On Thursday 05 March 2020 05:08:25 Gene Heskett wrote:
Amanda did a 72GB backup last night, where fot a couple weeks it has 
sailed along in the 15GB range.  So I have not solved my problem with 
the long cycle bandaid.

So of course it used 2 vtapes, and ran w/o any error drama.

Here is the triggering problem, the database my wrapper script keeps so 
that I can restore to that same backup, not a day older, in the event of 
a major main disk upchuck and all of the amanda history is wiped out.

root@coyote:~$ du -h /GenesAmandaHelper-0.61/config-bak/
32G     /GenesAmandaHelper-0.61/config-bak/

Which is just a few % smaller than the size of a vtape. It contains 
copies of the indice files generated from each run as uncompressed 
tarballs for the last 60 amanda runs.  Each is nearly .6 GB.  And its my 
last chance to recover all that data for amanda's recovery database in 
one swell foop.  And because of that, I don't want to break that one up 
into smaller pieces. It does compress about 10 GB in the process, but I 
don't see a satisfactory way to shrink it, other than shrinking the 
number of vtapes. My script also appends a copy of todays config and 
generated indice as a tarballs, which it does every night as an append 
to that slots contents, so its not actually included in the disklist 
where it would be both subject to the vtape size set in the config, and 
duplicate data harder to find in the normal backup scheme.

Looking for a solution, but I don't see one. Open to ideas though. 

Perhaps a classic example of not being able to see the forest with all 
these trees in the way.

Copyright 2019 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply via email to