Greg Freemyer wrote: > On 4/25/07, G.T.Smith <[EMAIL PROTECTED]> wrote: >> Carlos E. R. wrote: >> > >> > The Wednesday 2007-04-25 at 11:44 +0100, G.T.Smith wrote: >> > >> > ... >> > >> > > The conclusion I am coming too is the the current time stamping >> > > mechanism is inadequate for anything but the crudest of time related >> > > file management, and possibly not even that given the way some >> things >> > > manage files... >> > .... >> > > and time stamping was an option...If time stamping was reliable and >> > > consistent this could have been used to flag files to backup, it >> is not >> > > so it cant **sigh** I >> > >> > The modification time can be used to know when to backup the data, and >> > the >> > change time for the metadata. Meaning, if the modification >> timestamp has >> > not changed, but the change timestamp has, it should mean that the >> file >> > itself it's the same but the attributes have changed, and thus, >> > backing up >> > of the metadata only should suffice. >> > >> > In practice, you could compare all metadata: attributes, size, >> > dates... if >> > any of them changes, backup the file (not optimal). Another method, >> > safer, >> > is to also store a checksum: if some of the metadata changes (except >> > size), calculate the new checksum to see if a backup is needed. For >> this, >> > the metadata of the last backup should be saved on disk. >> > >> > A good backup program should do all this automatically. >> > >> I theory good, in practice not.. well look at editor example originally >> quoted ... modification time does not always mean content has changed it >> merely means the modification time stamp has changed... it would be nice >> that everyone handled this time stamping issue in a well defined >> manner... in practice many people don't, this is not criticism this is >> just an observation BTW >> >> Yes a good backup program will do this ..... but the serious players >> would charge me more than the underlying hardware is worth! A couple of >> people have pointed me to some stuff on a separate sub-thread which I >> intend to look at.. and hopefully I can avoid having to write my own >> solution... > > Neither of the solutions I posted earlier in this thread are dependent > on timestamps. > > iirc: Especially for online backups rdiff-backup mentioned before > ignores timestamps altogether. It calculates the MD5 for every file > to see if any changes have been introduced. If they have it segments > the file and drills down to find the smallest unit of change and only > sends that data across the LAN/WAN. > > Greg
Thanks. I have taken a look at your suggestions and that of Joachim, I am impressed with the description of both. XFS is not an option as it looks like I would have to do a lot of partition juggling to make a move. Unfortunately, as there are problems with my tape unit I am for the moment constrained by the need to backup to DVD/CD, and it is not immediately clear to me how either dirvish or rdiff-backup would effectively work in this situation, but I will be looking into this further. (Actually, the more I have explored the DVD/CD element of the problem, more I understand why no-one has produced a usable DVD/CD backup solution). I have already decided that for the code I am working on I will be using subversions backup procedures to dump the repositries, and I will be dumping MySQL databases as well (probably will eventually run queries that only dump new records or modified records), which largely leaves the backup of Documents, Spreadsheets, etc etc to something else (rdiff-backup seems to be the front runner here).. e-Mail structures are going to be a particular headache. t -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
