Re: Perfomance problem backupscript (more details and tests)

On Thu, 2005-10-06 at 04:48, Joerg Schilling wrote:
> >
> > A lot of things are done in strange ways, but after the infrastructure
> > around them is added it becomes counterproductive to invent arbitrarily
> > different ways, even if some people think they are less strange.
> 
> I would love if you could tell this to the Linux Kernel developers ;-)

I'm sure I've tried, but gave up after the kernel NFS introduced
when the 2.2 kernel was declared stable.

> > 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.

> 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.

> 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.

> 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...

-- 
  Les Mikesell
    [email protected]