Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!adm!rbj@icst-cmr.arpa
From: rbj@icst-cmr.arpa
Newsgroups: comp.unix.wizards
Subject: Backups on Live Systems
Message-ID: <7650@brl-adm.ARPA>
Date: Tue, 2-Jun-87 15:13:13 EDT
Article-I.D.: brl-adm.7650
Posted: Tue Jun  2 15:13:13 1987
Date-Received: Thu, 4-Jun-87 06:41:08 EDT
Sender: news@brl-adm.ARPA
Lines: 56


   Also, what would you *expect* from a full dump taken on an active
   filesystem?  If you had to restore that dump, what state of the
   filesystem would you expect to restore?  What sort of guarantees
   of consistency would you want from such a dump scheme?  When the
   filesystem is inactive, it's easy to guarantee a certain consistency,
   but when it's (potentially very) active, what can you guarantee?

These are all good questions. I will limit my answers to what I
*expect*, which may or may not correlate with reality.

Ideally, I expect all files newer than some date (selected by level)
to be dumped on tape. I do not care that file deletions be noted,
because it is easier to delete extraneous data than to recreate it.
I also do not believe in incremental restores, as I tried it once
and it didn't seem to work. While I realize this is scant data and
I could have goofed, I would rather restore what I want into a
subdirectory (using either the `i' or `r' options) and sort it
out by hand than depend on something that might really be broken.
I also have little desire to alter my conceptual model in this case.

Practically, since inodes are scanned first, pathnames mapped,
and then dumped as a triple (inode, pathname, data) by inode, it
would appear that any inode that changed could be bogus. This could
include incomplete data if the file was being modified. If a file was
deleted and a new file created that used the same inode, a new file
could be dumped under a wrong (the old) name. Either of these
possibilities presents little problem if you assume that "files in
the process of being updated while dumps are going on deserve what
they get". 

Of course, if your aim is to preserve the *exact* state of a disk,
then deletions are important to you. But then I would say why not
dump the whole thing? Takes time? Gee, life is tough!

   Does anyone know how other systems handle this problem?  What does
   VMS do?  TOPS-20?  Multics?  others?

Of others, I will speak of SECURE under EXEC 8, from memory and
at least a decade ago. Files have a backup date in their equivalent
of inodes. Every so often, and/or when storage becomes scarce, a
daemon backs up files to tape and optionally deletes them, the oldest
files (not specifically excluded by special means) going first. This
is called rolling out. If a file does not exist when referenced, a
daemon is started to roll the file back in and a message to be patient
is emitted. In awhile, the file magically reappears.

I see no reason why such daemons could not be implemented on any
UNIX system with operators onsite.

					   Bill Shannon
					   Sun Microsystems, Inc.

	(Root Boy) Jim Cottrell	<rbj@icst-cmr.arpa>
	National Bureau of Standards
	Flamer's Hotline: (301) 975-5688