different modify date/time errors

[ua-it]

I'm backing up a mailserver (Kerio), and am getting different modify date/time errors. I'm assuming that the files are getting touched between the time Retro checks the mailserver and the time it takes to get to backing up the file.

 

Do these files get backed up? If not what can i do to make sure they are getting backed up?

[rhwalker]

Quote:

---

I'm backing up a mailserver (Kerio), and am getting different modify date/time errors. I'm assuming that the files are getting touched between the time Retro checks the mailserver and the time it takes to get to backing up the file.

 

Do these files get backed up? If not what can i do to make sure they are getting backed up?

 

---

You ask a difficult question. Yes, the files get backed up, and the error message comes when the compare/verify phase finds something different when re-reading the backup set than on the disk. But you might not be able to restore an uncorrupted mail database from the backed up files.

 

The only way to eliminate the errors (but perhaps not solve your problem) is if the program logs what the MD5 (or some other) checksum polynomial was and then verifies that checksum against the computed checksum upon re-reading the backup set (rather than comparing against the file on disk). That ensures that what the program thought it backed up was, in fact, what was stored in the backup set. That's a different question than whether the data in the backup set matches the data on disk at a subsequent, post-backup, time. Some backup programs have this behavior (don't compare against the file on disk), and there are pros and cons to each design.

 

But, even then (with no errors, and assurance that the file in the backup set is the same that the program thought it put in the backup set), it's not good enough.

 

Most database systems (and kerio is one of those; the cyrus email server that we use on our unix system is another) have to have a consistent set of files in order to be able to do a restore. Most email servers have not only the email messages themselves, but also indexes into those messages, and all must match.

 

You need a consistent set of files to be backed up. There are several ways to do that. One way is to shut the mail server down, do the backup of a quiescent mail subsystem, then restart the mail server. That could have the mail server down for a while, and might be a problem unless you have a secondary MX.

 

A second way is if the mail server provides its own tools to create a consistent backup set, and then have Retrospect back up that backup set created by the mail server itself.

 

A third way is to put the mail subsystem on its own volume that is part of a RAID 1 mirror. Then, shut the mail system off (which ensures that the mail subsystem is quiescent), split the mirror, restart the mail system. That leaves the split-mirror clone having a consistent state of the mail system, and, if scripted, the mail system will be off only for a few seconds (and secondary MX, or normal mail retry, can handle the brief outage). You could then use Retrospect to back up the split mirror clone.

 

Hope this helps. We use the second and third ways.

 

Russ