Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site uiucdcs
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!inuxc!pur-ee!uiucdcs!acheng
From: acheng@uiucdcs.CS.UIUC.EDU
Newsgroups: net.unix-wizards
Subject: Re: dump(8) verification ?
Message-ID: <13700114@uiucdcs>
Date: Tue, 8-Oct-85 23:54:00 EDT
Article-I.D.: uiucdcs.13700114
Posted: Tue Oct  8 23:54:00 1985
Date-Received: Sat, 12-Oct-85 14:46:22 EDT
References: <631@dicomed.UUCP>
Lines: 24
Nf-ID: #R:dicomed.UUCP:-63100:uiucdcs:13700114:000:1232
Nf-From: uiucdcs.CS.UIUC.EDU!acheng    Oct  8 22:54:00 1985


>/* Written  1:06 am  Oct  7, 1985 by richl@lumiere.UUCP in uiucdcs:net.unix-wizar */
>A relatively reliable way to check even a multi-volume tape is to do a
>dumpdir (or restore -t, depending on your flavor) and, using awk or
>sort or something, obtain the highest number inode that was dumped.
>Then restore that file, doing it the *dumb* way (starting with tape 1,
>through tape n). This will force restore to read each and every tape
>and finally restore the last file on the last tape. 

If an empty directory happens to be of the highest inode, you are out
of luck.  Directories are dumped at the very beginning.  So, your
"restore" will read only a bit of vol. 1 and finish.  You may want
to search backwards (from the highest inode down) for a file
not ending with a "/.".  We use the above approach before but
use "dd" since it is much faster and doesnot make much difference.

----------------------------------------------------------------------
Albert Cheng
acheng@UIUC.ARPA	acheng@UIUC.CSNET	{ihnp4,pur-ee}!uiucdcs!acheng
Dept. of Computer Science, Univ. of Illinois-Urbana,
Rm. 240, 1304 W. Springfield, Urbana, IL 61801

%%% The above is the opinion of my own %%%
%%% and not necessarily that of the management. %%%