Re: Perfomance problem backupscript (more details and tests)

On Wed, 2005-10-05 at 19:18, Joerg Schilling wrote:

> > > This is with gnutar 1.13.25.
> >
> > I just reported a bug in incremental restore in 1.15.1.  I would suggest
> > that you upgrade to 1.15.1 if you want to trust gnu tar with incrementals.
> > The restore problem I found manifests itself by leaving certain files
> > around after the restore (it fails to delete symlinks that don't point to a
> > real file).

Are these created in --listed incremental mode?

> 
> There are many other problems with incrementals using GNU tar.
> GNU tar does absolutey not grok the case when a directory is renamed......

You must use --listed-incremental mode (which amanda does).  Can you
show a test case where this fails?

> it also does not work with old Linux versions that do not touch the
> ctime of a file in case it is renamed. Star is happy in case the
> mtime of the related directories are touched.

Ctime by definition is the time of the last inode change.  Changing
mtime _must_ change the inode, thus ctime is required to change.  I'm
not particularly interested in accommodating broken operating systems.

> GNU tar incrementals have been created 12 years ago but none of the bugs have 
> been fixed until very recently (past 1.15.1). This is why I don't understand the
> amanda people.

What bugs, and what other choice have they had for the last 12 years.
What choice do they have now for incrementals on backup runs that
cross filesystem boundaries?

> With star, I make an incremental backup _and_ restore every night for Berlios
> since a year.

I've been using amanda/gnutar for 10 years or so.  I'd be happy to
find a better alternative, but I don't see any other choice that
will schedule the right mix of many fulls and incrementals to fill
the tapes and also get the right files in the incrementals.

>  So far we had three problems that all have been fixed and the last
> problem is more than half a year ago. For your notice: 170 GB FS space is backed
> up incrementally. Every night approx. 10 GB change and a few thousand 
> files/directories are renamed or removed. The last bug (the one that caused a 
> problem on February) has been fixed on June 8th. Since then, I completely trust
> incrementals with star.
> 
> Note that I know of no case where people did run similar tests with GNU tar.
> Making incremental backups does not show you the problems you get with 
> incremental restores.......

The only bug I've ever seen is that if an ordinary file is removed and
replaced with a directory of the same name between a full and subsequent
incremental run, the incremental restore of the directory will fail. 
This is not fatal, though, since you see the error and can still
manually remove the directory and repeat the restore successfully.  And
this was some time ago - it may be fixed now.

-- 
  Les Mikesell
    [email protected]