> From: Patrick Welche <prlw1@newn.cam.ac.uk>
> 
> On Wed, Nov 10, 2004 at 06:41:19PM -0500, Greg Troxel wrote:
> > I use amanda, and use 'amverify'.  It doesn't compare  the bits, but
> > it does read the files back and run them through gunzip and restore
> > tfv (or tar for those that use tar, which I do for coda but not ffs).
> > I am betting that if gzip doesn't get a decompression error that the
> > bits are ok.
> 
> If I just use dump, with no compression. Then restore -tv is the
> equivalent of the above? But doesn't that just read the catalogue at
> the beginning of the tape file rather than read everything (giving
> a read error if there was something wrong with the tape)?

Indeed, 'restore t' only reads the catalogue.  With gzipped dumps,
one can verify that the entire file passes the gzip checksum.

My scary problem (that I attributed to scsi bus errors) was that the
files on tape were the same size, and most bits were right, but some
weren't.  I have no confidence that 'restore t' would catch this.


> There sometimes is mention of -C option which compared the files on tape
> to the files on disk, but was deemed not useful on live filesystems..

If it exixted, it might be interesting to run it and see how many
files are different.  One could make it compare ctime/mtime and print
out files that are different that shouldn't be.  Manually scanning the
list of non-matching files, you should only find ones that are
typically modified, much like the daily security check for changed
suid files.