Amanda-Users

Re: tuning amanda

2004-11-17 10:56:02
Subject: Re: tuning amanda
From: "Kai Zimmer" <kai AT zimmer DOT net>
To: amanda-users AT amanda DOT org
Date: Wed, 17 Nov 2004 16:52:59 +0100
Hi Alex,

> How much holding disk does that spell?  Verify the setting in
> amanda.conf, you don't want to be limited here.

345 GB - Amanda is allowed to use the disk completely, except for 30% reserve.

> I'd venture to try `compress server' here on all but the Sparc machine. 
> Seem to be nice beasts to me...

"compress server"? Didn't you mean "compress client"?

> Notice you hit EOT at between 300GB and 390GB, so your data is quite
> compressible, and you are in fact using hardware compression.  Is that
> LTO-2?

yes - it's an LTO-2. Most of our files are xml, so the compression should work 
good.

>  Anyway, the successful size of the tapes is only 200GB, which
> means that amanda wrote more than 100GB to tape, only to run into EOT
> and start over.
> Conclusion: either give a more realistic estimate of effective tape
> length in your tapetype definition so amanda doesn't try to schedule a
> huge flush only to fail;

hmm, that's a tapetype definition i found on amanda.org for this drive. But 
i'll change it of course.

> or use software compression with the true tape
> length (that would help with holding disk space as well).

ok, i'll try both and see which is faster.

>  And moreover,
> break your disks in smaller DLEs; that way when amanda hits EOT, she
> only needs to restart a few GB, and not hundreds.  That alone should cut
> your backup time down by a third.

ok, maybe that was a problem...
 
> Add to that the better parallelizing, and you're down to less than a
> weekend.

:-)

> As far as I see, you've got dump rates of consistently over 1MB/s. 
> That's not bad I think, I'm sometimes getting worse.  The longest runner
> would be kira:.../konvert, 134GB at 1.3MB/s gives 100000s which spells
> 27h to me.  Plus two other disks on the same machine that cannot be
> parallelized. :-(  Cutting into smaller pieces would stop them all from
> doing a full the same day, though.

that was my first guess, too. Now i have some parameters i can optimize now 
(tapesize, client compression, DLEs).

Thanks a lot for your help,
Kai





<Prev in Thread] Current Thread [Next in Thread>