A dump/restore HAZARD involving consecutive level 0 dumps

[Bill Mitchell]

This note describes a problem involving consecutive level 0 dumps that we
discovered the hard way.  Sun has been notified of this problem and has
assigned a bug number, 1052964.  We have requested an official workaround,
but haven't received one as yet.  We ran into this problem under 4.0.3 and
I assume it still exists in 4.1.1.

We use a fairly simple backup scheme here: level 0 dumps every month or so
and level 1 dumps daily.  We maintain off-site archives and to avoid
making trips to our storage facility to retrieve the most recent level 0
dumps, we do two sets of level 0 dumps, one right after the other, with
the system in single-user mode.  One set is sent off-site and one is kept
on-site.  A set of level 1 dumps is sent off-site on a weekly basis.

We used this scheme for a couple of years without any trouble, but one day
we ran into a problem.  For the sake of discussion, let's say that we did
level 0 dumps on 2/25 with the first set at 6:00pm and the second
(identical) set at 7:30pm.  It happened that the 6:00pm set was on-site
and we did a full restore from that set.  We then tried to restore a level
1 dump on top of just-restored filesystem, but restore squawked with
"incremental tape too high".  The problem was that when the level 1 dump
was made, it was noted on the tape that it was based on a level 0 dump
done at 7:30 on 2/25, but the restoresymtable built by the level 0
restoration said the level 0 dump was done at 6:00pm on 2/25.  restore
correctly detected an apparent mismatch and wouldn't let us proceed.  

restore is clearly doing the right thing, but there should also be some
way to tell restore to "trust me and use the tape".  In our particular
case we recovered by hacking the date recorded in restoresymtable so that
it matched the date on the level 1 tape.  (FYI-My notes indicate that the
time and date were the third and second words from the end of
restoresymtable.)

In the course of typing this note it occurred to me that it might be
possible to avoid this problem by not specifying dump's "u" flag on the
second dump, but I haven't tried this to see if it works.

If the problem occurs you can always do a restore of all the files on the
level 1, either ploppping them in on top of the level 0 files or putting
them in a separate hierarchy and manually merging them, but either one is
pretty ugly.

If you're careful to send the first set off-site and keep the second-set
on-site, you won't run into this problem unless you have to fall back to
the off-site archives.

If you'd like to see Sun address this issue, I encourage you to give them
a call.

Bill Mitchell				whm at sunquest.com
Sunquest Information Systems		sunquest!whm at arizona.edu
930 N. Finance Center Dr.               {arizona,uunet}!sunquest!whm
Tucson, AZ, 85710                       sunquest!whm at uunet.uu.net
602-885-7700