Date: Thu, 16 Nov 1995 14:47:48 +1000 From: Stephen Hocking <sysseh@devetir.qld.gov.au> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: bugs@freebsd.org Subject: Re: Cannot interactively restore from a multivolume dump Message-ID: <199511160447.EAA23348@netfl15a.devetir.qld.gov.au> In-Reply-To: Your message of "Wed, 15 Nov 1995 21:55:33 %2B0100." <199511152055.VAA08838@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> I've succesfully been using it. It's okay that it doesn't read the
> entire tape in order to find that it hasn't to deal with just that
> particular volume (that's one of the big advantages of dump/restore
> actually!). It simply tracks all i-node numbers that it wants to
> restore, and all it has to do for any volume is to examine the first
> header on it, and see if there's any actual work on this volume. (It
> does always write based on i-node number ordering.)
>
> So the question is: why did it think that your files haven't been on
> *any* volume?
Don't know - I tried dumping again (this time making sure that the fs was unmounted, last time it was just quiescent) and then interactively restoring gain. I took note of where the inodes started from for each tape (I love the scrollback on xterm) and when I did the interactive restore, chose the tape dependent on the inode of each file, as shown by the directory on tape 1 and extracted. It still said "resyncing on restore, skipped 33 blocks" but found the files OK. Wish I knew why it was resyncing - I'll probably dive in with a debugger one of these days.
Stephen
--
I do not speak for the Worker's Compensation Board of Queensland -
They don't pay me enough for that!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511160447.EAA23348>