Re: Perfomance problem backupscript (more details and tests)

On Wed, 2005-10-12 at 08:20, Joerg Schilling wrote:

> Looks like you did not understand the GNU tar incremental method either....
> 
> Please note that in case that inode numbers are not persistent, 
> a renamed directory with GNU tar (in case it works as advertized and does not
> show the bugs I reported) results in the following:
> 
> -	The old directory and its whole content is removed from 
> 	the restoreed filesystem.

The ONLY case where files are removed during a GNUtar incremental
restore is when the _name_ was not present in the corresponding
parent directory.  This has nothing to do with inodes or mount
points, only the name is involved.  (And hence the bug where an
existing directory is not removed if it has the same name as file
that took its place in a later incremental).
 
> -	As the new incremental backup is _missing_ the directory content
> 	(as it does not have a newer time stamp than the last backup),

I think the timestamp of a directory is irrelevant in
--listed-incremental mode and all contents are taken in any case where
the name/device/inode does not match. Regardless, a renamed directory
will have a newer ctime than the last backup anyway.

> 	GNU tar is unable to restore any of the files that are inside
> 	the renamed directory.

If the name/device/inode combination at the time of the incremental run
does not match one in the specified --listed-incremental file, all of
the contents are included.  If it does match, any files with a ctime
newer than that specified in the file are included.

> But if inode numbers are _not_ persistent, GNU tar will not include
> the content of a dir and thus fail the same way as star does.

If that has ever been true it was a bug, not the design.

> > Suppose you make a level 0 of a filesystem
> > containing / and /home, then mv a directory containing old files
> > from somewhere on /tmp to somewhere in /home (which amounts to a
> > rename), do an incremental, then restore these to a new machine
> > where / and /home are different filesystems.   I don't understand
> > how the old files under the mv'd directory will ever exist on
> > the /home filesystem.
> 

> But it should be obvious that both ufsrestore and star will not work
> this way but may be enhanced to do so by copying the renamed directory
> tree from one filesystem to another.

The point that it doesn't work is the relevant one and it is obvious
only to someone who already knows the issues of dump/restore.  When
doing a restore involving incrementals the operator _must_ know that the
mount topology is the same as the source.  In some cases as I have
already mentioned, arranging that might not be desirable, even if
possible.   

> > It would be really nice if star offered an option like GNU tar to
> > make incremental backups that are not limited to single filesystems
> > and do not require a restore of the previous, possibly unknown
> > named file to enable the restore of file renamed in the incrementals.
> > Then star could replace GNU tar as well as dump - and we could stop
> > talking about GNUtar bugs...
> 
> I am sorry, but this feature does not make sense as there are more
> important features waiting for an implementation _and_ as it is possible
> to handle your wishes by just using star the right way.

If I wanted a dump-like mechanism I'd be using dump.  I want to be able
to start at arbitrary directories, cross arbitrary mount points, use
arbitrary exclusion lists, and be assured that I can restore on
an arbitrary mount topology, possibly different from the source.
If you are unable or unwilling to provide those features, that is fine.
I am not trying to make demands here. But please stop trying to convince
me that those features are not generally useful or that I don't need
them or that there is no difference in the constraints.

There is a point to be made about the tradeoff between tape savings with
the star approach vs. ignoring filesystem boundaries with the GNUtar
approach.  It would be great to have a choice within the same program.

-- 
  Les Mikesell
   [email protected]