On Mon, Jul 18, 2005 at 07:50:12PM +0200, Michael Weiser wrote:
> On Sat, Jul 16, 2005 at 03:19:23PM -0400, Jon LaBadie wrote:
> 
> > 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.

It also says the -r options causes the output to be exactly as on "tape".
Thus it 'should' avoid the double processing.



> > 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.

Someone will correct me if I'm wrong.  The backup program may not be
available on the tapehost.  The client may have been some other
architecture or OS.  I'm pretty certain that amrecover was made to
run on a remote client, transfer the dump using amrestore (and its
"-r" option) on the tapehost, and do the extraction on the client.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)