Why is restore so slow?

[David Steffens]

In article <19012 at rpp386.cactus.org>,
jfh at rpp386.cactus.org (John F Haugh II) says:
> In article <1013 at eplunix.UUCP> das at eplunix.UUCP (David Steffens) writes:
>> Who cares how slow restore is?  How often do you do have to do
>> full restore on a filesystem or a whole disk?  Once or twice a year?
> There are quite a few reasons in an EDP environment for restoring
> files.  For example, before a large unreversible process, it is
> common to dump the entire database partition so it can be restored
> if the process is found to have completed incorrectly.

OK, so it would seem that the remainder of my posting (which you
didn't quote) is even more relevant in your case.  Wouldn't you:
| ...much rather have a SLOW restore that was guaranteed to WORK
| than one that was FAST and had unknown bugs because of some
| magic algorithm that wasn't tested under all possible conditions?

And therefore, don't you agree that:
| the three most important performance characteristics
| of dump and restore are: RELIABILITY, RELIABILITY and RELIABILITY?
-- 
David Allan Steffens       | I believe in learning from past mistakes...
Eaton-Peabody Laboratory   | ...but does a good education require so many?
Mass. Eye & Ear Infirmary, 243 Charles Street, Boston, MA 02114
{harvard,mit-eddie,think}!eplunix!das      (617) 573-3748 (1400-1900h EST)