Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!noao!mcdsun!fnf
From: fnf@mcdsun.UUCP (Fred Fish)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: UNIX tape backup utilities ( SysAdmin from UniSolutions Assoc.)
Message-ID: <376@mcdsun.UUCP>
Date: Wed, 31-Dec-69 18:59:59 EDT
Article-I.D.: mcdsun.376
Posted: Wed Dec 31 18:59:59 1969
Date-Received: Thu, 10-Sep-87 00:48:53 EDT
References: <153@tijc02.UUCP> <1143@ttidca.TTI.COM> <358@mcdsun.UUCP> <1153@ttidca.TTI.COM> <284@unisol.UUCP> <367@mcdsun.UUCP> <285@unisol.UUCP>
Reply-To: fnf@mcdsun.UUCP (Fred Fish)
Organization: Motorola Microcomputer Division
Lines: 62
Keywords: menus security backups
Xref: mnetor comp.unix.wizards:4145 comp.unix.questions:3948

In article <285@unisol.UUCP> haral@unisol.UUCP (Haral Tsitsivas) writes:
>Another issue though is, how many system administrators can keep the system
>down long enough to do block by block checking of dump tapes?  If you have a
>production level system (or a large development system) with several eagles
>(and GBytes) you may only have enough time to do complete backups and not
>block by block checking of the tape and disk files (users never want to lose
>the machine for long periods of time, or be slowed down while a backup is
>done when they are logged in).

A very valid point, unfortunately.  I myself have been bitten badly a 
couple of times when I simply did not want to take the time to verify
the backup.  I once lost several days worth of work to flakey hardware
that gave no indication of any error on write, and as luck would have
it, nuked only file data blocks on my backup and not file header blocks.
The typical method of "verifying" tar tapes by doing a table of contents
would not have caught this either.

The alternative to keeping the filesystems quiescent long enough to verify
the backup is to turn the users loose and do the verify anyway, and then
simply manually scan the list of differences for those that look like they
might indicate a problem (/unix is different for example).  Whether or not
this is a practical solution obviously depends on your circumstances.

There are couple of other uses for a tape versus filesystem comparison
facility that I have found to be quite handy:

	(1)	Write an archive of only the files you consider to be
		critical to system operation (I.E. "system" files as
		opposed to "user" files).  Keep this around, keep it
		current, and when you experience any "flakiness" with
		the system, diff your current system against this
		standard.  This is great for catching all sorts of
		nasty things like hardware induced filesystem
		errors, or malicious hacking at your system files.

	(2)	Use it to verify that two trees in a given system
		are identical, including permissions, ownership,
		file contents, dates, etc.  Very quick and easy to
		start two copies, one to create an archive in the
		"source tree" and pipe it to another to diff the
		archive in the "destination tree".

>				If a tape-speed (or near tape-speed) method
>for verifying the sanity of backups exists and works reliably (under most
>systems, although not as reliably as the block comparison method) then most
>people will use that...

This is one of the reasons why I also have an "inspection" mode, that
simply verifies that all the blocks are readable, they are in the
correct order, each block has the proper checksum, etc.  Not quite as
comforting as a full tape versus filesystem verify, but as you noted,
much faster and less impact on the system with downtime.  This also
means you can pull any tape out of storage, years later, and still
verify that it is a complete and viable backup (I understand some
installations rewrite old tapes periodically to counteract some sort
of "bitrot" that all magnetic media is subject to).

-Fred
-- 
= Drug tests; just say *NO*!
= Fred Fish  Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282  USA
= seismo!noao!mcdsun!fnf    (602) 438-3614