Re: Perfomance problem backupscript (more details and tests)

On Thu, 2005-10-20 at 07:20, Joerg Schilling wrote:
> As I already saud several times: this is your personal opinion that
> has nothing to do with a real world incremental backup.
> 
> Requiring this is similar to requiring cars to have square tires.
> They will be useful if you have the right roads, but only then.....

Analogies are always flawed, but a closer one would be that a
backup system that doesn't permit arbitrary exclusions is like
a car that forces you to always carry tons of useless extra
baggage.

> > The systems were running stock Sun software, and that is what was
> > crashing.  I think Sun has become more sensible about providing
> > software updates, but it's too late for me.
> 
> So you do not tell us the truth! I am still running a Sparcstation-II with
> Solaris-2.4 and it is rock solid.

Is it exposed to the internet and running the original stock sendmail
and dns server supplied with 2.4?  Can I have the IP address?

> > If you are going to pretend that there is a standard for UNIX, you have
> > to go back to the AT&T versions before all of the variations were
> > added.  Since that time there has been no standard and every vendor
> > has gone its own way.  Then it follows that applications have to
> > be adapted to match each distribution's conventions.
> 
> It looks like you try to find excuses for the rubbish you find on Linux 
> systems......

RedHat versions are very SysV-like.  Probably more so than Solaris 2.4
which still had a lot of BSD oddness.

> UNIX always had well defined ways to do things and Linux just ignores them.

The kernel has gone it's own way to improve things and has had faster
networking than Solaris for many years.  Solaris 10 is the first
thing to come close and even now only on 64-bit hardware:
http://www.networkworld.com/reviews/2005/022805solaristest.html
But as far as conventions for program locations and daemon
startups go, some distributions are BSD-like, some SysV-like,
following the already-diverse conventions.

> > > Star does meet your criteria, it seems that amanda is currently not well 
> > > maintained.
> >
> > I was hoping you would fill in the details here about what amanda would
> > have to do to know the tapes needed in this circumstance. It has been
> 
> I have no idea what your real objectives are...

I thought I explained that clearly.  Amanda indexes files during
a backup and prompts for tape insertion during restores taking
incremental levels into account.  How can amanda (or a person
doing this manually) collect the information needed to know
which tapes to insert and what commands to issue to do a
restore on a file that was renamed before some incremental
level, or files under a directory that was renamed?  

> GNU tar incrementals are known not to work.

You can describe conditions where a GNU tar restore will fail to
create some files. I can describe conditions where a star backup will
fail to save some files.  I don't see a big difference here.

> Star implements a different method that (in contrary to the GNU tar method)
> has been verified to work reliably. Why do you like star to implement a method
> that does yet have been verified to work at all?

How many reasons would you like?  I'd like it because it is a practical
and efficient method for backups.  I'd like it because it is possible
to restore a renamed file with only the tape containing the name
you know you want.  I'd like it because it permits arbitrary
file exclusions with no restrictions on renaming.  I'd like it
because it permits backups to cross mount points and mount points
to change between runs without losing data. I'd like it because
I think you can make it work.

> > > 
> > > Redhat maintainers did definitely not fix bugs in GNU tar, they did just
> > > publish otherwise unpublished internal test versions from the real GNU tar 
> > > maintainers.
> >
> > That's easy enough to disprove.  Their published source RPMs contain
> > the pristine developers tarball plus separate patches for the
> > distribution and a spec files that applies them while the binary
> > is built.  I've already mentioned that the current source RPM
> > contains seven patches - one for a specific bug you mentioned
> > earlier.  They also keep a bugzilla of open bug reports.  Should I
> > expect to see yours there?
> 
> So you believe that you may prove things by writing sentences that
> are self contradicting?

There is no contradiction there.  Developers sometimes have bugs
in their code.  Distribution packagers get the bug reports and
fix them.   You can make your own choice about running the
fixed or unfixed version.  I've already made mine.

> At least you now admit that you don't use a released GNU tar version
> but the current internal developer version of the source. As you tell us that
> you like to get "stable" software, why do you use unreleased developer
> versions of GNU tar?

There is nothing 'unreleased' about RedHat/fedora source RPMs. They
are published, publicly available, and entire distributions have
been rebuilt from them.  You could consider the original developer's
release as 'untested', the RedHat rawhide copy as 'alpha', the
fast-release fedora version as 'wide beta', and the RedHat
Enterprise version as 'stable'.   If you choose to run the
untested version when better alternatives are available that
is up to you but it doesn't make sense to complain about
bugs there.  

> > > The POSIX specs currently don't say anything about backups.
> >
> > Then perhaps you might understand why they are considered irrelevant
> > by a system administrator.  Why do you keep bringing them up?
> 
> Wrong: your through ins are considered irrelevant because you don't check the
> relations betweem the standards and the current discussion topic.
>
> A standard may of course define things that are relevent for other things that 
> not explicitly part of the standard. This happens to be the case for backups in 
> case you like to use a portable and standardized archive format as a container 
> for the actual backups.

In a practical sense, the archive format is irrelevant as long as
the code to access it is available and portable.  In a larger sense
the fact that Posix did not consider a mechanism to accommodate
incremental backups shows that they either did not understand or
did not concern themselves with the needs of a real system. Thus,
following their agenda is not going to be appropriate for someone
who needs to keep machines running.

-- 
  Les Mikesell
    [email protected]