Hello...
John R. Jackson wrote:
>> <start>
>> backup all the small partitions
>> several local partitions start
>> one of the partitions across the T1 starts
>> the local partitions end at various times
>> ...
>> <wait some more>
>> remote partition ends (about 4 hours later) and writes to tape
>> holding area dumps start writeing to tape
>
>
> Are you saying no tape activity is going on until this last line?
> That's definitely not right (and not what I see on my systems).
There is no tape activity for any backups started after the remote
(slow) backup started.
A simpler example
serverA /
serverA /data
serverB /
all dumps fit in holding area but not simultaniously
<amdump starts>
serverA / starts
serverB / starts
serverA / ends ( and start writing to tape)
serverA /data starts
serverA /data ends ( and stays in holding area)
<wait 4 hours while serverB / comes in>
serverB / ends ( and starts writing to tape)
serverA /data writes to tape
>
> Were you looking at the amdump.<NN> file to deduce this? And at the
> "FILE-WRITE" commands from taper to dumper? Here's a command that cuts
> down the chit-chat to the important stuff:
I watched it by running 'amstatus' periodically. The backups start ~
1am. Just the local backups take ~ 5 hours. Add in the delay from the
remote and it could be 9 or 10 hours total. My observations were made
about 6am.
>
> egrep '^driver:.*(DONE|FILE-)' amdump.<NN>
>
> If you want to convert the delta timestamps to real time, throw this
> script in the pipeline:
>
> ftp://gandalf.cc.purdue.edu/pub/amanda/amdumpts
>
>
>> Christopher McCrory
>
>
> John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
--
Christopher McCrory
"The guy that keeps the servers running"
[EMAIL PROTECTED]
http://www.pricegrabber.com
"Linux: Because rebooting is for adding new hardware"
