On Monday, August 22, 2011 12:55:32 AM Thomas Marko did opine: > Am 21.08.2011 um 12:56 schrieb gene heskett: > > On Sunday, August 21, 2011 06:30:06 AM Thomas Marko did opine: > >> Hi, > >> > >> I have a question regarding dump levels in Amanda. I do backup > >> several DLEs with an Amanda server 3.2.1 on a dedicated machine > >> (Ubuntu Natty). On another machine (Ubuntu Lucid, Amanda 2.6.1) > >> there is a DLE which approx. 175GB data. The first time backup was a > >> level 0 backup with approx. 175 GB (surprise :-). Then Amanda made > >> level 1 backup and dumped just changes (some megs, which is fine, my > >> bumpsize is 1MB). After that, Amanda made a level 1 with 175 GB > >> (WTF?). > >> > >> Is this as designed? Could one explain to me how Amanda works? I > >> really read many things about Amanda on Zmanda website and several > >> boards and I also follow this maillinglist for a while, but wether I > >> missed this information or I could not find it. I know that Amanda > >> decides by herself when she makes level 0 within the dumpcycle and > >> she always ensures that at minimum one is available. But why are > >> level >0 dumps sometimes the same size as a level 0? > >> > >> In my understanding Amanda should backup first a level 0 with 175GB > >> and then bump to level 1, as soon as the saved disk-space is more > >> than 1 MB (bumpsize). This will dump just a few MBs as the changes > >> on this DLE are really small and very rare. After that I would > >> expect that Amanda will make level 1 with very small amount of > >> data, as there again are practically no changes in the filesystem > >> (each level bumpsize will be multiplied with 1,5 in my case > >> (bumpmult)). But Amanda makes a level 1 dump again with 175GB!? > >> After that Amanda bumped to level 2, and dumped a few MBs (as > >> expected). But the next day a level 2 occurred with 175GB. This was > >> done also the next day: Level 2 with 175GB. > >> > >> I always thought, that dumps > level 0 are just incremental. Why is > >> that different in Amanda? What I would expect or what I want to > >> achieve is the following: > >> > >> Within 14 days I want to run dumps every day to backup as less as > >> possible the full DLE data (level 0) the other days I want to dump > >> just changes, as my DLEs change very rare and the changed data is > >> normally really small (I am backing up private data not in a > >> company). How can I achieve this with Amanda? > >> > >> I have about 21 DLEs with sizes between some MBs and 175GB and work > >> with 100GB vTapes. I tried to force Amanda to do smaller dumps by > >> setting runtapes to 2 or 3, but than Amanda moans that dumps are way > >> too big (of course they are, if Amanda makes that large level > >> >0's)... > >> > >> Any help will be appreciated. If necessary, please let me know which > >> kind of information you need for helping me. > >> > >> Thank you! > >> > >> Regards, > >> Thomas > > > > Your tar version(s) please? > > > > ISTR there was a tar problem that this resembles, back up the log a > > year or so. > > > > To use my /home as an example, it appears I never got past level 2 > > Aug 17 level 0 31612050 > > Aug 18 level 1 3347160 > > Aug 19 level 1 3389080 > > Aug 20 level 2 3352290 > > Aug 21 level 0 31476240 which is my dumpcycle > > > > But I had bumpdays at 2, which I just reduced to 1 and reduced some of > > the other settings so amanda could be a bit more aggressive in > > bumping levels. > > > > Perhaps Jean-Louis can clarify the tar version issue? FWIW mine is > > 1.26. ISTR 1.24 and 1.25 had issues. > > > > Cheers, gene > > My Tar versions are > > client: > root@SrvLinux1:~# tar --version > tar (GNU tar) 1.22 A rather short lived release, don't recall that I tested it.
> server: > root@srvlinux2:~# tar --version > tar (GNU tar) 1.25 This one is known bad, if possible update it to 1.26. > For bumping I use the following settings, which - I think - are the > reason why Amanda bumps more often here: > > bumpsize 1 mbytes # minimum savings (threshold) to bump level 1 -> > 2 #bumppercent 5 # minimum savings (threshold) to bump level 1 > -> 2 bumpdays 1 # minimum days at each level > bumpmult 1.5 # threshold = bumpsize * bumpmult^(level-1) Probably. I have also made mine a bit more aggressive. > My dumpcycle is 14 days and I run it every day currently with 50 tapes ل > 100GB max. 3 each run. > > My info for the DLE is a bit weird, as there are missing dates: > > Current info for srvlinux1 Bilder-Negative: > Stats: dump rates (kps), Full: 30672.3, 13901.7, 13933.9 > Incremental: 422.9, 19320.0, 18700.0 > compressed size, Full: 98.8%, 98.8%, 98.8% > Incremental: 7.3%, 7.3%, 7.3% > Dumps: lev datestmp tape file origK compK secs > 0 20110810 DailySet1-17 15 182991170 182991170 5966 > 1 20110813 DailySet1-22 14 182991170 182991170 6659 > 2 20110816 DailySet1-28 22 182991170 182991170 6701 > 3 20110821 DailySet1-1 3 183250010 183250010 9485 > 4 20110822 DailySet1-3 3 2960 2960 7 > > For example on 20th of August I got that line in my report (at this run, > Amanda bumped to level 3 and made an incremental): srvlinux1 > -r-Negative 3 0 0 -- 0:14 18642.2 0:03 87266.7 > > But there is no line in the info?! > > The day before I got an error of that DLE: > srvlinux1 Bilder-Negative lev 3 FAILED [too many dumper retry: > [request failed: timeout waiting for ACK]] [snip] > srvlinux1 Bilder-Negative lev 3 FAILED [service > /usr/lib/amanda/sendbackup failed: pid 2429 exited with code 1] > srvlinux1 Bilder-Negative lev 3 FAILED [cannot read header: got 0 > bytes instead of 32768] srvlinux1 Bilder-Negative lev 3 FAILED [cannot > read header: got 0 bytes instead of 32768] > I'm afraid I'd need more coffee before commenting on the rest of this. Sorry, it is late here. > Thank you! > > Cheers, > Thomas Cheers Thomas, gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) I don't have an eating problem. I eat. I get fat. I buy new clothes. No problem.
