Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!ads.com!sparkyfs!zwicky
From: zwicky@sparkyfs.istc.sri.com (Elizabeth Zwicky)
Newsgroups: comp.unix.admin
Subject: Re: Why idle backups?? (was Re: Looking for shell script for backup on BSD 4.3)
Message-ID: <32749@sparkyfs.istc.sri.com>
Date: 23 Oct 90 21:12:05 GMT
References: <547@fciva.FRANKLIN.COM> <1642@sirius.ucs.adelaide.edu.au>
Reply-To: zwicky@quetzalcoatl.erg.sri.com.UUCP (Elizabeth Zwicky)
Organization: SRI International, Menlo Park, CA 94025
Lines: 41

In article <1642@sirius.ucs.adelaide.edu.au> john@achilles.ua.oz (John Warburton) writes:
>Forgive my ignorance, but I have looked through TFM, and it says that you should
>not do a dump on an active file system. That's OK, but WHY??? I can't see any
>documentation as to what would happen if you did do a dump on an live file
>system.

Dump does not go through normal filesystem primitives to read files;
it builds a table and then reads inodes direct from disk. If the file
system changes between the time it reads the tables and the time it
reads the inodes, life is not good. The result can *and* *does*
produce tapes which are unusable - not just the active file, but
every file after that inode number is lost to restore.

Some sites run a dump modified by Purdue to skip inodes that change
after the tables are read - this means that your chances of getting
a corrupt tape are significantly reduced (there are still a few really
obscure conditions that can screw life up) but on the other hand files
are likely to be missing altogether. This is not what I want out of a
level 0.

The danger of doing active dumps is *NOT* theoretical; I have seen
missing files more than once, and completely mangled tapes at least
once. It may be acceptable to you if you do frequent dumps at
low-usage times, but you should watch out for users or processes that
inadvertently get synced with your dump schedule, you should run a
Purdue modified dump if at all possible, and you should give serious
thought to running level 0s in single-user; you can do this
automatically in the middle of the night by using the same sort of
trick that fastboot uses, creating a magic file that the rc files
look for in the boot process to tell them to do backups.

Programs like tar that use normal file system acesses do not suffer as
badly from this problem - they can tell when a file is active better -
but have speed problems and frequently problems with odd files. Given
the way UNIX file systems work, even these programs cannot guarantee
correct dumps of active files (instead, they skip them). You can get
around that by rewriting the file system, but that's not always an
available option...

	Elizabeth Zwicky
	zwicky@erg.sri.com