Andreas Dilger <adil...@dilger.ca> wrote:
> Keep your old snapshot around after you create the new one, and run "stat(1)"
> on the same file in both snapshots to see if there are any other differences
> besides the device number that may be causing tar to think the file changed.
gtar likes to implement something that is in conflict with a reliable
filesystem backup. It tries to support directory trees without looking at mount
point limits. This requires to look at both, stat.st_ino and stat.st_dev, since
inodes are unique only on a single filesystem.
Reliable filesystem backups on the other side need to be based on snapshots an
snapshots need to create ephemeral st_dev values in order to create the
appearance of a different filesystem with POSIX semantics.
This does not work well together...
Please have a look at star's incrementals. There are examples that are
currently starting at page #55. Examples for incrementals are in the section
INCREMENTAL BACKUPS that currently starts at page #50.
http://schilytools.sourceforge.net/man/man1/star.1.html
Note that star's incrementals are smaller than what you get from gtar:
If you have a full 1TB disk with a single directory tree in it's root directory
and rename the top level diretory just under the root, you end up with a 10 kB
star incremental.
The same done with gtar needs 1TB of backup space and you would even need a
2 TB disk to be able to restore the incremental.
BTW: currently sourceforge again tells me since half an hour that it is under
maintenence that will end in 10 minutes :-(
So be a bit patient when trying to access the man page.
Jörg
--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
