Hi.
I'd like to thank all 40+ people who responded so kindly and expediently
to my rather basic question (see bottom for original question). I'll spare
the mailing-list an itemized list of those kind souls, but here's the
basic information included in most responses, as provided by Michael
Maciolek:
> Each dump is saved on the tape as a separate dump file, and files
> on a tape are separated by 'end-of-file' markers. Use the 'mt'
> command to skip past the first dump file (for "root") and you'll
> then be positioned to use 'ufsrestore' on the second partition.
>
> mt -f /dev/rmt/1h rew
> mt -f /dev/rmt/1hn fsf 1 # fsf = "forward skip file"
> ufsrestore if /dev/rmt/1hn
>
> Remember that the files will all be relative to "/foo", thus you
> won't actually see "/foo" as part of the pathnames.
John Bradley included the same instruction, but then suggested:
> This does not always work though. When doing ufsdumps you should
> use something like this:
>
> ufsdump 9uf /dev/rmt/1hn /
> mt -f /dev/rmt/1hn eof
> ufsdump 9uf /dev/rmt/1hn /foo
> mt -f /dev/rmt/1hn eof
> ufsdump 9uf /dev/rmt/1hn /bar
> ...
>
> It seems to work for me.
Others included a variation on the above, issuing the "fast-forward"
instruction not during the mt sequence, but in the ufsrestore command, a la:
>% ufsrestore ifs /dev/rmt/1h 2
which refers to the sequential order of the filesystems on the tape (in
sequence /, /export, and /export/home, /export/home would be 3rd, hence
<ufsrestore ifs /dev/rmt/1h 3>). A few people seemed to think otherwise,
however, that the "2" would take one to the *third* volume file. My own
attempt using this convention confirms that it is, in fact, the former.
Also, Reto Lichtensteiger was kind enough to include a few words on the
"n" after the device designation (/dev/rmt/1hn):
> Note that I used the "n" version of the device file so that the
> driver wouldn't instruct the tape drive to rewind after we "close"
> the device.
And finally, Phil Antoine included what seems to be a wise instruction:
> The key is to pay careful attention to which device you are using
> and what it does to the tape position when it completes. Strange
> things can happen if you lose track of EOF markers so the safest
> thing to do, IMHO, is access each concatenated archive from fresh
> rewinds of the tape.
I would especially like to thank the list for the lack of curt
"RTFM" responses. A few responses included relevant man page lines,
which, for some reason, I missed in their various places (mt and ufsdump
and ufsrestore all referenced the relevant information in varying
detail). Many people included wonderful explanations in their responses,
and the effort is greatly appreciated.
Cheers,
Jason
---My original post:
> I've hit a small but important problem: I'm not really familiar > with ufs[dump|restore], and I can't figure out how to restore files > from the "/foo" volume off a tape of a machine that was backed up > like this: > > ... > mt -f /dev/rmt/1h rewind > ufsdump 9uf /dev/rmt/1hn / > ufsdump 9uf /dev/rmt/1hn /foo > ufsdump 9uf /dev/rmt/1hn /bar > ... > > If I "ufsrestore if /dev/rmt/1h" it takes me to the tree, I can > look around "/" all I want and restore files to my heart's content, > but both /foo and /bar look empty. The backup output seems to > indicate a successful backup of all three volumes, however.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:03 CDT