Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!bloom-beacon!think!ames!oliveb!jerry
From: jerry@oliveb.UUCP (Jerry F Aguirre)
Newsgroups: comp.unix.wizards
Subject: Re: Backups on Live Systems
Message-ID: <1589@oliveb.UUCP>
Date: Wed, 24-Jun-87 17:55:32 EDT
Article-I.D.: oliveb.1589
Posted: Wed Jun 24 17:55:32 1987
Date-Received: Fri, 26-Jun-87 06:06:24 EDT
References: <132@dvm.UUCP> <725@aramis.rutgers.edu> <20070@sun.uucp> <2248@hoptoad.uucp>
Reply-To: jerry@oliveb.UUCP (Jerry F Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 35
Summary: More than file system consistancy is important

I think it is important to realize that there are two levels of
consistancy that we are discussing here.  The first, and what most
people seem to be referring to, is the file system consistancy, i.e.
what fsck checks.

If all you are concerned about is getting a clean restore and fsck then
there are several means to do so.  Anything from locking out writes on
the raw interface to more complex strategy affecting only individual
files.  All these can give you a clean dump and restore.

But this DOESN'T mean that the dumps will be any good.  The object of
this is to have the user's files be recoverable, not to eliminate having
a guru patch the file system.  Even if all file IO was stopped for the
duration of the dump user files could be missing.

The most obvious example of this is if the user is editing a file at the
time that the dump begins.  Say he has just decided to write out all his
laborious changes.  The first thing done is to "create" the file which
truncates it to zero length.  Then it begins copying from the temp file
to the edited file.  If the dump begins at this time then the dumped
file will be at zero length!

This is actually worse than a system crash because vi knows how to
recover from those.  In a crash the temp file is saved and vi knows how
to re-create the edited file from that.  In this case a truncated file
is dumped, after which vi will continue and delete the temp file
necessary to re-create the original.  The dump is not likely to
contain the temp file because it is usually on a different file system.

If you are talking about a long running batch job that can be rerun to
create the output files then getting a "fsck" consistent restore from an
on-line dump is a worthwhile goal.  If you are talking about doing this
while users are banging away at random jobs then expect a few
disappointments.
					Jerry Aguirre