Charles, It looks to be a bug in gnutar, I sent a bug report to [email protected] but I got no reply. http://lists.gnu.org/archive/html/bug-tar/2018-02/msg00000.html
You could try an older version 1.12, 1.13, 1.14 Or the patch I posted to [email protected] Jean-Louis ________________________________________ From: [email protected] <[email protected]> on behalf of Charles Stroom <[email protected]> Sent: February 13, 2018 4:28:02 PM To: [email protected] Subject: Re: again level 1 backup problems. To sum up the problems I have had: I have now a properly working amanda working with my pictures directory divided over 5 disks defined in the disklist, that all resides on a Windows formatted separate disk. I have done a number of tests with all kind of variations on my vfat disk, but I couldn't get a handle on what or where the problem is. Level 1 backups are totally wrong, because they are in all but 1 case either full backups or very sizeable backups while they should be near 0. And then they were also different in size (that is unpredictable) in a next level 1 run and all this on a directory tree in which no changes were made between the test runs. The culprit seems to be the vfat disk which holds the directory, because when I copy the pictures directory to a linux ext4 partition, everything works just fine, including proper level 1 dumps. As variations I have done (all with a vtape test setup): - running on a read-only mounted directory and actually checked date/time settings with a find (for recently changed files) after a level 1 amdump: failed although there was no change in file times. - running with program "GNUTAR" with an empty gnutar-list-dir definition or with one: failure - tested each defined disk separately: failure for each with consistently 1 exception: de Pictures_M10 behaved as should. - level 1 for Pictures_M10 backups are ok, both for a no changed directory or with some test files added. I could not find any reason why this disk was different from the others. - However when I amdumped another disk together with the Pictures_M10 disk, both failed. - actual precise amdump results can vary for the same disks over time. - tested with tar 1.27 and tar 1.30: all fail - with or without the property "CHECK-DEVICE" "NO" in amgtar: no difference and then I have probably forgotten some variations. It seems that amanda (or probably tar?) does not produce the correct information to perform a level 1 backup. I have looked to find the details about what type of info amanda (time info of files and/or directories, size, etc?) is using to create the tar info, which I suppose goes into the files in the gnutar-lists directory. These are binary files, which makes investigation difficult (for me). So I have given up on the vfat format. But as it is claimed that amanda also runs on Windows, how does it works in Windows on vfat format? Anyhow, I then decided to reformat my picture disk to ntfs and see what that would deliver. In a first test, level 1 was a near 0 size dump, so everything seemed ok. However when I added a few large files, level 1 remained 0. It seemed an inverse problem. But then I noticed that only accessing a file did not only change atime, but also ctime equally. I remounted the picture disk with a noatime option added to the mount and this now solved all problems. In hindsight, I should have tested that option as well with the vfat disk, but when I tested file times after an amdump on vfat , I noticed no time changes at all. So noatime on vfat would probably not have solved the problems. The ntfs disk is mounted as: /dev/sdc1 /home/charles/pictures ntfs-3g \ defaults,uid=1000,gid=100,umask=0022,nofail,noatime,rw 0 0 Cheers, Charles -- Charles Stroom email: charles at no-spam.stremen.xs4all.nl<http://no-spam.stremen.xs4all.nl> (remove the "no-spam.") This message is the property of CARBONITE, INC. and may contain confidential or privileged information. If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone. Instead, destroy it and notify me by reply e-mail
