Summary: Taking a backup at 5 am (4.2BSD)

[Johan Wide'n]

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 at 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