On Tue, Jul 11, 2006 at 08:14:19AM -0600, Graeme Humphries wrote:
> Nicola Mauri wrote:
> > 1) What kind of errors can amverify detect?
> > 2) What kind of errors *cannot* amverify detect?
> > 3) Does it make sense to schedule amverify after amdump every day?
> > 4) Should we trust amverify results? Should we continue to check
> > backup by periodically restoring some tapes?
>
> It's my limited understanding that amverify simply tries to read all
> files off the tape that are supposed to be there according to the
> database. It has no way to compare that against the original data to
> compare whether or not it's good data, it just checks to make sure the
> data it thinks is there is actually there.

Just a clarification according to my understanding:

What amverify does depends on the commands that created the dump.
Obviously if the dump was made on a Solaris system with ufsdump
but the backup server is a linux system that lacks ufsrestore,
the ability to check the restorability of the dump is minimal.

In the best case situation, I believe amverify will confirm the
ability to read the data from the tape, gunzip it if appropriate,
and parse the archive throught the appropriate recovery program
by creating a table of contents to /dev/null.

Lower level of verification is used where the recovery program is
not available.  I.e. can it be read from the tape with out errors
and, if appropriate, gunzip'ped.

> So it's probably a very good idea to periodically pull data off the
> tapes and make sure it's actually valid, but running amverify after
> amdump just to make sure that data made it onto the tape isn't a bad
> idea either.

Absolutely.  amverify is no replacement for actual recovery testing.


And if you plan to run amverify after each amdump, consider instead
using amverifyrun.  amverify needs to be told which "single" tape to
check.  amverifyrun looks at all the tapes used in the most recent
amdump without being told on the command line which tapes they were.

I can't verify this (play on words) but am confident that these
commands now handle tape spanning.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)