Charles,

It looks to be a bug in gnutar, I sent a bug report to bug-...@gnu.org 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 bug-...@gnu.org

Jean-Louis

________________________________________
From: owner-amanda-us...@amanda.org <owner-amanda-us...@amanda.org> on behalf 
of Charles Stroom <char...@stremen.xs4all.nl>
Sent: February 13, 2018 4:28:02 PM
To: amanda-users@amanda.org
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

Reply via email to