>... After starting the restore (using 'amrecover'), I
>check that files and directories are indeed being created. ...
Files and directories, or just directories?
It appears from later comments that you are using a system dump program
(as compared with GNU tar). Is that correct?
If so, directories are stored at the front of such a dump image and so
get restored first. Then come the files. So when bringing something
back you'll see the entire directory tree get set up then individual
files as they are found on the image.
>... The read light on the tape drive continued to flash yet
>the size of data on the client disk was apparently not changing. ...
That could be entirely normal, especially if you are using a system
dump program. The files are written in inode number order, which has
absolutely nothing to do with directory order. So you could be skipping
through a bunch of files that are not involved in the directory you're
reloading, hence the disk space used will not be increasing.
It also means almost the entire tape image may have to be read to do the
restore, so while the directory you're bring back may only be 100 MBytes,
if the image is several GBytes it all has to be moved (up to the last
file to be restored).
>This following time, not having erased the files and directories that were
>restored the first time to the client disk, I can't see that anything
>is being restored. 'df's of the partition and 'du's of the
>directory show no change in size though, as with the first time, the tape
>drive read light is slowly flashing away. ...
That's the same as above. Unless you removed the restored area, nothing
would be happening to the disk space until it found the next file to
reload that wasn't already there.
>Is there anyway to monitor amrecover's activity? I checked the
>man page for a verbose flag but apparently this doesn't exist. ...
The problem is, amrecover is out of the picture at this point. All it
does is set up a pipeline between an amrestore on the tape system and your
restore program on the client, the sit back and wait for it to finish.
You could run lsof (ftp://vic.cc.purdue.edu) on amrestore on the tape
system to verify it is moving data. You can also run it twice with some
sleep time (a minute or two) in between and determine the transfer rate.
I'd be more suspicious of a general networking problem unrelated
to Amanda. For instance, is there any 100 Mbit Ethernet between
the two machines and if so are you absolutely positive there isn't
a duplex mismatch? You mentioned ufsrestore, which implies Solaris,
which is known to totally botch auto negotiation. I have to put this
in /etc/system to force the issue:
set hme:hme_adv_100fdx_cap = 1
set hme:hme_adv_autoneg_cap = 0
Without this, performance drops by a factor or 100 or more. Ick.
>Paul Yeatman
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
