A dump/restore HAZARD involving consecutive level 0 dumps

[Bill Mitchell]

In article <2100 at brchh104.bnr.ca>, I described a problem that prevents restore
from properly using an incremental tape that one would expect to be valid.
In that article I wrote:

> 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.

Today I tried this approach and it *did not* work.

Also, in the orginal article I said that using the first of two
consecutive level 0 dumps with an incremental dump yielded the message
"incremental tape too high".  I got that wrong, the message is
"Incremental volume too low." (If you do two consecutive level 0 dumps,
omit "u" on the second dump, restore the second dump, and then try to put
on an incremental, the message is "Incremental volume too high".

An old version of the source for restore seems to indicate that restore
expects the date match to be exact.  That is, if a level 0 dump is done at
10:12 on 3/1/91, the level 1 dump must contain information that indicates
that it was based on a level 0 dump done at 10:12 on 3/1/91.

I presume one could workaround by having a script that sets the system
date appropriately based on the contents of /etc/dumpdates and then starts
the second dump, but the date needs to be accurate to the second.  I don't
think it would be a snap to do this reliably.

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