Re: Perfomance problem backupscript (more details and tests)

Les Mikesell <[email protected]> wrote:

> tar -Gxpvf ../tar0.out
> tar -Gpxvf ../tar1.out
> cd ..
> diff -r test rest
> ---
> Mine are identical - rest/b and contents are gone, rest/e and
> contents are present.  And it would work the same if I let this
> test cross a mount point.  (And yes, on my distribution, probably
> one of the most popular in the world, /bin/tar is really gnutar).

I said that GNU tar fails with _simple_ test cases, but you did use 
an extremely trivial case. Just follow the instructions I did send a few days 
ago.


> > A few years ago, I did set up a testcase for ufsdump comparison between Solaris
> > and FreeBSD and I did run a GNU tar test for fun. The restore test failed with 
> > GNU tar. 
>
> Is it fair to compare this week's star against a few years's old gnutar?

Is it fair to try to reverse statements from other people?

I did always check the latest versionof GNU tar.

BTW: A fair comparison with GNU tar-1.15.1 (I did run my latest test in 
September 2004 with the GNU tar version that hase been the latest alpha)
would compare GNU tar-1.15.1 with the star that will be available in year 2018
as I did test a GNU tar version that has ben published 13 years after the
GNU tar incremental features have been introduced.


> > > 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?
> > 
> > There was of course ufsdump/ufsrestore since 1981.
>
> If you dumped from a ufs filesytem and restored to a ufs filesystem
> with exactly the same mount points.

ufsrestore restores to any POSIX filesystem.

Ufsump has been ported to many OS and filesystems.


> > How many real desaster recoveries did you do with the so created archives?
>
> I think there was only one that involved multiple level restores.  The
> amanda estimates allow it to bump the levels up/down according to what
> will fit on the tape so often you'll have a recent level 0 available
> if you allowed enough tape capacity to catch occasional large changes.
> I don't remember any particular real-world problems.

This answer is not related to the question. The question was related to the
reliability of GNU tar incrementals.


> > What do you do if thousands of sich replacements took place?
>
> It does seem to be fixed now, but if not I'd capture the error output to
> a file, convert the failed directory items to a script that removes
> those files, then repeat the restore.  I don't consider a file that
> is replaced by a directory to be any more likely than a directory
> being replaced by a mount point, and being able to restore the data
> after removing a file is much less of a problem than completely
> missing the contents of a mount point you expected to be traversed.

As the GNU tar maintainers did chose not to reply to my bug reports in 2004,
it cannot be fixed in an official release as the latest GNU tar release
is from December 21st 2004.

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]		(uni)  
       [email protected]	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily