That said, backups taken on the same day with tar, I've seen include unchanged files before, but I've not seen it skip files it's not been specifically told to skip.
--On Wednesday, September 01, 2004 18:42 -0600 Bret Mckee <[EMAIL PROTECTED]> wrote:
[ 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
--
GPG/PGP --> 0xE736BD7E 5144 6A2D 977A 6651 DFBE 1462 E351 88B9 E736 BD7E