[ Sorry if this message shows up twice.  I sent it this morning, and
realized when it didn't show up that I was not longer a subscriber of
this list...]

Greetings:

I installed amanda and believe I have everything running.  I am using
the disk based virtual tape driver and everything seemed fine.

I did the first backup, and of course it did a level 0. I then did a
second backup and it did a level 1 backup.  Because I have a large
/home disk, I back up all the users directories separately.

My home directory (/home/mckee) is about 5GB, and the level 0 seemed
large enough to have gotten to it all.  The level 1 backup was run
almost immediately (as part of testing the new install), and virtually
nothing changed. I was really surprised to see that the level 1 was
about 500Mb or 10% of the level 0 (I had expected it to be much
smaller).

First, a bit of version information:
$ uname -a # I'm running RH Enterprise ES
Linux hostname 2.4.21-15.ELsmp #1 SMP Thu Apr 22 00:18:24 EDT 2004
i686 i686 i386 GNU/Linux

$ tar --version # And because it might matter:
tar (GNU tar) 1.13.25

amanda, unpacked from:
-rw-rw-r--    1 mckee    mckee     1383528 Jun 22 06:50
amanda-2.4.4p3.tar.gz

I used amrestore | tar -tv to get a list of the files in the level 0
and
level 1 archives, and discovered that several things that almost
certainly
had not changed were backed up. I then went and read all about gtar's
--listed-incremental mode and *think* I understand it (famous last
words :-), and I still can't explain why these files were backed up.

Picked as an example, one file that didn't change but that was backed
up was: /home/mckee/proj/proj-2.3/client/pubring.gpg

which was backed up relative to /home/mckee as:
./proj/proj-2.3/client/pubring.gpg

Trying to figure out why it got backed up, I looked in the gnutar-list
files for the path to both files:

hostname_home_mckee_0:26641 31851568 ./proj
hostname_home_mckee_1:26641 31851568 ./proj

hostname_home_mckee_0:26641 4637093 ./proj/proj-2.3
hostname_home_mckee_1:26641 4637093 ./proj/proj-2.3

hostname_home_mckee_0:26641 37028138 ./proj/proj-2.3/client
hostname_home_mckee_1:26641 37028138 ./proj/proj-2.3/client

Note that device/inode didn't change for any of the directories in the
path (which would have triggered tar to back up the files)

Here are the entries for the tar -tv output, and again the dates/sizes
didn't change:
mckee.list.0:-rw------- root/root           1692 2004-03-23 10:04:03
./proj/proj-2.3/client/pubring.gpg
mckee.list.1:-rw------- root/root          1692 2004-03-23 10:04:03
./proj/proj-2.3/client/pubring.gpg

I'm looking to understand this behavior, both because it is a waste of
tape
(even virtual) to backup unchanged bits and because I can't help
wonder
if some files are not being backed up at all (i.e. if it doesn't
correctly
decide what to back up, it could easily be missing files too).

If anyone can explain this behavior, or if you need additional
information to try and explain it, please let me know.  I have also
submitted this to the GNU tar list, since it seems fairly likely it is
really a tar problem...

Many thanks in advance,

Bret

--