Hi,
wow, thanks for all the great feedback. I think you convinced me
that there was actually nothing wrong but I was likely not taking
into account the (should have been obvious) fact as you pointed out
that the entire dump file will have to be read to restore the
directory (yes it was dump vs. tar, by the way and, as you
observed, Sun's dump--ufsdump).
I guess what was bothering me most was never actually seeing the data
size of the client disk increase while amrecover (or, I guess,
amrestore by that point) was running. Maybe I had some egregiously
uncanny timing for checking inbetween "writes" while the dump file was
being parsed on tape. Yet, though I can't explain this, I believe I
witnessed twice the oddity of constantly checking the directory size
unchangingly and then, when convinced nothing was happening and so
aborted amrecover, the directory size would "suddenly" 'du' as 20
megs or so larger than the entire time I was checking it during the
restore. Is there any reasonable explanation for this?
So, I believe things were being restored but it was taking a
painfully long time (yet, as a possibility you mentioned, the dump file
itself was large, about 7 gigs) and eventhough I couldn't detect any
increase in size of the directory being restored, after aborting the
restore, the directory would be significantly larger.
One of these nights, when I don't need to run a backup, I'll
attempt the restore again leaving it to run overnight.
Now, for the entries in /etc/system that you mentioned at the end
of your message, is it a good idea for anyone using Sun's dump and
restore to have these? I have no idea what they are doing but if
they'll increase restore performance with no side-effects to mention,
they couldn't be a bad thing. Since I have no idea what these
entries are, you'll have to let me know if I can place them in my
/etc/system verbatim or if I'll need to customize them.
Thanks for all the feedback.
->>In response to your message<<-
--received from John R. Jackson--
>
> >... 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]
--
Paul Yeatman (858) 534-9896 [EMAIL PROTECTED]
==================================
==Proudly brought to you by Mutt==
==================================
