Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (System Mangler)
Newsgroups: net.unix
Subject: Re: Automatic unattended execution of '
Message-ID: <1012@cit-vax.Caltech.Edu>
Date: Sun, 5-Oct-86 07:05:04 EDT
Article-I.D.: cit-vax.1012
Posted: Sun Oct  5 07:05:04 1986
Date-Received: Tue, 7-Oct-86 19:59:03 EDT
References: <128@morgoth.UUCP> <49600015@convexs> <1316@jade.BERKELEY.EDU>
Organization: California Institute of Technology
Lines: 23
Summary: multi-user dumps

In article <1316@jade.BERKELEY.EDU>, mwm@dunsel.berkeley.edu (Mike Meyer) writes:
> Of course, the problem of needing extra tapes, what to do if the dump
> or reboot dies, etc. are still there. Me, I'd just dump the stuff late
> at night with active file systems and not worry about it. We run dumps
> of active systems (at 4-6 in the morning), and have more trouble with
> tapes going bad than we do with the file systems being active.

4.[123]bsd /etc/dump requires a human response on /dev/tty if the
slightest thing goes wrong.  Executing such a program from crontab
or /etc/rc is just asking for trouble.	Restore is even worse.

When dumps take hours on a machine that must be up continuously,
such as the sole gateway for an entire campus or the server for
all your Suns, there is no choice but to dump active filesystems.

We cope by hiring a sophomore to do dumps when activity is light
(6 am), and we do them as quickly as possible, so that a minimum
of activity transpires during the dump.  The activity has messed
up lengthy full rdumps; so has media problems.	We compensate by
doing more full dumps.	It's not an issue for daily dumps, where
the probability and consequences of a bad dump are both far less.

Don Speck	speck@vlsi.caltech.edu	seismo!cit-vax!speck