Why idle backups?? (was Re: Looking for shell script for backup on BSD 4.3)

[Elizabeth Zwicky]

In article <1990Oct24.210312.3271 at cubmol.bio.columbia.edu> ping at cubmol.bio.columbia.edu (Shiping Zhang) writes:
>In article <32749 at sparkyfs.istc.sri.com> zwicky at quetzalcoatl.erg.sri.com.UUCP (Elizabeth Zwicky) writes:
>>You should give serious
>>thought to running level 0s in single-user; you can do this
>>automatically in the middle of the night by using the same sort of
>>trick that fastboot uses, creating a magic file that the rc files
>>look for in the boot process to tell them to do backups.

>I have seen this suggestion more than once on this news group.
>But I don't know how. One question I have is about the tape changes.
>Certainly one tape is not enough for a zero level backup.
>How to get away with this problem?  Thanks for any enlightenment.

Step 1: Set up your full saves so you don't have to change tapes.
The traditional way to do this is to buy high-capacity tape drives -
many people find that a whole machine can level 0 onto a 2 gigabyte
exabyte tape. For people like me who no longer have that luxury,
you can either back up different file systems to different tape drives
on the same night, or back up different file systems to the same tape
drive on different nights. There are hooks in the script I use to
do either one, although I actually do the latter. If you have single
file systems that won't fit on single tapes, you will have to buy
new hardware, re-partition your disks, or give up.

Step 2: Modify whatever script it is that your system runs during the
boot process (rc.local is a good choice on a Sun) to insert a check
for the existence of a special file - I use /backup - and execute the
backup script of your choice if it exists. You will need to figure out
where you can put this test so that enough of the machine is running
so that you can do the backups (we use remote tape drives, and also
need /usr/local, which is NFS mounted on many machines, to get the
scripts out of), but not enough so that the users can make the file
systems active. 

Step 3: When you intend to do a backup, set an at or cron job to
create /backup and schedule a shutdown with about an hour's lead time.
Note: You don't want to create /backup at 5 when you leave and set
the shutdown off, because if the machine crashes at 5:15 it will do
the full save, which will significantly delay its reboot process.

This trick was invented by Steve Romig, at Ohio State, although
probably other people have also invented it independently; it's not
all that tricky. It is discussed, along with lots of other fascinating
backup tricks, in his paper in the latest Large Installation System
Administration conference proceedings; get the conference proceedings
from the Usenix association, or you can probably get just the paper
from him, romig at cis.ohio-state.edu.

	Elizabeth D. Zwicky (zwicky at erg.sri.com)