On Dec 22, 2007 2:20 PM, Greg Troxel <gdt AT ir.bbn DOT com> wrote:
>   backup@amandaserver# amrestore -r /dev/nst0 hostname /foo/bar
>
> This will uncompress your dumps, which are probably gzipped, and that
> takes CPU and more disk bandwidth to write.  If they are compressed,
> give '-c' to amrestore to leave them alone.

Even without decompression, there are a nontrivial number of  copies
performed in the amrestore process, vs. dd, which essentially runs
while (!eof()) { read(buf); write(buf); }, if not something faster
like memory mapping.  That said, the initial analysis of block sizes
uncovered the likely culprit, so I'll be interested to see how the
Device API (under which this was completely rewritten) performs.

Dustin

P.S. To Stefan's wondering "where are all the hackers?" -- we're all
working hard to get a new release ready.  That's also why I totally
failed to identify the source of the "mystery 'r*' directories" in
another thread.  Thanks to Jean-Louis for straightening me out there!

-- 
Storage Software Engineer
http://www.zmanda.com