Conrad and David,
thank you very much for your replies. I upgraded to tar 1.13.18, but
even this newest version does not remedy the problem of incorrect
computation of incrementals on mounted vfat filesystems on my AMANDA
server.
I think the time of truth has come: AMANDA *cannot* backup Windows
filesystems correctly, contrary to the many claims to the opposite! It
will *not* compute incrementals correctly. This is something that those
who evaluate it as a possible candidate for Linux _and_ Windows backups
should seriously take into account. I have been struggling with this the
past six months without success :-(
Consider the following situation: you try to minimize the Windows
footprint on your network. You migrate to Linux and SAMBA. Windows is
run only on the clients: all your data and applications are on the vfat
filesystems of the SAMBA server which runs Linux. Now you want to back
all this up. Your backup server is the SAMBA server itself, running
AMANDA. There are Linux filesystems on the server, Linux filesystems on
the Linux clients, vfat filesystems on the server and vfat filesystems
of the Windows clients. The clients with the vfat filesystems run on
Windows, the server runs on Linux. You don't care that much about the
vfat files on the Windows machines, because these are easily reproduced.
You *do* care about your data and apps on your Linux server, be it ext2
or vfat.
In this situation, AMANDA will *fail* do do its job for the vfat files
on the server! The incrementals on these files may (or will) be computed
wrongly. They may (or will) be almost as large as full backups, taking
up so much space on your tapes, that almost all of the other full
backups will be delayed, or not done at all. Of course, you can increase
your dumpcycle, use larger tapes etc., but this is almost equivalent to
doing full backups of all vfat filesystems every day! No matter how you
declare the files in the disklist, the SAMBA way (i.e. as shares
exported from the SAMBA server), or the "usual" way (i.e. as mounted
filesystems on the server) the result is the same: maybe that the vfat
files on the boxes running Windows are backed up correctly, but the vfat
files on the box running Linux (your SAMBA and AMANDA server) will have
their incrementals computed incorrectly. And those are your most
important files! At least this is the case with the latest (1.13.18) and
some older (1.12) tar version.
Now, JJ will say "this is tar's problem" and will be in principle
correct. tar's developers will say "this is vfat's problem due to its
lack of inodes" and will be in principle correct. Me, as an AMANDA user
who likes it because of its integrative capabilities, will say "I don't
care whose problem it is, I just see that it is so simple (every backup
program can compute incrementals correctly) and it still cannot be
solved with AMANDA". I understand that it is a design issue: AMANDA
wants to be independent of the way the estimates are done. But in this
case it becomes dependent on tar, or the Linux kernel. And even if I had
written *the* correct estimator, I would not be able to tell AMANDA to
use it. So I will have to rely on native Windows backups for the vfat
filesystems on the AMANDA server - saying goodby to simplicity :-(
Comments and workarounds are very welcome.
--
Regards
Chris Karakas
Don´t waste your cpu time - crack rc5: http://www.distributed.net
Conrad Hughes wrote:
>
> >>My suspicion is that GNU tar, which I use in the version 1.12, somehow
> >>cannot compute incrementals right, for filesystems of vfat type that
> >>are mounted the way I described above...(?)
>
> >Even RedHat have a later version of GNU tar than 1.1.2 and (honestly)
> >they're not known to release the latest versions of programs. Upgrade
> >tar to at least (GNU tar) 1.13.17; the ones below this are likely to
> >cause all sorts of weird problems.
>
> I'm using 1.13.17 and have the same problem: incrementals on vfat just
> don't work, they're effectively the same as full backups. tar seems to
> think that every file has been modified since the last backup.
>
> Searches elsewhere suggest that it stems from a rewrite of the kernel
> vfat support between kernels 2.10 and 2.11, but I couldn't find a
> solution mentioned anywhere (*). It's very frustrating. If anyone else
> has an idea what to do I'd be ecstatic: this added hours to my daily
> incrementals until I just gave up on backing up Windows.
>
> Conrad
>
> * If I understand correctly (and there's no guarantee that I do), the
> vfat change was to ensure that a file on a vfat FS would have the same
> inode number for the duration of a single mount; inodes need to be
> constructed in some manner on vfat because it doesn't actually have
> real inodes, and the previous mechanism meant that a file's inode
> wouldn't be constant (for example a rename would change it; this
> caused much gnashing of teeth among one crowd of people). This new
> mechanism means inodes are fixed for the duration of a mount, but if
> you umount and remount then you have no guarantee of continuity; this
> is now causing gnashing of teeth amoung another crowd. Since tar
> --listed-incremental seems to record inodes, it gets very confused if
> the machine umounts and mounts a vfat system between backups (as would
> inevitably be the case if you rebooted for example).
