Re: Perfomance problem backupscript (more details and tests)

Les Mikesell <[email protected]> wrote:


> > > GNU tar does it about the only way possible that
> > > permits backing up arbitrary directories where the recursion crosses
> > > mount points and that allows multiple backup sets, each with their
> > > own concept of when the prior run was done and, of course, catching
> > > old files that are now under renamed directories compared to a prior
> > > run.  It works with amanda and does what I like (the backup is correct),
> > > and it seems there is no other choice.
> > 
> > In theory this could be done with star too, but I am not sure whether this
> > makes sense. 
>
> The part that makes sense is that you can make only one set of
> regular backups  (or a pair so one can go offsite), and decide
> later whether the use is to do a disaster recovery to an exact
> clone of the old machine or a portable archive of data that
> can be restored onto something entirely different.

I don't really undrstand you!

As you may do exactly what you like using star, wher is your problem?
You just need to make one separate backup for every of the related 
filesystems.


> > First star-1.5-final needs to be published to have a "stable" alternative to
> > ufsdump/ufsrestore, then I would need to check what people like to do with
> > their backups..... The star archive format definition allows to store enough
> > information so that in theory a backup (that crosses mount points) could be
> > done. For the restore, the database format would need to be enhanced but this
> > is a transient format anyway.
>
> There are tradeoffs either way.  I can understand not supporting it
> even if it means you can't restore onto a different topology, but
> the drastic difference in modes needs to be clearly documented.

Star can do it already, you of course need to try to understand how to do it
or use a backup control software that knows how to do it.


> > But the problem is that GNU tar claims to support this kind of backups but
> > has too many bugs with incremental backup/restore to make it useful. 
>
> Either gnutar doesn't like you or the OS you are using or you
> are going out of your way to find broken versions. Or the bugs
> are patched in the distribution packages I run. So far I can't
> duplicate any of your claimed bugs.

It seems that you just ignore my proof for the bug.


> > gtar -cf /dev/null --totals -S sparsefile 
> > gtar: sparsefile: Cannot seek to 0: Bad file number
> > Total bytes written: 153600 (150KiB, 59MiB/s)
> > gtar: Error exit delayed from previous errors
> > and BTW:
> > gtar -cf /dev/zero --totals -S sparsefile 
> > Total bytes written: 71680 (70KiB, 2.1MiB/s)
> > 
> > This is 1.15.1
>
> The only 1.15.x I have is on fedora FC4 (with current updates)
> #rpm -q tar
> tar-1.15.1-10.FC4
> # ls -l lastlog
> -rw-r--r--  1 root       root    19136220 Oct  9 17:56 lastlog
> # tar -cf /dev/null --totals lastlog
> Total bytes written: 19138560 (19MiB, ?/s)
> # tar -cf /dev/null --sparse --totals lastlog
> Total bytes written: 10240 (10KiB, ?/s)
>
> No errors - correct looking results...

You seem to be a funny person.

You refuse to use recent star versions but on the other side, you
try to argue with GNU tar versions that have not yes been published but
that are onviously made from _unpublished_ internal developer versions.


Could you try to be a bit more fair in future please?



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