In February I expressed concern that when scheduling and promoting,
amanda's planner does not properly consider DLEs with longer than
default dumpcycles.

In my case I had a default dumpcycle of 1 week.  But more than
half my DLEs had custom dumpcycles of 2, 3, or 4 weeks.  When
looked at as "what does the full dump schedule look like for
the next 28 days" using "amadmin DS1 balance --days 28", there
were days with NO level 0s scheduled and others with 5 and 7 
large DLEs schedules totalling up to 4 times the "balance".

Sure, the "no scheduled level 0" days will get some promoted
dumps, but the monster dump days never seemed to go away.

This is not a recent configuration/installation.  There have
been years to get the balance adjusted to a reasonable state.

As described in the Feb 25 message below, I lengthed my default
dumpcycle and runspercycle to 28 days.  How I did it is described
in the message but is not recommended except for an experiment
like this.  After the included February message I describe the
results of the experiment.


On Tue, Feb 25, 2020 at 05:32:28PM -0500, Jon LaBadie wrote:
> In a recent discussion on widely out of balance dumps and
> frequent promotions to level 0 dumps I noted this about
> my configuration.
> 
> On Thu, Feb 13, 2020 at 11:50:34PM -0500, Jon LaBadie wrote:
> ...
> > 
> > My default {dump/runsper}cycle is 7 days, set in amanda.conf.
> > But more than 1/2 of my DLEs have custom dumpcycles (14,21,and
> > 28 days) set in their dumptypes.  You can not set custom values
> > for runspercycle in dumptypes (bummer!!).
> > 
> 
> I decided to give amanda's planner a different scenario, long
> dumpcycles and daily runspercycle to see if that would have an
> effect on the balances and promotions.  It seems to be working.
> 
> Using "amadmin <config> balance", the report shows the
> expected high balance over the next 28 days only exceeds 57%
> one time.  On that one date, 5 DLEs are scheduled to dump 350%
> of the balanced amount.  But the 3 days before that are well
> under balance, so perhaps the planner will promote some of
> the 5 DLEs.
> 
> Here are the changes I made.
> 
> In "amanda.conf", dumpcycle and runspercycle were both changed
> from 7 to 28 days.
> 
> In "disklist" I had many entries that defaulted to 7 day cycles
> like:
> 
>    cyber.jgcomp.com      Root    /        comp-root-tar
> 
> and many othere entries with longer dumpcycles like:
> 
>    cyber.jgcomp.com      Vault-Monthly    /opt/vault-monthly {
>        comp-user-tar
>        dumpcycle 28
>    }
> 
> I made NO changes to disklist.  Thus it seems like Root above
> would get the default 28 day dumpcycle rather than the desired
> 7 day.  To fix this I edited the "dumptypes" file.  The dumptype
> "global" is incorporated into nearly every other dumptype so
> I added a dumpcycle line.
> 
>    define dumptype global {
>        comment "Global definitions"
>         index yes
>         record yes
>         auth "bsdtcp"
>         # added jhl 2/13/2020
>         dumpcycle 7
>    }
> 
> So now, DLE Root gets its dumpcyle from the global dumptype
> (7 days), Vault-Monthly overrides the global value to 28 days,
> and amanda's planner uses the default value from amanda.conf,
> also 28 days.
> 
> The primary downside is an administrative one.  If someone
> adds a new DLE they might expect it to get the default from
> amanda.conf when that is actually overridden by the global
> dumptype.
> 
> If I see any surprise effects from these changes I'll report
> back.  But so far (12 days) it has been fine.
> 
> Jon


Well, not a hick-cup.  Ran smoothly the entire 2 months since
I made the changes.  As you will see in the 28 day schedule
that follows, there are no days with zero full dumps scheduled
and the largest days are only 2x the balance size.

    $ amadmin DS1 balance
    
     due-date  #fs    orig MB     out MB   balance
    ----------------------------------------------
     4/14 Tue    1     107003     106124    +59.5%
     4/15 Wed    3      76638      65826     -1.0%
     4/16 Thu    3      80792      51735    -22.2%
     4/17 Fri    4     192853     133781   +101.1%
     4/18 Sat    7     110353      88447    +33.0%
     4/19 Sun    2      79663      58196    -12.5%
     4/20 Mon    1     123755      97200    +46.1%
     4/21 Tue    1      63332      51495    -22.6%
     4/22 Wed    3      76638      65826     -1.0%
     4/23 Thu    3      80792      51735    -22.2%
     4/24 Fri    3     120982      61484     -7.6%
     4/25 Sat    6      38743      17041    -74.4%
     4/26 Sun    1      79663      58196    -12.5%
     4/27 Mon    1     123755      97200    +46.1%
     4/28 Tue    1      40558      39703    -40.3%
     4/29 Wed    3      76638      65826     -1.0%
     4/30 Thu    4     108679      79443    +19.4%
     5/01 Fri    2      85869      27801    -58.2%
     5/02 Sat    7      90187      61737     -7.2%
     5/03 Sun    2      79663      58196    -12.5%
     5/04 Mon    1     123755      97200    +46.1%
     5/05 Tue    1      19439      19326    -70.9%
     5/06 Wed    4      76638      65826     -1.0%
     5/07 Thu    3      80792      51735    -22.2%
     5/08 Fri    4     132022      73292    +10.2%
     5/09 Sat    6      38743      17041    -74.4%
     5/10 Sun    2     159184     137520   +106.7%
     5/11 Mon    1     123755      97200    +46.1%
    ----------------------------------------------
    TOTAL       80    2590884    1896132     67719
    BALANCED          2556708    1862553     66519
    DISTINCT    30    1100328     909156
      (estimated 28 runs per dumpcycle)

I'm completely happy with the results.  If you are
having balance problems and do have some longer than
default dumpcycles, consider making a similar change.
But my situation may be unusual in that I have a high
proportion of long dumpcycle DLEs.

Time to eliminate the administrative problem I allude
to in the February message and convert the 7 day
dumpcycle DLEs to "custom" dumpcycles.

Jon
-- 
Jon H. LaBadie                 j...@jgcomp.com
 11226 South Shore Rd.          (703) 787-0688 (H)
 Reston, VA  20190              (703) 935-6720 (C)

Reply via email to