different modify date/time

[pkapoor]

I get execution errors in my log - "different modify date/time".

 

I have Retrospect Multiserver 7.5 setup.

 

All files indicated in the logs are from the Eudora email client.

 

What does this error message mean EXACTLY?

 

Thanks.

[rhwalker]

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?

 

Russ

[pkapoor]

Thanks for the response.

 

Yes, I believe that Eudora was running.

 

Now a follow-up question: from what you are saying, I do not have to worry because the version of the file that existed before its modification during backup, does get backed-up anyways. Right?

[rhwalker]

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?

 

Regards,

 

Russ

[pkapoor]

Thanks. That explanation gives a clearer picture.