Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!ucsd!ucbvax!ucsfcgl!cca.ucsf.edu!dick
From: dick@cca.ucsf.edu (Dick Karpinski)
Newsgroups: comp.unix.admin
Subject: Re: Why idle backups??
Summary: Live dumps could be safe and slow.
Message-ID: <3212@ucsfcca.ucsf.edu>
Date: 30 Oct 90 18:24:12 GMT
References: <547@fciva.FRANKLIN.COM> <1642@sirius.ucs.adelaide.edu.au> <32749@sparkyfs.istc.sri.com> <1990Oct24.151840.25570@ccad.uiowa.edu> <32757@sparkyfs.istc.sri.com>
Reply-To: dick@cca.ucsf.edu (Dick Karpinski)
Organization: University of California, San Francisco
Lines: 20

In article <32757@sparkyfs.istc.sri.com> zwicky@pterodactyl.erg.sri.com.UUCP (Elizabeth Zwicky) writes:
>
>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:

In principle, your dump program could take checksums of each block of
each file during its dump and then again from the disk after the dump.
This could catch flaws arising from dumping a live file system, though
fixing those flaws requires also a way to rewrite the dump tape or to
note that a file image is damaged.  Rereading the tape is necessary
and sufficient to detect writing and media errors.

Since almost all files are small enough to hold in RAM, you could even
employ two strategies, a quick one for little files and a slow, robust
one for the few large files.  Strategies that include file system mods
have more opportunities to be quick and efficient, but safe live dumps
need not require them.

Dick