Kai Zimmer wrote: > the machines are: > kirk (amanda-server): 2x650 P3; IDE-LVM (hold: 2, local 6 disks), Linux, > Giga-Ethernet
How much holding disk does that spell? Verify the setting in amanda.conf, you don't want to be limited here. > before: 1x244 Opteron, single-SCSI-Disk U160, Linux, Giga-Ethernet > crusher: 1x242 Opteron, single-SCSI-Disk U160, Linux, Giga-Ethernet > hera: 2x1,4 Ghz P3, SCSI-LVM (2 disks), Linux, Giga-Ethernet > kira: 2x1,4 Ghz P3, IDE-LVM (8 disks), Linux, Giga-Ethernet > lore: 2x1,8 Ghz Xeon, SCSI-HW-Raid (10 disks R5), Linux, Giga-Ethernet > zeus: 2x400 Mhz Sparc, single-SCSI-Disks (4), Solaris 8, Giga-Ethernet I'd venture to try `compress server' here on all but the Sparc machine. Seem to be nice beasts to me... > USAGE BY TAPE: > Label Time Size % Nb > volume008 30:30 193301.4 93.5 7 > volume009 11:01 199313.5 96.4 1 > volume010 15:47 192761.9 93.3 2 > volume011 7:13 130811.4 63.3 1 [...] > taper: tape volume008 kb 389149248 fm 8 writing file: No space left on > device [...] > taper: tape volume009 kb 305159648 fm 2 writing file: No space left on > device [...] > taper: tape volume010 kb 324967808 fm 3 writing file: No space left on > device [...] > taper: tape volume011 kb 133950912 fm 1 [OK] 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? 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; or use software compression with the true tape length (that would help with holding disk space as well). 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. Add to that the better parallelizing, and you're down to less than a weekend. > before /home 0 2904652029046520 -- 215:092250.1 214:162259.4 > crusher /home 0 1616860016168600 -- 205:041314.1 240:581118.3 > hera /home 0 3058162030581620 -- 419:161215.7 540:09 943.6 > kira /home 0 8711075287110752 -- 1291:561123.8 431:153366.6 > kira -me/konvert 0 133950848133950848 -- 1633:501366.4 432:315161.7 > kira -re_rehbein 1 197190 197190 -- 33:11 99.0 11:03 297.5 > kirk /home/clip 0 110277408110277408 -- 577:093184.6 516:113560.6 > kirk /ohne-clip 0 204097056204097056 -- 1561:002179.1 660:325149.8 > lore /local/home 0 104371080104371080 -- 1059:461641.4 489:043556.8 > lore -me/sokirko 0 85726108572610 -- 116:181228.6 169:18 843.9 > zeus /home 0 90030409003040 -- 139:311075.5 165:25 907.2 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. Alex -- Alexander Jolk / BUF Compagnie tel +33-1 42 68 18 28 / fax +33-1 42 68 18 29
