Help! backup/restore yielded trash...

[Steve Dyer]

The problem I had with restore is fixed.  Following the procedure I describe
below, the restore of a full dump consisting of 33 diskettes proceeded
normally, error-free and successfully.

Note that in my earlier message, I had used the following command to
back up my old 30meg disk:

backup 0uk 1024 /dev/src

in the belief that the AT's 1.2mb floppy could hold at least 1024 1K blocks.
In fact, it holds 1200 blocks, which is the key to understanding the problems
I had during the restore.

The second fact to note, which I hadn't mentioned in my letter, was the
the floppies I had been using for the backup were not all freshly formatted.
Some of them had been used as DOS backups and perhaps some as UNIX backups.
Thus, when 'backup' wrote onto the diskette, it stopped after writing 1024
1K blocks, and there is naturally no equivalent on a floppy to EOT.  (It's
conceivable that a version of backup/restore could use a dummy header to
indicate that the dump floppy was logically at EOT, but the behavior I see
here would suggest that this isn't being done.)

Thus, when I performed a 'restore r /dev/src' on my new 80 meg disk, the
restore program obviously continued to read the floppies beyond the 1024th
block, and proceeded to get out of sync from there on, thus causing the error
message 'Missing address (header) block' to appear occasionally.  This
corrupted restore process produced a correspondingly corrupted file system.

By using "dd" (the programmers' equivalent to a Swiss army knife) and
copying only the first 1024 blocks of each floppy to a file name, I was
able to 'restore rf filename', recopying a new floppy each time restore
asked for a new volume.

Everything checked out cleanly, and the files are all intact, as best
I can tell.

You might want to file this one away for future reference!
-- 
Steve Dyer
dyer at harvard.HARVARD.EDU
{linus,wanginst,bbnccv,harvard,ima,ihnp4}!spdcc!dyer