On Thu, 2001-12-06 at 16:53, Joshua Baker-LePain wrote:

> Well, there's amverify, but all it does is generate a table of contents 
> from the tape images -- if that succeeds, the tape is marked OK. Note that 
> there is no comparison of the TOC to index files or file system contents, 
> so this isn't exactly the best.

amverify is good at detecting if the media has gone bad. As you point
out it doesn't check the contest - dump could have filled the archive
with garbage and amverify wouldn't notice anything.


> > linux box. Some cron task that could do a file to file compare or md5
> > compare would really help me sleep at night.
> 
> Patches welcome.  ;)

:)

Right now we use a shell script to gather information about date, file
size, uid, gid and permission. We run teh script on the server and on
the restored replica. We filter both lists with a python script and
parses the through diff to see how much they differ.

This is very time consuming as you have to restore a complete server
each time. I have another idea to a script which could be run from cron:

After the backup is done, one of the level 0 backups is restored to an
area on the backup-server. Then an rsync dryrun is compared to the real
server (or part of) and the output is mailed to sysadmin. The restore is
kept for reference and deleted next time the compare is running. Some
kind of planner is needed to schedule the comparison - only level 0
dumps can be used (at least for systems with no auto tape-changer).

We currently backup 22 partitions, which means (if you only compare one
partition each night) that we can check each partition approx once a
month. Hmm.. maybe the scheduler should look at the size of the archive,
so that eg. 3 small partitions could be checked at once. It would be
nice if the compare cycle could be kept lower than the tape cycle.

Regards,

Ole Kaas

Reply via email to