Re: Re: Perfomance problem backupscript (more details and tests)

On Thu, 2005-10-06 at 06:14, [email protected] wrote:

> as we are discussing incremental backups :
> 
> Do i perceive it right that both star and GNU-tar rely on
> the persistence of inode numbers within filesystems ?

I think star relies on unix-like filesystem.  Tar does
use device/inode combinations to track directories
traversed by the full runs.

> Googling for "tar" "listed-incremental" i find problem
> reports about VFAT filesystems which obviously do not
> preserve inode numbers after umount. There seem to be
> similar problems with SMBFS. Not to speak of FAT.

I don't think it's obvious at all that inode numbers
would change if you mount/unmount a device even if
they are faked by computation.  Does this only happen
if you remove a device, mount it elsewhere and modify
it, then remount in the original location for the
gnutar incremental or does it happen on any remount.

> > Les Mikesell wrote :
> > and it seems there is no other choice.
> 
> One of my own methods for incremental backup resembles 
> the approach of an intrusion detection system rather than
> to rely on the intestinies of particular filesystem types.
> I.e. there is a tree model of the backup area with
> name and checksum of each single file.

On unix-like filesystems with valid ctimes all you need
is the ctime of ordinary files since that catches any
possible change - including ownership and permissions
which your method appears to miss.  The problem is a
renamed directory containing old files.

> This is darn slow in comparison to an inode-number check,
> but it is not bound to full featured Unix filesystems
> and it is not affected by filesystem boundaries.

Actually, my first choice in backups these days is
backuppc http://backuppc.sourceforge.net/ which
can use several methods including rsync to transfer
the copy and keeps compressed copies online with hardlinks
for all duplicates so you can store about 10x what you
would expect.  However, because of the hardlink requirement
it only works with disk storage and I still keep amanda
running for offsite tape copies.

> (Thanks to inspiration by star, i added an alternative
> inode-number check which runs fast and reliable on ext2
> and reiserfs. Other types have still to be evaluated
> but i guess it is ok with most locally attached 
> filesystems on Linux.)

Any filesystem with native unix semantics must have
fixed inodes and the ability to create hardlinks by
having any number of directory entries pointing to the
same inode.  Backup methods must be able to re-create
these hardlinks - which isn't easy because all they
have in common is the inode number.

> Nevertheless:
> Can it really be that the big archive programs ignore the
> existence of filesystems which do not comply to the
> inode-semantics of classical Unix ?

Tar only cares if you do --listed-incrementals, and then it
only cares that the directories have the same inode
number on each pass (or the fake computed equivalent)
for the directories.  If they don't match, the failure
mode is to copy everything which is probably the best
way to fail.

> Shouldn't there be some fallback provided in order to
> handle such cases ?

If the filesystem in question doesn't provide any way
to tell what has changed, there's not much hope for
a good incremental method.  But, since disk space has
recently become cheap, doing an rsync against an
on-line copy of the prior full is a practical alternative.

> The ctime trick of my current Linux ext2 is a nice try 
> but i am sure that it can be fooled by using other 
> operating systems (or just other Linux versions) on the 
> same filesystem.

All unix filesytems have ctime values that are updated
with any inode change.  Changing the files contents
requires mtime to change, mtime is stored in the inode
and thus the change requires ctime to change.  That is,
ctime is not a trick, it is the specification of the
filesystem.

> On my SuSE 9.0 the situation is nicely mixed :
> 
> mv changes ctime on ext2 but not on ReiserFS.

ReiserFS doesn't completely follow unix semantics.

> man 2 stat still says :
> "The field st_ctime is changed by writing or by setting
>  inode information (i.e., owner, group, link count, mode,
>  etc.)."
> The name of a file is not an inode information.
> Renaming of files is rather covered by :
> "Moreover, st_mtime of a directory is changed by the
>  creation or deletion of files in that directory."
> 
> The ctime-quirk seems to be dependend on the type of
> filesystem and on the version of Linux. It has been
> patched into the code without revising documentation.
> It might get patched out of the code as well.
> http://sourceforge.net/mailarchive/forum.php?thread_id=3726620&forum_id=6379 :
> "Unfortunately, however, the change was not pushed
>  into 2.3, and so 2.4 and now 2.6 have a ext2 rename()
>  implementation that does not update inode ctime."

Rename is kind of a special case.  The inode in question
doesn't necessarily change because a directory entry pointing
to it changes.  Most implementations would do it by creating
a new link with the new name, then removing the old one, and
changing the link count in the inode requires a ctime change.
However, this is an atomic operation done with the inode
locked so other processes will only see one name or the
other, so I can see where taking a shortcut that leaves the
net link count unchanged might be legal.

> On one hand it is pleasant to see that my first approach
> is still the only one that covers all filesystem types
> and mount situations. 

Do you catch other inode-only changes (owner/permissions, etc.).
Can you reconstruct hard links? 

> On the other hand it is unsatisfying that i cannot
> advise the much faster inode method or even a merely
> time based method as general default.
> 
> So, if somebody could refute my above considerations,
> i would be 50% sad and 50% happy.

Rsync against a complete on-line copy should always
be able to detect any change...  And backuppc can do
it against compressed copies.

> Is my understanding of star correct that in this case
> it only records the directory with its pairs of names and inodes
> but not the files' content (which is unchanged) ? 
> That at restore time, the content already got restored by
> a previous level and then gets attached to these newer
> directory entries ?
> 
> If so, then it is as elegant as it is daring.

Dump/restore used the same technique forever, but it is
fairly intimate with the filesystem and it will fail
horribly if you convert a directory to a mount point
between runs.

-- 
  Les Mikesell
   [email protected]