On Sat, Jul 16, 2005 at 03:19:23PM -0400, Jon LaBadie wrote:

> > > amrestore -p diskdir/slot30/00002.machine._.3  | \
> > >   ssh machine "cat - >~/restore/machine._.2.tar"

> > Does anybody know if the above is the right way to restore complete
> > archives from virtual tapes?

> Don't have a real solid answer, fortunately I've not had to do that.
> Just a couple of thoughts.

I'd like to try it out before the actual crash happens. ;)

> Simple thing, you have a mismatch in source and destination names,
> level .3 -> level .2.tar

Ah. I think I had to rerun one of the restores since this typo made
another overwrite the this one's archive. ;)

> The amrestore command is getting the file in uncompressed format
> even if it was compressed.  If you want to transfer the compressed
> form I think you could add the -r option.

I think it's -c actually and the manpage is a bit ambiguous on the
actual workings it. From the phrasing I'd expect the files to be
uncompressed if necessary and then recompressed if requested using -c.
That would mean processing the whole archive twice - first uncompressing
then recompressing. That's why I've just gone without it since I wanted
to untar the whole thing anyway. One could just give it a try and look
with top if amrestore actually works that simple or does some brainwork
first.

> Extraction and transfer could be done separately if you have space
> and don't want to play with pipes/cat/ssh.

I wanted to restore a backup to set up a chroot environment of the
machine in question to compile some updates without hogging the actual
box. I'd have piped it into tar on the target machine directly, but
wanted to prevent me from trashing the compile box by simple every-day
stupidity. So I settled for restoring the archives first using an
unpriviliged user and then untared interactively as root. Otherwise it
would have read

amrestore -p diskdir/slot30/00002.machine._.3  | \
        ssh root@machine "cd /data/chroot && gtar -xpf -"

or so.

> You are certain it is a tar archive?  Separate extraction of the
> header can be done to see what amanda says it used.

I was certain it was tar archives. An automated solution obviously would
have to check. 

> Using amrecover might be possible.  I think when you specify to
> extract a directory it extracts recursively anything under that
> directory.  So adding "/" or "." to the extract list (I forget the
> semantics) might make recovery of the entire dump possible using
> amrecover.

Problem is: amrecover always restores to a directory on the backup
server, doesn't it? So I'd have to NFS-mount some directory from the
actual target machine to have the data go where I need it. If I want to
restore the whole box anyway I find the archives more flexible.

> The final answer is, of course, whatever works :)

My experience is quite good so far. The restore using the above
technique worked just fine and the chrooted system is compiling
without problems. ;)

I'm just a bit surprised that no-one else seems to have run into this one,
yet. Has anyone else done complete system recoveries from virtual tapes?
-- 
bye, Micha