Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!rutgers!clyde!cuae2!ihnp4!inuxc!pur-ee!davy From: davy@pur-ee.UUCP (Dave Curry) Newsgroups: comp.unix.wizards Subject: Re: Backup of a live filesystem revisited Message-ID: <5108@pur-ee.UUCP> Date: Wed, 24-Dec-86 22:54:37 EST Article-I.D.: pur-ee.5108 Posted: Wed Dec 24 22:54:37 1986 Date-Received: Thu, 25-Dec-86 22:35:45 EST References: <4760002@hpirs.HP> <1226@ho95e.UUCP> <7446@utzoo.UUCP> Reply-To: davy@pur-ee.UUCP (Dave Curry) Organization: Electrical Engineering Department , Purdue University Lines: 34 We do both partial and full dumps of live file systems on a regular basis, and have had no troubles. The tricks: 1. Nice yourself down as far as you can. Like -20. 2. Modify dump (most of the mods are in dumptraverse.c) to skip any inode whose mtime or ctime is greater than spcl.c_date (time of the dump). The idea here is that you dump all files which have not changed since the dump started. If the file changes during the dump, it will not be looked at, and thus the problems of removed or changed files (removed files are the worst) go away. You MUST make these mods to dump to get away with this sort of thing; we found out real fast in testing that dump (actually restore) tends to get real upset if files go away when it thinks they should be there. The most we've seen happen doing things this way is that when restoring from a full dump you see a few "resync restore" messages. But we have never had a bad dump (non-restorable) in the 14 months or so that we've been doing this. NOTE: I'm not necessarily recommending this practice. If we had our way we'd do dumps in single-user mode. But shutting down 20 machines every morning for 30-minute partials and on weekends for 2- and 3-hour fulls is not practical. If you want the diffs (for 4.3BSD dump), send me mail... if I get enough requests I'll post them. --Dave Curry Purdue University Engineering Computer Network