Re: Perfomance problem backupscript (more details and tests)

Les Mikesell <[email protected]> wrote:

> > This is your private opinion but not necessarily an objective statement.
> > Every tool may not work as expected if used in an undomumented way.
> > Star's incrementals work perfectly as long as you follow the documentation.
>
> My opinion is that an incremental run should include all files that
> exist in the included area.  As a practical matter, I need to
> exclude some areas and I cannot restrict renaming.  The tool I use
> must work correctly under these conditions.

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


> > > Restoring incrementals must have the option to delete files that were
> > > not present at the time of the incremental run or you will accumulate
> > > all the garbage that was deleted between the full and incrementals and
> > > probably run out of space.
> > 
> > It is really boring to see that you still did not read the star man page....
> > This is not the first time that you write untrue things because you don't
> > read the man page.
>
> There is nothing untrue or uniquely related to star in my statement
> above.  It is a basic requirement that star may recently be able to
> meet.  It is ignored in the Posix spec, as far as I can tell, though.

It is definitely untrue: read the man page and you know what/why.


> > Then please admit that your experiences are a result of badly administred
> > or defective and unfixed machines. I have enough experiences with Sun
> > equipment to prove that your experiences do not match reality.
>
> Yes, running the buggy Solaris 2.4 was bad administration. But that's
> what the Sun people sold us. I'm sure you stopped using it at the
> first opportunity.

Solaris-2.4 was as buggy as any really good OS was at that time.
If you did destroy it, it was your personal problem. For the rest of the
world, Solaris-2.4 was rock solid.


> > I am sorry, but if your sysadmin was not doing a good job, please don't
> > tell us that Solaris was bad - tell us that you would have needed a different
> > sysadmin but not a different OS.
>
> 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.


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

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



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

But if you were trying to find a backup solution, you would start reading
the star man mage (and I am not talking about the man pages you find on
your outdated Radhat system....)

If you did read my previous mails, you would know that I did already answer 
your question in great details. So please tell me: why do you repeat
questions that have already been answered?


> the index and again for recovery after making selections. With GNUtar
> based runs, the data is always included in the same run as the name so
> a restore of renamed files or paths is simple.

GNU tar incrementals are known not to work.

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?



> > I did explaint it already several time to you:
> > 
> > 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?

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?


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

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