ADSM-L

AW: AW: Incremental Forever

2000-05-03 03:50:23
Subject: AW: AW: Incremental Forever
From: sal Salak Juraj <sal AT KEBA.CO DOT AT>
Date: Wed, 3 May 2000 09:50:23 +0200
Hi Allen, 

let me respectfully disagree with your respectfull disagreement :=8)

First, while I was comparing the speed 
between "incremental-forever" restores 
and "full" restores, 
you argued with "full+delta" backup/restore scheme,
which really some different implications.

If joining your comparision,
I must admit that my unrestricted statement 
that "full restores will be slower"
should be requalified, and the 
statement would not be so definitive.

Hey, the argumentation with 
 > On any day except the day the full was taken, 
 > you must mount a minimum of two
 > tapes to complete a restore.
is simply wrong. It is by no means 
the priviledge of incremental-forever 
backup software like *SM
to write tapes in append mode!

Even more important, this is not THE point.


Let me specify my previous statement about restore speed
as possible argument against incremental-forever approach 
more precise:
(I speak about approach, not only about its 
specific implementation in *SM software 
which I use since V1)

if the restore requirement is to restore 
 large amounts of data like whole file systems
 in latest known genuine state.
 "Large amount" means one single full backup would
 occupy substantial part of one tape, or even more tapes,
 and theoreticall throghput of tape HW would not allow
 for write/read times under, say, a hour or two.

if only the speed of backup/restore subsystem
 is the limiting factor (assuming that,
 for example, the file system can create/write
 files quicker than the tape can read them,
 that network connection can keep with, etc.)

if we compare different approaches on otherwise
 same hardware and OS plattforms

=> then well-managed full restore 
 will never be slower comparing 
 to restore from simmilary well-managed 
 full/incrementall restore;
 and restore from 1 week full/delta/delta/delta/delta
 will probably be quicker than incrementall forever restore as well.


To argue, answer the following question:

What is the speed limiting factor in the above configuration?

(stop here, think about, then PageDown)











































It is the ability to read the data from tape.

Who can read data quicker: 
a tape drive which can stream all the time, 
or a tape drive which is foced to stream/search/stream/search .. ?

Pure streaming is much,much quicker, 
even with expensive search-optimised Magstars.
Using slow-searching DLT´s 
can lead to magnitude-large differencies.

Which approach leads to more empty gaps, thus
more searches - full or incremental?

Which approach leads to more gaps, 
incremental forever or 
full on monday + incremental on tuesday to friday only?


1) incremental-forever approach leads to most tape gaps,
causing most tape searches thus slowest tape read throughputs.
There is no predictable hard high limit of search count.

2) one week full/4incrementals approach leads to less gaps,
the high fap limit is 4 tape gaps per file.
Thus this approach limits the search count.

2) pure "full" approach raises no tape gaps at all, 
thus making full-time streaming mode possible,
leading to restore times only limited by underlying HW.

Depending on used SW, the "full" approach will 
likely be easier configurable to higher throughputs
by inserting $$ into equipment and management:
it is trivial to backup/restore to/from
2 tapes in parallel with simple backup tools,
it is possible but neither simple nor deterministic
using complex tools like *sm.

As full restore has the potential of 
fully exploiting the HW,
any claim that incremental restore is quicker than
full restore claims implicitly that incremental can restore data
quicker than the HW used can transfer data.
This is magic, not engineering.


Real life observation: 
while I know there are cases
*SM can restore data quicker than
another SW, the restore throuputs 
having been communicated on this forum
are by no means suspicios of beeing world records.
Simple DLT drive on dedicated SCSI Interface
would defeat most of restore throughputs
I have ever seen published here.

Conclusion:

When planning new backup system
under above assumptions, 
the restore speed requirements 
should be considered as an important point 
to check against backup approach selection.
(Warning: the issue is much more complex than 
this long mail can even touch on.)

Maybe not often, but possibly, 
the so-called 1970´ approach
can fulfill requirements better than 
most modern one.




Disclaimer:

*Nothing* of above was meant either as a war
against either *SM or against incremental-forever approach.
I only want to point out that , generally speaking,
seldom a single approach, incremental-forever including,
will be optimal to fulfill  ALL requirements under ALL
circumstances.

In fact, mix of of many real-life requirements can be
fulfilled with incremental approach and its current
*SM implementation better than with 
either full or full/incremental approaches.


regards
Salak Juraj

KEBA AG
Softwareentwicklung Bankautomation
Gewerbepark Urfahr 14 - 16
Postfach 111
A-4041 Linz
Österreich

Tel. ++43/732/7090-7461
Fax ++43/732/730910
e-mail: sal AT keba.co DOT at
www.keba.co.at


















<Prev in Thread] Current Thread [Next in Thread>