On Sunday 11 November 2018 15:36:52 Nathan Stratton Treadway wrote: > 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.... >
it is an improvement, so I'm not going to try and move anything else for about a week just to see if it levels out better. PublicA is currently the 800 lb gorilla, so I may next attempt to adapt one of the recipes for a-f etc in the top of the disklist. 3, maybe even 4 of those might get it under control. And its a technique I've not yet explored. > 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 Copyright 2018 by Maurice E. Heskett -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
