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