On Sun, Nov 11, 2018 at 05:25:29 -0500, Gene Heskett wrote:
> > > amanda@coyote:/amandatapes/Dailys/data$ /usr/local/sbin/amadmin
> > > Daily balance
> > >
> > > due-date #fs orig MB out MB balance
> > > ----------------------------------------------
> > > 11/10 Sat 1 7912 3145 -78.7%
> > > 11/11 Sun 1 10886 10886 -26.1%
> > > 11/12 Mon 1 32963 7875 -46.6%
> > > 11/13 Tue 1 7688 7688 -47.8%
> > > 11/14 Wed 2 22109 22109 +50.0%
> > > 11/15 Thu 4 75027 46623 +216.3%
> > > 11/16 Fri 6 8257 6109 -58.6%
> > > 11/17 Sat 29 14034 8932 -39.4%
> > > 11/18 Sun 4 21281 16842 +14.3%
> > > 11/19 Mon 18 34599 17188 +16.6%
> > > ----------------------------------------------
> > > TOTAL 67 234756 147397 14739
> > >
[...]
> After this mornings run, its better again:
> amanda@coyote:/root$ /usr/local/sbin/amadmin Daily balance
>
> due-date #fs orig MB out MB balance
> ----------------------------------------------
> 11/11 Sun 1 10886 10886 -35.8%
> 11/12 Mon 1 32963 7875 -53.6%
> 11/13 Tue 1 7688 7688 -54.7%
> 11/14 Wed 2 22109 22109 +30.4%
> 11/15 Thu 4 75027 46623 +175.0%
> 11/16 Fri 6 8257 6109 -64.0%
> 11/17 Sat 29 14034 8932 -47.3%
> 11/18 Sun 4 21281 16842 -0.7%
> 11/19 Mon 18 34599 17188 +1.4%
> 11/20 Tue 1 49240 25295 +49.2%
> ----------------------------------------------
> TOTAL 67 276084 169547 16954
> (estimated 10 runs per dumpcycle)
>
> And it must be calculating the balance based on the original size, not
> the compressed size (out MB), that growing Tuesday the 20th is still on
> one vtape, but if unchanged, Thu 15nth will still use a 2nd vtape.
Comparing these two runs, I see that all the rows (the first four
columns on each line) are the same -- except that the single DLE listed
on 11/10 of the first run came out much larger when it was actually
dumped last night. (7912/3145 v.s. 49240/25295). When you said "that
growing Tuesday the 20th", was that an indication that you already
expected that particular DLE (which should be easy to identify as the
only full dump listed in last night's report) to be growing rapidly?
(Note that the "balance" column is in fact calculated based on the
compressed/"out MB": the "average size" of 16954 listed at the bottom of
the "balance" column is sum-of-all-"out"-sizes/runs-per-dumpcycle (i.e.
the average of the out-sizes), and then the balance percentile in each
row is (today's-out-MB less average-size)/average-size. For example,
for 11/20, you have
(25295-16954) / 16954 = 0.492
,and for 11/16 you have
( 6109-16954) / 16954 = -0.640
, etc.)
So, from these two days of "balance" reports, the takeaway is that one
particular DLE seems to have become much bigger (3145 -> 25295 MB
compressed size), and as a result the average dump size went up by
2200MB, and thus all the positive-balance days had their balance
percentages go down a bit. So the balance did improve, but because of
the growth of the total backup volume rather than because of
rescheduling any particular dump(s).
Also, the fact that this one DLE grew to be larger than the average dump
size explains why no other DLEs were promoted to last night's run (and
thus none of the other date's rows changed at all).
However, the next three days all show negative balance figures, so it
will be interesting to see if Amanda promotes any DLEs from the 11/14,
11/15, or 11/19's groups to try to even the batches out a bit.
However, the first two of those dates currently have small DLE counts,
and 11/19 includes many DLEs but totals just slightly over the average,
so the opportunities for rebalancing may be pretty limited....
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
