Problems with restore (4.2BSD)

[Steve Grandi]

Last weekend we had a head crash on one of the RA81s attached to a
750 running 4.2.  After four days, a new head disk assembly was
installed by DEC (DEC apparently doesn't believe in stocking spare
parts, our new hda had to be pulled off the production line at
Colorado Springs) and I proceeded to restore the trashed file systems.

We had made a level 0 dump of /u1 and /u2 (our user file systems) on
17Oct and various incremental dumps in the following weeks.
I newfs'ed the file systems and read in the level 0 dumps with little
trouble.  However, when I tried to read in the first incremental dump,
restore would print out the nasty message: "Incremental tape too low."

Arrgh!!!!  The description of this message in the man page is not very
helpful ("a tape that was written before the previous incremental tape,
or that has too low an incremental level") and a look at the source
(/usr/src/etc/restore/symtab.c) reveals that this message occurs when
a comparison between a date in recorded in restoresymtable (which is 
created when the level 0 dump is restored) and a date stored in the header
of the newly mounted incremental tape do not agree exactly.  That doesn't
make much sense to me, but what do I know.

All was not lost as I could read in the incremental tapes file by file
using the interactive "add" mode of restore; but it is not very quick
or clean as everyone gains back all the old files they thought they
rm'ed long ago.

So, am I missing something or should I start hacking away on restore?

While I am in the neighborhood, does anyone understand the "resync
restore, skipped 1 blocks message"?  When restoring certain level 0
dumps, these messages appear on the console at a freightening rate;
but as far as I can tell, all the data is good.  Empirically, (when I
was doing a lot of level 0 restores while upgrading two VAXes to 4.2)
I only saw this behavior when I restored our /local filesystem; filesystems 
with other names hummed along fine.
-- 
Steve Grandi, National Optical Astronomy Observatories, Tucson, AZ
UUCP:	{allegra,arizona,astrovax,decvax,hao,ihnp4}  !noao!grandi
Arpa:	noao!grandi at lbl-csam