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>
