Jon and Paul, many thanks for your suggestions. I started off looking at the gnutar-lists directory and found many entries dated from before my cleaning operation (that included as per FAQ "reset its databases so as to start from scratch"). So I reset it again and emptied also the gnutar-lists. I started with a reduced disklist (3 DLEs) and found evidence that it had cured the problem. Reset again. However, after the first full backup, the 2nd was wrong again.
Considering the suggestion that something looks at my files, thereby modifying [a|c|m]time and the only one I could think of was updatedb (apart from the nsa of course), I did an immediate 3rd backup after the 2nd, but this was also wrong with level 1 dumps equal in size to level 0. Nevertheless, I have disabled the updatedb, and see to the results tomorrow. But I did also do a check on the ctime of 1 of the Pictures* DLE's and in fact ALL ctimes are "2014-02-03" the date when these files were copied over from the previous installation. I suspect the fault is somewhere else. To be continued. Regards, Charles On Sat, 22 Feb 2014 12:10:44 -0500 Jon LaBadie <j...@jgcomp.com> wrote: > On Sat, Feb 22, 2014 at 12:52:28AM +0100, Charles Stroom wrote: > > Hi all, > > > > on 20 Feb, I have been running my first backup after cleanup the > > test results (amanda 3.3.5 compiled on opensuse 13.1). As > > expected, the 13 DLEs were all level 0, exceeded the capacity of my > > DDS4 backup tape and I needed 2 flushes to get it all on tape. > > Below the dump summary of the backup (not the 2 flushes): > > " > > DUMP SUMMARY: > > DUMPER > > STATS TAPER STATS HOSTNAME DISK L ORIG-KB > > OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s > > --------------------------------- ---------------------- > > --------------- ------------- fiume.localnet Hobbies 0 > > 3087140 2759002 89.4 4:59 9236.7 19:55 2308.8 > > fiume.localnet Homes 0 2289630 1800945 78.7 5:35 > > 5369.9 13:01 2305.9 fiume.localnet Mail 0 2377330 > > 1588938 66.8 5:52 4514.8 fiume.localnet Pictures_800IS 0 > > 6926780 6926780 -- 8:11 14107.1 50:01 2308.2 > > fiume.localnet Pictures_G2 0 6293540 6293540 -- 5:01 > > 20878.2 45:27 2307.9 fiume.localnet Pictures_rest 0 5069670 > > 5069670 -- 4:39 18179.6 fiume.localnet Vbox-1 0 > > 7508010 5594805 74.5 30:37 3045.3 fiume.localnet > > Vbox-2 0 2217880 1443700 65.1 2:52 8374.1 1:58 > > 0.0 PARTIAL fiume.localnet Wine 0 2152670 1378210 > > 64.0 2:58 7737.9 10:30 2187.6 fiume.localnet home-charles > > 0 6285690 3907741 62.2 10:26 6241.5 fiume.localnet > > root 0 599840 250596 41.8 0:44 5676.4 1:48 > > 2320.3 fiume.localnet usr 0 5742500 2321579 40.4 > > 8:34 4517.0 stremen.localnet my_data 0 764860 398956 > > 52.2 3:18 2011.5 2:57 2254.0 > > > > (brought to you by Amanda version 3.3.5) > > " > > > > On 21 Feb, the second backup was done and it did 3 level 0 backups > > and 10 level 1 backups. Dump summary below: > > " > > DUMP SUMMARY: > > DUMPER > > STATS TAPER STATS HOSTNAME DISK L ORIG-KB > > OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s > > --------------------------------- ---------------------- > > --------------- ------------- fiume.localnet Hobbies 1 > > 3087140 2759006 89.4 4:53 9411.3 fiume.localnet > > Homes 1 2289630 1800949 78.7 4:38 6472.8 13:00 > > 2308.9 fiume.localnet Mail 1 2378930 1589378 66.8 > > 7:36 3482.4 fiume.localnet Pictures_800IS 1 6926780 6926780 > > -- 5:43 20218.3 50:01 2308.2 fiume.localnet Pictures_G2 1 > > 6293540 6293540 -- 5:13 20099.0 45:26 2308.7 > > fiume.localnet Pictures_rest 1 5069800 5069800 -- 4:36 > > 18371.0 fiume.localnet Vbox-1 1 10 1 10.0 > > 0:00 4.8 0:00 0.0 fiume.localnet Vbox-2 1 > > 2217880 1443700 65.1 33:19 722.4 fiume.localnet > > Wine 1 2152670 1378212 64.0 3:04 7471.0 7:10 > > 0.0 PARTIAL fiume.localnet home-charles 0 6182340 3827321 > > 61.9 9:29 6724.5 27:51 2290.4 fiume.localnet root > > 0 596290 247471 41.5 0:44 5611.9 2:22 1742.8 > > fiume.localnet usr 0 5742630 2321781 40.4 8:44 > > 4429.8 stremen.localnet my_data 1 25230 3851 15.3 > > 0:10 401.3 0:02 1925.5 > > > > (brought to you by Amanda version 3.3.5) > > " > > > > This looks fine, but is not. ALL level 1 backups have identical > > size as the level 0 backup done the day before with 2 exceptions: > > Vbox-1 and my_data. This is total nonsensical, the 3 Pictures* > > DLEs have not been used/modified and the level 1 should have a size > > near zero. Except my_data, all fiume DLEs use the same dumptype, > > although Pictures* have an additional "compress none". > > > > I do not think there is even an option which rules level 1 (or any > > level) behaviour, so what is wrong? Is this a tar problem? I have > > never had these problems with 3.3.1 in opensuse 11.4 (my previous > > version). > > > > Any advice appreciated and of course I can provide more > > details/logs. > > Guessing only. tar "could" look at 3 things to determine if a file > needs to be incrementally backed up; file size, last modified time, > and last inode change time. I don't think size comes into play. > > So we are left with last data modification (mtime) and last inode > modification (ctime). > > You may have a process that runs daily looking at your files. That > modifies data access time (atime) but does not affect mtime. However, > as atime is stored in the inode, it does affect ctime. Thus tar > will back up the file because its inode changed. > > There is a mount option, "noatime", to prevent modification to atime. > Some administrators set this option in the "mount options" field of > the /etc/fstab file. > > Another possible mount option is "relatime". This will only modify > atime if mtime is also being modified but will generally leave it > alone. > > Jon > -- > Jon H. LaBadie j...@jgcomp.com > 11226 South Shore Rd. (703) 787-0688 (H) > Reston, VA 20190 (609) 477-8330 (C) -- Charles Stroom email: charles at no-spam.stremen.xs4all.nl (remove the "no-spam.")
