pat@tifsie (09/16/86)
Don't know about all of it, but if you create /etc/nologin (touch should work
nicely), that will prevent anyone from logging in. Delete the file when
you're ready to allow users again.
Also bear in mind that you have to remember to mount a tape before you go
home at night. We run a backup of one of our file systems every night at
midnight, using cron. However, the system is pretty much idle, so we don't
worry about shutting anything down. We made sure to pick a file system that
will fit on a single tape. If dump asks for another tape when you're in bed,
you've got a problem....
-----------------
Patrick W. Peters
Texas Instruments
Process Automation Center
P.O. Box 655012, M/S 3635
Dallas, TX 75243
UUCP: {uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!pat
Voice: (214) 995-2786hosking@convexs.UUCP (09/18/86)
How sleezy are you willing to be ? This is *really* crude, but it might work: The general idea is to temporarily replace /etc/rc with a dump script. 1. Create a dump script that does whatever you want. Call it /etc/dump_rc. The last thing in it should be "cp /etc/real_rc /etc/rc;/etc/reboot." It should NOT start the normal daemons. This eliminates possible races with cron jobs or other daemons. The /etc/nologin trick shouldn't be needed here, since the system will have rebooted before rc finishes. 2. cp /etc/rc /etc/real_rc. 3. Create a crontab entry that does 'shutdown -r +5 "to do the dumps"' after it does "cp /etc/dump_rc /etc/rc." Yes, there are plenty of possible problems if you crash in the middle, etc... but it's hard to make it much simpler, and it might be useful enough to use. You could do something similar with the .profile or .cshrc for root, too. How well this works would depend on the characteristics of your particular backup scheme. Since I don't know much about your system, I can't guess whether it's a workable solution for your needs.
mwm@dunsel.berkeley.edu (Mike Meyer) (09/21/86)
In article <49600015@convexs> hosking@convexs.UUCP writes: >How sleezy are you willing to be ? >This is *really* crude, but it might work: > >The general idea is to temporarily replace /etc/rc with a dump script. There is a better way. The first thing our /etc/rc script does after fsck'ing the file systems is: if [ -f /etc/special.reboot ] then sh -x /etc/special.reboot > /etc/special.reboot.out 2>&1 fi This allows me to do arbitrary things on reboot without fiddling with the rc scripts. Put a script to dump things plus a mv command in /etc/dump.reboot, then arrange for cron to move /etc/dump.reboot to /et/special.reboot and reboot the system. Much nicer than swapping rc scripts around and rebooting multiple times. 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. <mike
mangler@cit-vax.Caltech.Edu (System Mangler) (10/05/86)
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