0
mkdir test
echo "hi" > test/file1
tar -c -f archive.0.tar -g test.snar test
touch -a test/file1  # changes atime and ctime, doesn't change mtime
tar -c -f archive.1.tar -g test.snar test
tar -t -G -vv -f archive.1.tar  # lists Y for file1

So did GNU tar store the entire file again, even though only access time (atime) and metadata change time (ctime) were changed? This seems horribly inefficient to me, as we can reasonably expect many files to be read but not changed.

1 Answer 1

1

Using gtar for incremental backups is unreliable, but this is not a result of handling time stamps incorrectly.

Any backuptool that works in userland and thus cannot check internal filesystem structures as done by e.g. zfs send needs to handle time stamps the same way or it cannot grant a correct incremental backup.

  • atime is irrelevant for backups since it is only a hint that the file has been read, but not whether the file has been modified.

  • mtime may look interesting from the first view, but is irrelevant as well. This is because the mtime of a file can be set to any value by user space programs.

  • ctime is the only important time stamp for incremental backups as this is the only time stamp that cannot be manipulated.

As ctime cannot bemanipulated and as ctime is updated for both, content and meta data change, a backup tool needs to archive the file content and the file meta data whenever ctime has been updated.

As a result, a file that apparently did not change mtime could still have a modified content and thus needs to be in the backup

Finally: GNU tar does not implement a method, you asked for. The behavior is hard coded.

star however offers the option -dumpmeta that has been created in 2004 in order to experiment with inremental backups. star however clearly warns to use this option, see the man page:

-dumpmeta changes the behavior of star in incremental dump mode. If -dumpmeta is used and only the inode change time (st_ctime) of a file has been updated since the last incremental dump, star will archive only the meta data of the file (e.g. uid, permissions, ...) but not the file content. Using -dumpmeta will result in smaller incremental dumps, but files that have been created between two incrementals and set to an old date in st_mtime (e.g. as a result from a tar extract) will not be archived with full content. Using -dumpmeta thus may result in incomplete incremental dumps, use with extreme care.

The method used by star by default is used by ufsdump and ufsrestore from around 1981 and this is the method used by star since February 2005 and there has never been a problem with restoring incremental backups using these programs.

3
  • 1
    The downvoting trolls are active again and downvote a 100% correct answer.
    – schily
    Jul 11, 2020 at 15:22
  • I think my question was really: can GNU tar save only the difference in metadata instead of the whole file again?
    – qwr
    Jul 11, 2020 at 20:34
  • Ok, I added a related hint to the answer
    – schily
    Jul 12, 2020 at 13:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .