grandi@noao.UUCP (Steve Grandi) (11/24/84)
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@lbl-csamtgr@brl-tgr.UUCP (11/29/84)
Reguarding the second of your problems (the resynch message from restore), it has been my experience that that is the result of tape parity errors resulting from either bad tape or tape drive problems. With very many of these errors you backup is not of much value. It is also my experience that dump is silent about this type of error. Having been bitten once, we now occasionally check our level 0 backups by trying to restore a file or two, just to make sure that the backup really is! ( a backup, that is). Bill [johnston@lbl-csam]
lancs.sm@ukc.UUCP (lancs.sm) (03/12/85)
When trying to do a restore, mounting the tapes in reverse order as suggested, restore asked us for a tape which had been previously mounted. After we mounted this tape - we got a HUGE number of diagnostics about files being missing from the tape. We tried it again in the forward order and it worked! I guess it splits files between tape boundaries and doesn't realise not to re-read a WHOLE tape after getting the tail end of a file from the previous tape.
joe@fluke.UUCP (Joe Kelsey) (03/20/85)
Once again, here is a bug that was fixed on March 22, 1984, almost one year ago today! If there is anyone out there who doesn't know how to send their $50 to mt. Xinu for the 4.2 buglist, please review the recent archives in this buglist or send a request directly to mt. Xinu (they talk to berkeley and their machine name is mtxinu, send a message to postmaster if nothing else). I assume that you all have your mt. Xinu bug lists handy, turn to the file etc/48 and apply the fix listed there. /Joe