Re: : [Bug-tar] Trying to figure out why unchanged file gets backed up in level 1 backup

[Martin Simmons]

>>>>> On Wed, 1 Sep 2004 16:46:35 -0600, "Bret Mckee" <address@hidden> said:

  Bret> I'm having a problem with incremental backups.  I'm using amanda to
  Bret> manage the backups, but this looks like a  gnutar issue to me.

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

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

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

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

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

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

  Bret> Picked as an example, one file that didn't change but that was backed
  Bret> up was:

  Bret> /home/mckee/proj/proj-2.3/client/pubring.gpg

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

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

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

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

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

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

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

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

  Bret> If anyone can explain this behavior, or if you need additional
  Bret> information to try and explain it, please let me know.

Maybe the ctime on the file changes (check with ls -lc)?

__Martin