On Monday, August 22, 2011 07:59:02 AM Thomas Marko did opine: > Am 21.08.2011 um 18:17 schrieb Jon LaBadie: > > On Sun, Aug 21, 2011 at 07:47:59AM +0200, Thomas Marko wrote: > >> 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)... > > > > Thomas, > > > > Assuming you are using gnutar for backups I ditto Gene's comment about > > checking the archives for similar problems. ISTR that there were some > > situations that could cause tar to think the dumps were coming from a > > different device. So to tar, a file was deleted and even though it > > was the same name, as it was on a "different device", it was a new > > file. > > > > Typically, if a dump at an incremental level were going to be so large > > and so similar to a level 0 dump, amanda would do a new level 0 dump. > > Without guessing at its cause I think your "uber-strange" behavior of > > not returning to level 0's is being caused by the cycle of 1 day of > > normal incrementals at each dump level and the forced remaining at > > that level by the default "bumpdays 2". > > > > I suspect that if you set bumpdays to 1 you would see alternating days > > of level 0,1,0,1,0,1 ... Still not good, but simpler to analyze and > > state the problem; > > > > Why does gnutar think all of your files have changed? > > > > I think gnutar uses a combination of factors to decide if a file has > > changed. I'm sure one factor is the file time stamps, notably data > > write and inode change times (as shown by ls -l and ls -lc). Might > > you have an 'every other day cronjob' that does something with each > > file on that DLE? > > > > As noted above, changed devices could affect it also. Might that > > DLE reside on an external media such that when you reboot or mount > > and unmount the media could assign different device ids? > > > > Jon > > Hi Jon, > > my answer to regarding versions see my last posted answer to Gene. > > I checked the file dates with "ls -lcR |grep 2011-08-[12]" and "ls -lR > |grep 2011-08-[12]" and just got a handful of hits (max 250 MB, dated > on 16th of August). So the changes are really small compared to the DLE > size of 175 GB. > > My actual bumpdays is set to 1! The "funny" thing is, that Amanda does > level 0, but states them as level >0. > > Some facts about the DLE: > > The DLE is a subdirectory of a mounted LV (LVM2) part of a PV configured > as RAID1: fstab: /dev/Store01-Data/Bilder /storage/bilder ext3 > suid,exec,nodev,user_xattr 0 0 > > There is no local access to this DLE (except me, because I'm root, I'm > allowed to do that ;-). Users (me and my wife ;-) normally access data > through CIFS (Samba 3.4.7~dfsg-1ubuntu3.7) and through AFS (Netatalk > 2.0.5-3). > > IDs should not change here. Maybe GNUTAR is the problem. But is it the > version on the server (1.25) or on the client (1.22)? > > Thank you! > > Cheers, > Thomas
At this time, I can recall seeing that, and it took tar-1.26 to fix it, which has been out for quite a while now. However ISTR there was a change needed in amgtar or its config stanza in amanda.conf at about the same time. I expect I am running much newer versions of amanda than most as I build the latest from the zmanda site, so I have been running Amanda version 4.0.0alpha.svn.4275 for 2 or 3 weeks now. I sort of play the canary in the coal mine part here since at my age (77 in Oct) I don't feel qualified to do more than walk around in the code kicking the tires at best. So I test & report, and have not had anything bad to report in several months. OTOH, I have maximum dle sizes in the 25Gb range, much smaller than Thomas. Cheers, 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) * CosmicRay wishes he had some strippers here.... <CosmicRay> err, wire strippers
