johanw@ttds.UUCP (Johan Wide'n) (12/16/84)
A couple of weeks ago I posted an article describing a way to take a single user mode dump during the wee hours of the night. Here is a summary of the responses I got. First to recap: >We take backups with /etc/dump. It is possible to get a reasonably >errorfree dump in multi user mode if the system activity is low. >As our systems can be quite active even at a very odd hour, we prefer >to take backups in single user mode. Although we dump directly to tape, a common approach is as follows: Take the system down into single user mode. Instead of dumping the disk partition to tape you copy it to another (unmounted) disk partition. Take the system up into multi user mode. During the following day the copy of the partition is dumped to tape (in multi user mode). As the copy resides on an unmounted partition there will be no problems with i-nodes being modified during the dump. This approach has the obvious benefit that the operator is available and can respond to error messages from dump, change tapes etc. Per Hedeland (mcvax!enea!erix!per) presented a script for taking the system down into single user mode, executing a shell script and then returning to multi user mode again (without a reboot). This is based on providing a check for the existence of a file in /.profile. Note that the script is experimental and that there are a few problems: When you enter single user mode and then reenter multi user mode /etc/mtab is cleared. This means that mount -a will not work. Per suggests that one should put a umount -a somewhere in the script. Here is his addition to /.profile. ('exec -mv' is supposed to kill the shell) ======================================================================== # For doing dumps etc in single user and then returning to multi : # If there is a file /single_shot owned by root and created today, # source it, remove it, and die # (Assumes, of course, that root doesn't run /bin/sh in multi-user) if [ -f /single_shot ] then set - `ls -l /single_shot` owner="$3" ctime="$5 $6" set - `date` if [ "$owner" = root -a "$ctime" = "$2 $3" ] then . /single_shot exec mv -f /single_shot /single_done else rm -f /single_shot fi fi export PATH TERM ======================================================================== Here is Per's script for requesting a single user mode dump (in this case from a Sun to a Vax-disk). ======================================================================== #!/bin/sh if [ $# -ne 1 ] then echo "usage: dump_at 'time'" exit 1 fi cat >/single_shot <<EOF ( /etc/dump 0uf - /dev/rxy0a | \ /usr/ucb/rsh erix cat ">" /mnt/dump/erix-s/root ; \ /etc/dump 0uf - /dev/rxy0g | \ /usr/ucb/rsh erix cat ">" /mnt/dump/erix-s/usr ) >/dump_log 2>&1 EOF at $1 <<EOF shutdown +5 "Dumping" EOF ======================================================================== -------------------------------------------------------------------- From: mcvax!seismo!randy@nlm-vax.arpa (Rand Huntzinger) [...] We have a slightly more complex set of shell scripts and do a disk to disk copy at 5 AM instead of disk to tape. Another script is used to transfer the disk copy of the dump to tape (using dd) when the system is up multiuser. We only use this scheme for incremental dumps to avoid disk and tape overflows. The scripts do a level 1 dump on monday and a level 3 dump on tuesday through friday. No dumps are done on weekends. We use cron to start our backup instead of at. We also provide a mechanism for suppressing the shutdown, reboot and dump sequence. The advantage of the disk to disk copy is that we can use multiple tapes if all the dumps won't fit on a single tape, the limitiation becoming one tape per file system. Of course, the big disadvantage is the amount of disk space you have to keep free to hold the nightly dumps. Our scripts only seem to hang if there is a problem with actual reboot, not if the backup fails. Since we do disk to disk copies, we don't get the system hanging while waiting for a tape change. The script aborts and the system comes back up if dump exits with a return code other than 1 (which seems to be its normal return code). We also allow for the possibility of a crash interrupting the dump process. We use a file renaming process to keep track of which file system dumps have been completed and which have to be done. (name.x means dump in progress, name.y means dump done. When we have done all file systems, the trigger file is deleted and the .y is removed from the dump files). [...] This scheme has turned out to quite acceptable for our current needs; however, we may have to alter it eventually as our disks fill up and our user community becomes larger. ----------------------------------------------------------------- I also got a message from mcvax!enea!erix!mike (Mike Williams) stating that they performed dumps by copying a diskpartition to an unmounted partition. They had found that dd performed poorly and had written a faster disk copying program. mcvax!enea!ttds!johanw Johan Widen