On Thu, Aug 21, 2003 at 03:28:24PM +0100, Keith Foster wrote:
> I'm trying to do a remote recovery of a Solaris server, I have booted to
> rsh -n -l "user" "server" /usr/local/sbin/amrestore -p /dev/rmt/0bn "server
> name" / | ufsrestore rvbfd 2 - for the level 0
> I then load the incremental tape and run the same command I get:
> Dump date: Tue Aug 19 18:09:34 2003
> Dumped from: Mon May 19 05:32:04 2003
> Level 1 dump of / on server:/dev/md/dsk/d0
> I don't understand where it gets the "Dumped from" date, and what is meant
Keith,
ufsdump got it from an entry in /etc/dumpdates that looked like this:
/dev/md/dsk/d0 0 Mon May 19 05:32:04 2003
The obvious (but not necessarily correct) answer is that you managed to
run the full (at least) without the amanda 'record yes' set. Does
/etc/dumpdates match your amanda records exactly?
ufsdump stores the "Dump date" and "Dump from" on the tape. "Dump
from" is "the epoch" for level 0, and read from /etc/dumpdates for
level 1,2,3...
When you run 'ufsrestore r', as you ufsrestore each tape in order,
it leaves the "level/Dump date/Dump from" information behind in
./restoresymtable.
Since 'ufsrestore r' *removes* files as well as adding them, it is
VERY careful about all the "Dump date" and "Dump from" information
matching up EXACTLY, to make you:
1) Run the tapes in the right order, not 0, 1, 3, 2.
2) Run the correct set of tapes.
If the dates don't match up, because of /etc/dumpdates problems
for example, you cannot run 'ufsrestore r'.
If you are *sure* your tapes are all proper, you can run 'ufsrestore x .'
instead. You will not get file removal.
--
Jay Lessert jay_lessert AT accelerant DOT net
Accelerant Networks Inc. (voice)1.503.439.3461
Beaverton OR, USA (fax)1.503.466.9472
|