amverify will read the tape, gunzip if gzipped, and use the list
option of restore/dump (which does not compare to disk contents).
(Really one can't compare to disk contents because they might have
changed, although a procedure of checking all and noting
matches/mismatches with ctime/mtime would be useful.)

In assessing how useful this is, it's helpful to think about the kinds
of errors that can happen:

* failure to read bits for the tape (media error, signaled on read)

* silently getting the wrong bits from the tape (i.e., not the ones
  that were written, but with no error indication)

* dump not dumping some files that it should

* dump producing the wrong bits on the client

* gzip producing the wrong bits

* changes in the bits from the client to the holding disk

* changes from the holding disk to the tape

* misconfigurations that fail to dump filesystems that should be
  backed up (amverify-like programs can't detect this of course).

I have seen the first two failures actually happen, and the last is of
course common.  The others seem not to happen much.

A key point is the use of gzip, which has a CRC.  So if you read a
file and the CRC is ok, then it is likely that the output of gzip (in
my case, on clients) was correctly transferred across the net, to the
holding disk, to the tape, and then back off the tape.

Without gzip, you'll get error indications if the metadata is
unreadable, but the data isn't checked.  So silent corruption may not
be detected.

I run amverify once a week (and amdump 5 times).  This is a tradeoff
between tape wear and quality control - if it works essentially every
time once a week, I'm pretty sure that things are generally ok.
Probably it should run with p=0.2 every night, to avoid checking the
same tapes.

-- 
        Greg Troxel <gdt AT ir.bbn DOT com>

pgp1MfXeS2Lxj.pgp
Description: PGP signature