Path: utzoo!attcan!uunet!wuarchive!emory!gatech!mcnc!decwrl!ads.com!sparkyfs!zwicky
From: zwicky@sparkyfs.istc.sri.com (Elizabeth Zwicky)
Newsgroups: comp.unix.admin
Subject: Re: Why idle backups?? (was Re: Looking for shell script for backup on BSD 4.3)
Message-ID: <32757@sparkyfs.istc.sri.com>
Date: 25 Oct 90 16:53:01 GMT
References: <547@fciva.FRANKLIN.COM> <1642@sirius.ucs.adelaide.edu.au> <32749@sparkyfs.istc.sri.com> <1990Oct24.151840.25570@ccad.uiowa.edu>
Reply-To: zwicky@pterodactyl.erg.sri.com.UUCP (Elizabeth Zwicky)
Organization: SRI International, Menlo Park, CA 94025
Lines: 38

In article <1990Oct24.151840.25570@ccad.uiowa.edu> emcguire@ccad.uiowa.edu (Ed McGuire) writes:

>Now is there any easy way to validate an active dump?
>I have in mind something on the order of attempting an interactive
>restore of the last file dumped. 

No, there isn't any easy way to validate it - unless you consider
doing a full restore easy. There are basically four ways in which the
tape can be screwed:
	1) Some individual file may be missing or damaged; without
attempting to restore that particular file, you will never know.
	2) Some individual file may be damaged so that any attempt to
read it confuses restore permanently. Again, unless you attempt to
read *that* file, you will never know; things after it on the tape are
perfectly accessible, as long as you don't read it first. (Since
restore doesn't tell you what it's trying to restore, only what it has
finished restoring, if you run into one of these when trying to
restore, you get to play binary search, doing add and extracts on
subsets of your original file list until you have everything but the
bad one. Ick.)
	3) At some point, some file may be screwed enough to corrupt
everything after it - this one you will catch by interactively
restoring the last file. 
	4) There may be physical write or read errors on the tape.
These will generally be caught by the scanning necessary to find a
file, so you will usually see indication of them if you try the
interactive restore. However, you won't know what they've eaten.

So you only catch half the possible kinds of error; since error number
one is the most common case for active files, you end up catching less
than half of all the errors. There are methods that check a dump
against a file system without requiring you to do a restore, which are
really useful for testing modifications to dump, but worthless for
verifying live dumps, since they will report that the dump is
incorrect if it doesn't match the disk - which it certainly won't, if
the disk is active.

	Elizabeth Zwicky