nancy@resonex.UUCP (Nancy Blachman) (07/12/85)
The UNIX manual page for dump(8) suggests dumping a file system
according to a modified Tower of Hanoi algorithm. If you know
how the sequence suggested, i.e.,
0 3 2 5 4 7 6 9 8
relates to the Tower of Hanoi algorithm, would you please
write to me and tell me.
The Tower of Hanoi algorithm is the sequence required to move
rings of different sizes from one peg of three pegs to another with
the restriction that no ring may lie on top of a smaller ring.
Do you know who invented the Tower of Hanoi?
/\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\/
Nancy Blachman UUCP: {hplabs,ihnp4,ucbvax!sun}!resonex!nancy
(408)720 8600 x37 ARPA: nancy@riacs.ARPAsalmi@dicomed.UUCP (john s salmi) (10/03/85)
a point of interest has been generated here of late. we are beginning to use
our 4.2 vax 750 as a serious development machine. a lot of proprietary soft-
ware lives on it, and dumps are done daily. my question is this:
has anyone hacked dump to perform a verify pass on the data dumped? a few
of our other development systems (pdp-11's) running rsx use bru as a backup
facility. one of the switches on the bru command line tells bru to make sure
that the tape is written as it is supposed to be written. this does, of course,
cause a bit of hardship, as the pdp's are backed up each morning around 8:00,
and the machines need to be in single user mode for the verifications to work.
anyway, does such a utility exist? if so, can someone point me in the direct-
ion of the source?
as always, thanks in advance...
-john
--
john salmi {ihnp4,mgnetp}!dicomed!salmi
system administrator
dicomed corporation
minneapolis, mn
612/885-3092eric@amc.UUCP (Eric McRae) (10/04/85)
> has anyone hacked dump to perform a verify pass on the data dumped?
If your dumps fit on one tape, you can at least do a dd of the tape
into /dev/null. That will check for tape errors. At some point, you
should verify that your dump/restore mechanism works. Understand what
you would have to do to partially or completely rebuild a filesystem.
I have had disk crashes three times in my carreer as a sysad. Each
one wiped out two filesystems. I could give you a lot of other hints
about this whole process but for now I'll assume that you don't need
them. If you do, send me a note.
Eric McRae Engineering Fellow, Applied Microsystems Corporation
Phys: 5020 148th Ave. N.E. USPS: PO Box C-1002
Redmond, Wa 98052 Redmond, Wa. 98073-1002
UUCP: eric@amc (..uw-beaver!tikal!amc!eric) ATT: (206) 882-2000richl@lumiere.UUCP (Rick Lindsley) (10/07/85)
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. This doesn't verify the data on every file, but it does verify that all the tapes are readable, that the labels you put on the tapes are correct, and that the data on the tape is in a recognizable format. This was the test we used to use at a leading university (Hi guys) before we packed away the last full backups of a semester for three years. If all you are interested in is tape errors, however, then as someone else mentioned, dd is a very fast way of doing that. Rick Lindsley
perl@rdin.UUCP (Robert Perlberg) (10/22/85)
Guy Harris's version of restor as implemented on MASSCOMP's has a 'c'
option which compares a dump with the filesystem and flags differences
in data content. I believe it is in the public domain and has been
posted to the net.
Robert Perlberg
Resource Dynamics Inc.
New York
{philabs|delftcc}!rdin!perl