Path: utzoo!attcan!uunet!spool.mu.edu!think.com!eplunix!das
From: das@eplunix.UUCP (David Steffens)
Newsgroups: comp.unix.internals
Subject: Re: Why is restore so slow?
Message-ID: <1017@eplunix.UUCP>
Date: 30 Jan 91 20:41:42 GMT
References: <19012@rpp386.cactus.org>
Organization: Eaton-Peabody Lab, Boston, MA
Lines: 24

In article <19012@rpp386.cactus.org>,
jfh@rpp386.cactus.org (John F Haugh II) says:
> In article <1013@eplunix.UUCP> das@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)