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 [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA (fax)1.503.466.9472