Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: iand@krite.labtam.oz.au (Ian Donaldson)
Newsgroups: comp.sys.sun
Subject: Re: A dump/restore HAZARD involving consecutive level 0 dumps
Keywords: Miscellaneous
Message-ID: <2178@brchh104.bnr.ca>
Date: 25 Mar 91 22:00:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 18
Approved: Sun-Spots@rice.edu
X-Original-Date: 25 Mar 91 11:19:48 GMT
X-Refs:  Original: v10n63
X-Sun-Spots-Digest: Volume 10, Issue 69, message 1
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

sunquest!whm@uunet.uu.net (Bill Mitchell) writes:
>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.

A reasonable solution to this is to allow a command line argument to
specify an alternate /etc/dumpdates file.  This way you can have multiple
consistent dumps done simultaneously.

Dump upto 4.3bsd-reno doesn't have such an option unfortunately. (would
be nice!)

A workaround is to maintain multiple /etc/dumpdates yourself, by using a
wrapper script for alternate sump sequences that mv's /etc/dumpdates to a
safe place, the alternate one in for the alternate dump, then out again
and restores the original one afterwards.

Ian D