On Wednesday 27 January 2016 11:47:25 jflack wrote: > On 01/26/2016 05:51 PM, Jean-Louis Martineau wrote: > > What is the taperalgo setting? > > largestfit > > >> Dumps: lev datestmp tape file origK compK secs > >> 0 20160124 0 20550680 20550680 369 > >> 1 20160125 0 680 680 11 > >> 2 19691231 D03001 69 0 0 0 > > > > That one looks like a bug. I suspect it is an old dump that was > > deleted when D03001 was overwritten. > > I think there might be an arguable bug of some kind, but I see > situations like this frequently in amadmin info output ... that > is, two situations that are similar: > > 1. A full dump that is still in the holding disk, with a later > increment that has been taped, where the later increment has > nonzero size and a real datestmp > > 2. A full dump that is still in the holding disk, with a later > increment that has zero size (probably nothing changed in > that DLE), and a 19691231 datestmp. > > It looks to me as if the 19691231 datestmp (Unix epoch, depending > on your timezone) is always what appears if the increment has > zero size. That seems like a quirky-but-minor issue. > > What holds more of my interest is this apparent pattern where > increments will go to tape even before the full dumps they > depend on, with the full dump not necessarily even going to > tape until a later amflush. > > When I look at the list of available taperalgos, it looks as if > they only consider two things: dump size (largest, smallest, > any algo ending with "fit"), and time of dump completion > (first, last, any algo starting with "first"). > > I don't see that any algo explicitly considers the dependency > relationships between dumps (hmm, dump B *depends on* dump A, > so I should satisfy the stated algo preferences in a way > that also makes sure A is on tape if B is). > > As a practical matter, dump A must have arrived at the holding > disk before dump B did, so algo "first" will probably DTRT, > and "firstfit" will probably DTRT most of the time. Algo "last" > will probably DTRT only when no other outcome is possible. :) > > I guess what I'm wondering is, how straightforward is the > development of additional taperalgos? Can they be written > in Perl? Is there an API for retrieving information on the > dumps that are in the holdingdisk, and enough information to > figure out which ones *depend on* which others, so something > like a topological sort could be done? > > And ... is there anybody already working on that? > > -Chap
Sounds to me like you are doing these backups by hand, and IMO thats not how to run amanda efficiently. If you don't have a user "amanda" make one, then put the backup into the amanda crontab to be done in the middle of the night when the machine is mostly idle. Because its being done regularly, 99.44% (SWAG guess, copied from an old ivory soap commercial) of those problems will vanish, only popping up when the machine is rebooted in the middle of a session that never gets finished. But amanda will catch up the next day if you have autoflush set true in the amanda.conf file, so thats not a biggie in my observations. 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>
