On 2006-03-16 09:12, Thomas Widhalm wrote:

And, actually, we did not yet see how many times this DLE
was dumped with level 0.

Can you post the output of "amadmin config balance" and
"amoverview config" (or mail it to me if it contains
too much private information).

[root@amanda root]# amadmin IS balance

 due-date  #fs    orig KB     out KB   balance
----------------------------------------------
 3/16 Thu    0          0          0      ---
 3/17 Fri    0          0          0      ---
 3/18 Sat    0          0          0      ---
 3/19 Sun    1    2960985    2960984     -8.7%
 3/20 Mon    2   18406150   14296059   +341.0%
 3/21 Tue    6    4925020    2194810    -32.3%
----------------------------------------------
TOTAL        9   26292155   19451853   3241975
  (estimated 6 runs per dumpcycle)

Amanda expects about 19 GByte of level 0 dumps, and, from
experience in the last cycle, expects to run 6 times during
a dumpcycle.
Didn't you specify a dumpcycle of 8, together with
runspercycle 0, promising to run 8 times instead of 6?
Better make sure the crontab entry is in harmony with the
runspercycle as specified in amanda.conf.
Or is this IS config one with runspercycle 6?

From the last cycle, Amanda now looks at the due-dates (the
date when the next level 0 of a file system is scheduled)
and calculates how much data that generates.  This actually
is boils down to the real data in the last dumpcycle, shifted
in the future.
So from the above, amanda does not need to dump anything at
level 0 for the next three days, but she looks ahead and sees
that on 3/20 she expects to dump 14 Gbyte.  So during the
next run she will promote some filesystem to that run, in the
hope that to lower the amount of work on 3/20.  She tries to
dump 19 GByte / 6 each time.

But I guess that one of those filesystems due on 3/20 is a
very large one.  And so Amanda is always out of balance.
She tries to dump 1/6th each day, promoting everything,
except the large one. But the work is for nothing because that
one filesystem is just way bigger than 1/6 of the work.

Does that make sense in your config?

[root@amanda root]# amoverview IS
         date                 03 03 03 03 03 03 03 03 03
host     disk                 08 09 10 11 12 13 14 15 16

amanda.e /                     0  0  0  0  0  0  1  0  1
amanda.e /boot                    0  0  0  0  0  1  0  1
commodo. /                     1  2  2  2  2  2  2  1  1
linglab. /                        1  1  1  1  1  0  1  1
linglab. /home                    1  1  1  1  1  1  1  1
psyserv0 /                        0  0  0  0  0  1  0  1
psyserv0 /boot                    0  0  0  0  0  1  0  1
psyserv0 /usr                     0  0  0  0  0  1  0  1
psyserv0 /var                     0  0  0  0  0  1  0  1

First the disklist details that were posted were for
host springfield.edvz.sbg.ac.at, but that is not in the list above.
So I'm still not 100% sure that host psyserv0 has the correct
parameters.  But let's assume it is all correct.

How large is the level 0 dump of linglab. root filesystem?
Is that the enormous chunk that cannot Amanda has difficulty
to balance?

Please remember that IS is just one of, for now, 4 configs which are run
daily.

Are those 4 configs on 4 servers?  Any reason not to consolidate them
into fewer (19Gbyte is not a large config -- mine needs to dump
160 Gbyte compressed over the complete dumpcycle, and I do use vtapes
for this too.)

It seems, that tweaking "reserve 30" and "maxpromoteday 2" did it. Today
was just one full backup and this should happen.

The "reserve 30" will Amanda force in doing only 60% of free holdingdisk
for level 0, and the rest for incrementals.

Note that those 30% is calculated each run again, based on the current
available space in the holdingdisk: if you start one day with 200 Gbyte
free space, than 60 Gbyte is reserved for incrementals, allowing for
up to 140 Gbyte of level 0 dumps.  Assuming that Amanda did fill those
140 Gbyte with level 0 indeed (and 20 Gbyte incrementals), then the

full dumps.  And so on.

So I still believe this is not a real solution.

The solution is probably to divide the enormous DLE into smaller,

--
Paul Bijnens, xplanation Technology Services        Tel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM    Fax  +32 16 397.512
http://www.xplanation.com/          email:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* 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, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************