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
