Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!root%bostonu.csnet@CSNET-RELAY.ARPA
From: root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr)
Newsgroups: net.unix-wizards
Subject: Re: dump(8) verification?
Message-ID: <2068@brl-tgr.ARPA>
Date: Fri, 11-Oct-85 16:39:42 EDT
Article-I.D.: brl-tgr.2068
Posted: Fri Oct 11 16:39:42 1985
Date-Received: Mon, 14-Oct-85 03:29:41 EDT
Sender: news@brl-tgr.ARPA
Lines: 44


Ok, a couple of more thoughts on one of our favorite subjects (:-)

	1. Assuming you are able to design your dump schedules to
	use a lot of incremental dumps which are not huge (and have,
	of course, completely thought out what it takes to restore
	such a sequence) why not dump to a file, put that to tape
	(tar would do fine, would also allow multiple savesets on
	a tape if you just give them different names). Now the
	verify should be workable albeit not speedy (verify against
	the disk image, it won't get changed as the system runs.)
	One would probably have to write a streaming form of cmp/tar
	so you could do the moral equivalent of cmp `tar x mydump` mydump
	or some such, or just make another disk copy if you can afford to
	(cd ../scratch;tar x mydump;cmp mydump ../dump/mydump). This
	of course assumes sufficient disk space, may require relying on
	more frequent incrementals rather than only occasional fulls.
	You may have to still just take your chances with fulls or use
	another scheme, but this could help a lot.

	2. Use two tape drives or dump twice to two tapes which takes
	about the same amount of time as verifying a tape, they may not
	be identical but they should, if done right, be equally useful
	if the same level dump is used and the first does not update
	dumpdates. It doubles tape cost but something has to give!

Note that a lot of this does not prevent what I have experienced as the
absolute worst disaster in the whole backup industry: A tape drive is
going out of synch, eventually someone notices something is wrong
(maybe goes completely down), FS comes and fixes it. It now refuses to
read many many tapes written on itself before the fix. This is not as
uncommon as you think (have you ever checked after FS left?) which means
to really do a verify, you ought to do it on a different tape drive,
or maybe N different tape drives...? Trust me, it happens.

SO: WHAT I AM REALLY CURIOUS ABOUT BEING AS TAPE DRIVES STINK !I HATE EM!

Anyone out there have Optical Disks *in production* on their Unix systems?
Mail to me and I'll summarize. This promises to solve some set of problems
I believe, if it ever keeps its promises.

	-Barry Shein, Boston University

TAPES committee (Tapes Are a Poor Excuse for a Solution.)