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
(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
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.
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.
*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
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.
Gewerbepark Urfahr 14 - 16
e-mail: sal AT keba.co DOT at