On Sun, Feb 09, 2020 at 15:29:04 -0500, Gene Heskett wrote:
> It has perms to use 2 vtapes, so there is nothing left in either of the
> holding disks, ever. And I am still trying to make it use higher levels,
> its entirely too often it will advance half the disklist from level 2 to
> level 0, doing a jump of 9 days!, and that then runs onto the 2d vtape
> by half a vtape. Doesn't make any sense either when it says going to do
> a level 3, then in the final report in the same email it actually does a
> level 0, maybe 20 times out of a 75+ entry disklist.
>
> So basically, I am tired of amanda lying to me. It should do what the
Gene,
When you say Amanda is lying to you, are you referring to the section
of the Amanda mail report that looks like:
planner: Incremental of <DLE1> bumped to level 6.
planner: Incremental of <DLE2> bumped to level 2.
planner: Incremental of <DLE3> bumped to level 2.
[...]
planner: Full dump of <DLEx> promoted from 6 days ahead.
planner: Full dump of <DLEy> promoted from 6 days ahead.
planner: Full dump of <DLEz> promoted from 6 days ahead.
[...]
... and in particular the fact that sometime the same DLE shows up in
both of those lists?
Assuming so: keep in mind that the "bumped to level" messages actually
come from an early pass through the DLE list, during which Amanda simple
decides if the incremental level (for each DLE) should be bumped up,
based on the various bump* amanda.conf dumptype parameters. (Presumably
the calculations from this step will match the results printed by the
"admadmin ... bumpsize" command.)
At this point Amanda hasn't tried to do any "balancing" yet, so really
these "Incremental of <DLE1> bumped to level X" messages should be
interpreted as meaning "if I happen to do an incremental dump for <DLE>,
that dump will be at level X" (rather than as, say, "I am about to do a
level X dump of <DLE>").
> planner says its going to and it might eventually hit a balanced
> schedule, but with something overriding the planner, there is no way in
> hell it will ever get it done.
The "from from N days ahead" lines are the ones from the logic that
attempts to balance the runs. I think it's fair to say that they are
_from_ the planner, so the issue is not really that something is
"overriding" the planner, but rather that the planner's calculations
aren't working out very well in your context....
Looks like there we had some discussion here on the list back in
November 2018 about the unbalanced runs you were seeing, which got as
far as my theorizing that perhaps you had a few DLEs that were so much
larger than all the others that Amanda's normal algorithm for adjusting
the balance is unable to achieve that goal....
I don't know if there is anyone left on this list who understands the
inner workings of those algorithms, but if you really want to get to the
bottom of the problem you'll probably have to spend some time combing
through the balance calculation section of the planner log files....
Or, you can try one or both of these and see if they happen to improve
the situation:
* break up your largest DLEs (or exclude some of the data from Amanda
backup in order to make them smaller)
* make your dumpcycle either longer or shorter, so that the expected
average daily size changes. (Depending on the relatives sizes of
your DLEs, you may need to made the daily size either larger or
smaller to get things to work better...)
Anyway, if you decide you want to get to the bottom of your balance
issue, it probably makes sense to go back to the 'following the
"balance" report' thread from 2018 and pick up from there...
> Back at about 2.4.2 I had zero trouble filling to within 50 megs, a 4GB
> DS2 tape. And that was by telling amanda the tape was 3.5Gigs, and
(I have no idea how much the planner algorithm changed between 2.4 and
3.5, but keep in mind that your DLE list changed a lot since then as
well, so it's not really an apples-to-apples comparison...)
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - [email protected] - 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
