To: eecs.nwu.edu::sun-managers
Subject: SUMMARY: Problem: restore - ". is not on volume"
Cc: hansen
A week ago I posted the problem included at the end, where I had problems
restoring from an `rdump' done of a filesystem on a Stardent (called `stellar'),
onto an Exabyte on a 4/690 (called `chrome'). Almost everyone who answered
agreed about the problem, below are their replies. Seems like `dump' and
`restore' aren't always compatible across different hardware types:
andy@mks.com:
> Maybe stellar's dump format is incompatible with chrome's so that you
> can't use chrome's restore programme.
Perry_Hutchison.Portland@xerox.com
> Perhaps the "restore" on the Sun is not compatible with the "dump" on
> the Stardent? What happens if you try
> stellar# rrestore -ivf chrome:/dev/rst2
russ@MATH.ORST.EDU:
> Use "rrestore" on the stardent to access the remote exabyte host (the 690).
> No surprise - the dumps are machine etc dependent.
> What if your stardent is down ? well, sorry, good luck.
(unfortunately the Stardent is long gone and for ever dead... although the
users knew far in advance and had plenty of time to move their stuff, some
unfortunately didn't listen. Aaarghhhh!)
dworkin@rootgroup.com:
> What does rrestore on the Stardent have to say about the tape? My bet
> is that the Stardent has a different byte-order than the Sun. Take a
> look at /usr/include/protocols/dumprestore.h -- you'll that there are
> lots of long ints stored in binary in the header....
>
> If you really want dumps that can be created by one machine, but read
> on all, you'll have to use tar(1) or cpio(1) (the latter with the `b'
> option).
miker@sbcoc.com:
> Try doing the restore remotely (like the dump) ... rrestore from the
> Stardent from the Sun tape drive. Most likely there's a subtle difference
> in the dump tape format.
tkevans@eplrx7.es.dupont.com:
> Try using the Stardent's 'rrestore'. I've seen different vendors'
> 'dump' generate incompatible tapes.
Thanks to the above and everyone else who replied with good suggestions:
holle@asc.slb.com and brent@crick.ssctr.bcm.tmc.edu:
suggested `dd' to see whether the tapes are readable. Seems to work, except
that `restore' doesn't know what to do with the resulting file...
ebumfr@ebu.ericsson.se suggested that I try to add to one of the savesets from
the Sun. This way I could possibly have found out whether `dump' on the Sun
really is compatible with `rbackup' (rdump) on the Stardent. Haven't tried it,
though.
(Thanks also to others I might have forgotten)
----------------------------------------------------------------------------
Ove Hansen e-mail : hansen@scr.slb.com
Schlumberger Cambridge Research Tel/fax: 0223-325246 / 0223-315486
P.O.Box 153, Cambridge CB3 0HG, England (International prefix for UK: 44)
============================================================================
============================================================================
============= MY ORIGINAL MESSAGE FOLLOWS ==================================
Help! I have the following problem with `restore' on a 4/690 (4.1.2), which
keeps telling me that `. is not on volume - Root directory is not on tape':
chrome# cd /tmp
chrome# restore -ivf /dev/rst2
Verify volume and initialize maps
Media block size is 112
Dump date: Sat Jun 20 02:30:31 1992
Dumped from: the epoch
Extract directories from tape
. is not on volume
Root directory is not on tape
abort? [yn] y
Below is the log of the dump from the actual date:
-------------------------------------------------------------------------
Dumping /home/stellar at dump level 0
/ETC/RBACKUP: Date of this level 0 dump: Sat Jun 20 02:30:31 1992
/ETC/RBACKUP: Date of last level 0 dump: the epoch
/ETC/RBACKUP: Dumping /dev/rdsk/10 (/home/stellar) to /dev/nrst2 on host
chrome
/ETC/RBACKUP: mapping (Pass I) [regular files]
/ETC/RBACKUP: mapping (Pass II) [directories]
/ETC/RBACKUP: estimated 1261870 tape blocks on 0.57 tape(s).
/ETC/RBACKUP: dumping (Pass III) [directories]
/ETC/RBACKUP: dumping (Pass IV) [regular files]
/ETC/RBACKUP: 2.46% done, finished in 3:18
<stuff deleted>
/ETC/RBACKUP: 96.78% done, finished in 0:06
/ETC/RBACKUP: 1243859 tape blocks on 1 tape(s)
/ETC/RBACKUP: /ETC/RBACKUP IS DONE
/ETC/RBACKUP: level 0 dump on Sat Mar 21 02:30:31 1992
/ETC/RBACKUP: Tape rewinding
Checking stellar:/home/stellar backup ... successful
--------------------------------------------------------------------------
Apparently from the above the dump has gome OK - the `checking backup' works
the following way:
< 1. Create a file in filesystem to be dumped >
< 2. Do the actual dump >
< 3. CHECK BACKUP: see if we can restore the file from stage 1 >
< 4. If file can be restored say dump OK. >
My problem is not just with the tape above - *all* the backups of the
particular system (a Stardent `rdump'ing onto a 4/690 running SunOS 4.1.2)
seem to be worthless (I have looked at at least 20 tapes), with exactly the
same error message as above.
Now, I am pretty sure that the dump has worked in the past - our operator has
successfully restored stuff before (so he says), and the script hasn't been
changed for yonks of time. The restore above was done on the *same* drive as
the tape was written on (Exabyte), I have tried other drives too - the same
result.
The time the dump was done should indicate that the file system was relatively
stable, in any case, changing file systems shouldn't affect *all* the backups
made of it.
Is there anything else I can try or should I better just use all the backup
tapes for my camcorder? I will summarise to the list.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:50 CDT