/xenix: Making and Managing Backups
©1987 - Richard A. Bilancia - All Rights Reserved
to be published first in the March 1988 issue of UNIX&reg/World

If you are using and relying on a computer for your business or personal needs, let me assure you that there is absolutely nothing more important than properly made, managed and stored backups. I know, because I learned the hard way several years ago!

Lighting never strikes twice?

I live and work in the front range of the Rocky Mountains about 30 miles southwest of downtown Denver, Colorado. While the Tampa Bay, Florida area is generally recognized as the "lightning capital of the world," the front range of the Rockys certainly deserves the second place rating. Until I moved to Colorado I had never met anyone that had their home struck by lightening, but in the last three years my home has suffered not one, but two direct strikes (at opposite ends of the roof line, so the old adage must still apply).

In addition to frying everything electrical on both occasions, the lightning created a 12 foot hole in my roof from the first strike. But very fortunately, no one was injured as a result of either strike: even though I was talking on the phone during the second strike.

Before the first strike I had been doing regular, but not daily, backups. Accordingly, while I had not lost very much data I did not have a computer available to even look at my latest **calendar** entries! I had to rely totally upon my memory, and still wonder if I missed any important appointments.

After I got my primary system back, I implemented a supplemental procedure that automatically prints my **~/calendar** and other critical files once a day. Therefore, I would be able to continue to conduct business without a computer--at least for a short time.

As a result of my efforts and plans, the second strike (while just as damaging to my systems) did not disrupt my computer or business operations to nearly the same extent as the first strike. Of course, the frustration of dealing with insurance adjusters and computer repair organizations is quite another story.

Backup Utility Alternatives.

The !!xenix!! operating system comes with a wide selection of tools that can be used for system backup and recovery. These tools include **tar** (originally for tape archiver), **cpio** (for copy in/copy out), and the **dump**/**restor** combination that is also known to !!xenix!! users as **backup** and **restore**.

It is important to recognize that these tools were originally designed to be used by experienced !!unix!! system administrators, not the typical business user of today. Accordingly, you can expect that these utilities will have a large selection of rather cryptic options. To make them easier to use, a number of user interfaces are available. Microsoft has included with !!xenix!! System V a utility called **sysadmin** that is nothing more than a very extensive Bourne shell (**sh**) script that appropriately executes the **dump**/**restor** utilities for full system and incremental backups and restorations. Additionally, the SCO provided **sysadmsh** user interface provides a fill in the blank interface for **tar**.

While many !!unix!! system administrators prefer **cpio** for incremental backups because it can take a list of files to be backed up as its standard input, I prefer to use **tar** on my !!xenix!! systems for the same reason. !!xenix!! **tar** includes an option (**-F**) that allows for a list of files to be backed up to be specified in a file. This option, coupled with the faster speed of **tar** compared to **cpio** on !!xenix!! systems, makes **tar** the !!xenix!! backup utility of choice. **dump** may be faster than **tar**, but **restor** can be much slower, particularly when entire file systems must be restored.

Some of My Supplemental Techniques.

With the rather large file systems that many !!xenix!! users now have, steaming tape backups and multiple system networks are becoming more and more popular. This combination of factors makes the option of automatic incremental backups, networked to a single tape drive a very viable solution.

The two shell scripts that follow (**.bufull** and . **.buremote**) are two utilities that I use on one of my !!xenix!! systems to automatically perform incremental backups via the **uucp** system to a machine that has a streaming tape backup unit. The two procedures must be used together because the date & time stamped files needed by **.buremote** are only created by **.bufull**. **.bufull** is nothing more than another way to do a full system backup of all standard files (not empty directories or device files) using **tar**. Once **.bufull** has been run one time, **.buremote** can be executed to backup all files that were created or modified after the last execution of **.bufull**. The incremental backup file that is created, **/tmp/part.tar**, is then compressed (typically 20% to 40% using the **pack** utility) and finally transferred to another system via the **uucp** command. Once on the other system, it can then be backed up to the streaming tape unit.

".bufull"

:
#       ".bufull"
#       Full backup utility used with ".buremote"
#
date > /etc/.lastpartial
date > /etc/.lastbackup
find / -type f -print > /tmp/bu.files
tar cF2 /tmp/bu.files
rm -f /tmp/bu.files

".buremote"

: # ".buremote"

# Incremental backup utility used with ".bufull"

find / -type f -newer /etc/.lastbackup -print | fgrep -v "/tmp/

/usr/spool/" > /tmp/files.tmp

/bin/echo "The number of files to be backed up is :
wc -l < /tmp/files.tmp

tar cfF /tmp/part.tar /tmp/files.tmp

date > /etc/.lastpartial

pack /tmp/part.tar

uucp /tmp/part.tar.z system2!/u/tmp/part.tar.z

rm -f /tmp/part.tar.z /tmp/files.tmp

One other thing to keep in mind when using **tar** directly with streaming tape units, is the relative inefficiency of the **tar** blocking factor limit of 20. If you have sufficient memory, and want to keep the tape drive from frequently stopping and starting, you might consider using the **dd** command to increase the size of the blocks being written to the tape device. Variations of the following command line can be considered:

**tar cf - . | dd obs=512k > /dev/rct0**

In this case, the **-** signified to **tar** to send its output to the standard output, which is then read by **dd** and written in blocks 512K bytes each to the cartridge tape device.

Media Rotation.

There are several different methodologies to use to rotate electronic backup media. The most common of these methods is to have three sets of media for both incremental and full system backups. These sets are sequentially reused and are typically referred to as the child, parent and grandparent sets. Each time that a new backup is to be performed, the oldest backup set (the grandparent set) is used. The old grandparent set then becomes referred to as the child, the old parent set becomes the grandparent, and the old child now becomes the parent. There is nothing magical about having only three sets, more can be used.

I prefer using a slightly different procedure that continuously uses and reuses a large single set of sequentially numbered media. This approach, as long as your set of media is sufficiently large, has the primary benefit of always having all of the full backups have the corresponding incremental backups available until they are overwritten in sequence. For example, a single set of media might have the following backup information:

Media #    Date     Description






1-20   3/1/88    Full backup (oldest)21 3/2/88 incremental #1 for oldest22 3/3/88 incremental #2 for oldest
23 3/4/88 incremental #3 for oldest

24-25 3/5/88 incremental #4 for oldest

25-47 3/6/88 Full Backup (middle)

48 3/7/88 incremental #1 for oldest

49 3/8/88 incremental #2 for oldest

50-51 3/9/88 incremental #3 for oldest

52-54 3/10/88 incremental #4 for oldest

55-74 3/11/88 Full Backup (newest)

75 3/12/88 incremental #1 for oldest

76 3/13/88 incremental #2 for oldest

77 3/14/88 incremental #3 for oldest

78-79 3/15/88 incremental #4 for oldest

80-81 3/16/88 incremental #5 for oldest

The important thing in any backup media rotation is to
keep a written log of the dates, times, contents, number of
volumes, and type of utility used for each and every backup.
That way if you ever need to use any set to restore some
data, you’ll have all the necessary information
written down in a single place. In other words, don’t
rely on information written on diskette labels--it may be
totally useless if you accidently drop a stack of diskettes,
and certainly don’t trust your memory. Unless
your’s is perfect, it doesn’t work over a period
that may last up to several months.

Conclusion.

Computers fail, whether they are struck by lightning or
not. Accordingly, make sure that you’ve implemented an
appropriate backup and recovery procedure for your system.
That procedure should include a schedule for full, periodic
backups as well as incremental, or partial, daily backups
and off site media storage.

In some cases where a system is critical to a business
operation, you might even want to consider some hardware
redundancy with automatic backup and restoration
procedures.

I hope that you never need to rely on the backups, but
believe me it’s comforting to know that they’re
there!