On Tuesday 23 March 2004 22:48, Fernando Serto wrote:
>> > My doubt is... isn't 324.7 K/s for dump rate too slow? I
>>
>> was backing up 1Gb
>>
>> > of data and it's taking almost 1 hour! does that mean that
>>
>> for 12Gb I'll get
>>
>> > something close to 12 hours?
>>
>> Probably, unless something changes.
>
>I hope it changes. :o)
>
>> > another thing, I tried using compress server best and
>>
>> compress client best
>>
>> > and I get no difference at all on the backups, same time to
>>
>> run, same amount
>>
>> > of data, and same tape usage.
>>
>> Is 'handsoff' the server itself, or another machine? If it is the
>> server, then it would be the same either way.
>
>yup. anyway, compression is off now (and was already set to none
> when I sent this one).
Drive hardware compression usually has a mind of its own. In
particular, many drives look at the header, and set the compression
on if the tape has ever been written to with the compression turned
on, and there is nothing amanda can do about fixing that. Many
drives have an indicator on the front panel called "dc", and if its
lit while the tape is being written, then the compression is on.
The only way I know of to fix such a tape is:
rewind it
read out the label to a scratch file using dd
rewind it again
turn the compression off with "mt -f device whatever turns it off"
dd that scratch file back to the tape using the non-rewinding device
dd at least enough data from /dev/zero to force the drive to flush its
buffers. This will force the drive to turn the header compression
flag off and that tape will not be compressed again unless you turn
compression back on.
I noted in a previous msg that your drive is a DDS3. This drive
should be able to stream about 700k/second. I'd concur that the
holding disk isn't enabled, or is somehow miss-configured and that
the drive is shoe-shineing the tape due to running out of data and
having to back up and restart once the buffer is up to 50% full or
so. Thats a speed killer in addition to causing a lot of wear and
tear on both the tape and the headwheel with all that starting and
stopping that we suspect it may be doing.
>> > NOTES:
>> > planner: tapecycle (1) <= runspercycle (1)
>> > planner: Last full dump of handsoff:/home/data/archive on
>>
>> tape DailySet01
>>
>> > overwritten in 1 run.
>>
>> This is OK for testing, but would be a big problem for real
>> backups. What
>> does your tapecycle, runspercycle, and runtapes look like?
>
>well, this is just a test, but I'll run a full backup once in a
> while for this box. I'll set up other backup clients to use a
> different conf file.
>
>> Since the taper and dumper stats are almost identical, I'm
>> guessing you
>> aren't using a holdingdisk. Configuring one could greatly
>> increase your
>> taper speeds since the tape must constantly stop and reposition
>> itself if the dumper can't keep up, and the dumper has to stop
>> each time the tape does since there isn't much buffering in
>> between.
>
>I followed all the steps for this, but I'm not sure if I'm using it
> or not.
>
>> If this is old slow hardware then the compression might also
>> limit your speed.
>
>it was set to none. doesn't matter what I use for compression, the
> backup time is the same.
>
>thanks!
>
>---
>Certain disclaimers and policies apply to all email sent from
> Memetrics. For the full text of these disclaimers and policies see
><a
>href="http://www.memetrics.com/emailpolicy.html";>http://www.memetric
>s.com/em ailpolicy.html</a>
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
|
