Jump to content

different modify date/time


Recommended Posts

Exactly what it says. The files have a different modify date/time during verification than during backup. During verification, the info for each file in the backup set is compared with the info on the disk. The files were modified during the backup procedure. Was the Eudora client reading/receiving email while backup was going on?



Link to comment
Share on other sites

Well, not quite. In some cases (it's application dependent), the application "state" is a set of files, not just one file. And in some cases (e.g., databases), the program may update stuff in the middle of a file without changing the length (or date, depending on the underlying OS and the mechanism used for opening the file). And in some cases, the program may cache modifications and then blast a bunch out at once, such that the file on disk may not match the program state in memory.


What Retrospect is giving you is a warning that the backed up data doesn't match the data on the disk during the verification. It takes judgment to decide whether that is serious.


One way to handle much of this is with CRC/checksum/polynomial calculations (e.g., MD5), so that the backup program can verify that the file in the backup matches what it thinks it wrote without having to do a comparison/verification with a file on disk. I think that the Windows Retrospect has this option, the Macintosh version does not (and I wish it did). Some other backup programs have this model (MD5, etc., validation rather than file comparison), too. That gives you the confidence that the file in the backup set is correct, even if the file has changed on disk in the interim.


But even that doesn't handle the case where a set of files constitutes a consistent state for the data (as happens with email servers and some email clients). The only true way to get a good backup is to do it with quiescent services, while things aren't active on the disk. If you've got a live server that you are trying to back up that needs 24x7 availability, and if the various applications don't do their own safe checkpointing (so that you can back up the checkpoints, rather than live databases), the only real way in my opinion to do the backup is to create a RAID 1 mirror, add a mirror secondary drive, allow the mirror to rebuild, then split the added mirror drive from the RAID, which gives you an instantaneous snapshot of the drive. It still has the same problem mentioned above about database consistency, but the window of risk is small, so you can quickly do a scripted shutdown of critical services, do the mirror split on the quiescent drive, bring services back online with only a brief outage and minimal disruption.


There's a discussion of this in a thread on the Macintosh forums:

Is a Duplicate an Exact Duplicate?





Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...