On Tue, Oct 30, 2018 at 14:20:55 -0400, Chris Nighswonger wrote:
> Why in the world does Amanda plan level 0 backups for all entries in a DLE
> for the same run???? This causes all sorts of problems.
>
> Is there any solution for this? I've read some of the creative suggestions,
> but it seems a bunch of trouble.
The operation of Amanda's planner depends on many inputs, both "fixed"
(e.g. configuration options) and constantly-varying (e.g. estimate sizes
and dump history), and I suspect there are only a few people in the
world who really understand it fully -- and I don't know how many of
them still read this mailing list :(. But even one of those people
would probably need to look at a lot of information in order to know
what exactly was going on.
The good news is that I have noticed that the planner records a bunch of
interesting information in the amdump.DATETIMESTAMP log file, so at
least that seems like the place to start investigated. Look in
particular for the following sections: DONE QUEUE, ANALYZING ESTIMATES,
INITIAL SCHEDULE, DELAYING DUMPS IF NEEDED, PROMOTING DUMPS IF NEEDED,
and finally GENERATING SCHEDULE.
In your case, it seems likely that the PROMOTING DUMPS section should
have a bunch of activity listed; if so, that might explain what it's
"thinking".
If that doesn't give a clear answer, does the INITIAL SCHEDULE section
show all the dumps are already scheduled for level 0? If not, pick a
DLE that is not shown at level 0 there and follow it down the log to see
if you can figure out what stage bumps it back to level 0...
On a different track of investigation, the output of "amadmin CONFIG
balance" might show something useful (though off hand it seems unlikely
to explain why _all_ DLEs would be switched to level 0).
Let us know what you find out :)
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
