Kai Zimmer wrote:
Run Time (hrs:min) 110:57 Dump Time (hrs:min) 120:52
Sorry, i didn't completely understand that. Run time can't be lower than dump time, so parallelizing will gain max. 10h ?
Yes it runtime should be much lower than dumptime when having many clients.
From my "archive" run this weekend:
STATISTICS:
Total Full Daily
-------- -------- --------
Estimate Time (hrs:min) 0:39
Run Time (hrs:min) 12:07
Dump Time (hrs:min) 51:45 51:45 0:00
This means that the backup was done in about 12 hours, which would have taken more than 4 times as much when doing every DLE sequentially. Amanda does dump many clients at the same time.
About your problem, the pdf shows that from the 16 dumpers you started, only a minority is busy: a peak of 40% in the beginning, and then only 1 or even 0 dumpers for a long time. At the same time the holdingdisk is used 100%. Together it means that your holdingdisk area is too small. If possible I would add a cheap large disk in the server (200 Gbyte or more would be nice). You can configure multiple holdingdisks.
The graph also shows the tapedrive is (almost) always busy. That's good. You can fill the little gap with having a larger holdingdisk.
The total data was 716188 Mbyte and took almost 110:57 - 8:56 = 102:01. That is 1996 kB/sec. You didn't specify what tapedrive and host server you used, but this seems a little low to me. What is the expected throughput of your tapedrive (what does amtapetype indicate as speed)?
My tapedrive is a simple AIT-1 drive, 35 Gbyte native capacity, theoretically doing 3MBytes/sec. Amanda does 2600 kB/sec on average (large partitions going at 3000-3090 kB/sec). And the amanda server is only a 300 MHz Celeron with 128 MB RAM and a 80 Gbyte IDE holdingdisk.
Slow tapespeed can be the result of one or more DLE's bypassing
the holdingdisk. That results in the tapedrive not streaming anymore.
The file "amdump.1" contains the keyword "PORT-DUMP" instead of "FILE-DUMP" for such partitions. Are there any?
Again adding holdingdisk space would help in that case (or splitting those DLE's into smaller ones).
Having a large holdingdisk, and many parallel dumpers, could result in doing the dumps fast, finishing before people come in and load the client machines, and taping all those collected images can then proceed at the normal tapespeed, but without bothering the end users.
-- Paul Bijnens, Xplanation Tel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *********************************************************************** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***********************************************************************
