Dump and Restore

Judith Ashworth

Of the several UNIX utilities that perform backups -- including, among others, dump(1), tar(1), and cpio(1) -- the most popular is probably the dump utility. However, if your network has UNIX systems from several different vendors, dump may not be compatible across all of them. In these cases, using tar or cpio would be an alternative. Also, if you are not running BSD UNIX, dump may be called something else on your system. For example, on System V Release 4 it is called ufsdump and on AIX systems it is called backup. The restore utility may also be called something different, like ufsrestore on System V. Check the documentation for your particular flavor of UNIX.

Unlike tar or cpio, the dump utility was created specifically for doing backups. It has the ability to do several levels of partial backups, called incrementals, which conserve tape by saving only those files that have changed since the last time they were backed up. There is also a companion utility for dump called restore. The restore utility recovers individual files, directories, or an entire disk partition from tape. This article deals exclusively with the dump and restore utilities.

As nice as dump is, it does have some shortcomings. For example, it can only backup file systems (disk partitions): it cannot be used for individual files or directories. To perform such backups, you must use tar or cpio. Further, you cannot use dump to backup active file systems; if your systems are in use 24 hours a day, 7 days a week, you will have trouble with dump. If you still prefer dump over tar or cpio, there are several companies that sell similar software products for performing backups. Many of those products use the same tape format as dump.

Understanding Dump Levels

The dump command allows you to specify "levels" of backups. The dump utility has 10 levels: 0 through 9. A level 0 is a full backup, capturing every file on a partition. Every other level is an incremental. Incrementals capture every file that has changed since the last previous dump with a level number less than or equal to the requested level.

A level 1 dump will always capture everything that has changed since the last level 0 dump on the file system, because the only level lower than 1 is 0. Now this is the tricky part: what every other level captures is entirely dependent on what levels have already been done! For example, let's suppose the following dump schedule after doing a level 0 monthly backup:

Monday:          level 8
Tuesday:         level 9
Wednesday:       level 7
Thursday:        level 8
Friday:          level 1 (weekly)

Since we are starting at a level 0, Monday's level 8 will get all files that changed since then. Tuesday's level 9 will get files that changed since Monday. Wednesday's dump is a level 7. The most recent dump we have done that is lower than 7 is the level 0, so all files that have changed since the level 0 are dumped. Wednesday's level renders Monday's and Tuesday's levels obsolete except as safety copies. Thursday's level 8 gets everything from Wednesday because the level 7 was the next lowest dump done, and Friday gets everything from the level 0. Similarly to Wednesday's level, Friday's level renders the four previous days' backups obsolete except as safety copies. The redundant levels cover you when a tape is damaged or someone destroys an important file between the two levels.

If this sequence is repeated each week, Monday will always get everything that changed since Friday, because that is the most recent dump with a lower level. Wednesday will also get files that have changed since the level 1 done on Friday, and each subsequent Friday will get everything from the level 0. To capture a week's worth of changes each Friday, just bump the level up each week. So the first weekly dump would be a level 1, but the second week would be a level 2, and so forth until it is time to do a monthly again.

How does dump know when the most recent lower-level dump was done? When the -u update option is specified, dump updates a file called /etc/dumpdates. When dump does an incremental, it peeks in this file to find out how far back it should go. Before using dump for the first time, check to see if the dumpdates file exists and create it if it doesn't. It should be owned by root, belong to the operator group, and have the following permissions:

-rw-rw-r--	(644)

Recommended Options for 1/4" Tapes

One type of 1/4" tape is the Data Cartridge 6150, which has a capacity of 150 Mb. Now, that doesn't mean you can dump 150 Mb of data to the tape, because dump puts a lot of overhead information on there, too, but you can get pretty close. These tapes have a density of 6250 BPI, and a length of 700 ft. However, to get even close to capacity, you need to set the track option and use the cartridge option to set the interrecord gap correctly.

Listing 1 shows a dump command for a level 0 dump to a local 1/4" 150 Mb tape, st0, on a system called pegasus. The argument 0 specifies a level 0 dump; u updates the /etc/dumpdates file; c is the cartridge option. The other option arguments identify the meaning of subsequent arguments: t is the tracks; s is the size, or length of the tape in feet; d is the density; and f is the dump device. The next five parameters are the positional arguments those option letters identified: 18 is the number of tracks; 700 is the length of the tape; 6250 is the density; /dev/rst0 is the tape device. The /judy argument is the file system mount point to dump.

Recommended Options for 8mm Tapes

Some 8mm tapes have a capacity of about 2.3 Gb. That doesn't mean you can dump 2.3 Gb of data to the tape, due to dump's overhead, but you can get pretty close with the correct options. These tapes have a density of 54,000 BPI, and a length of 6,000 ft. Another type of 8mm tape has a 5 Gb capacity. The only difference is length, which is double that of the 2.3 Gb tapes. However, you do have to have a tape drive capable of writing to 5 Gb tapes!

Listing 2 shows a dump command for doing a level 0 dump to a local 8mm 2.3 Gb tape (st1) on pegasus. The b sets the blocking factor. All other options shown have the same meaning as with a 1/4" tape. The next five parameters are positional, starting with 126 as the blocking factor, and so on.

General Recommendations

To dump more than one file system sequentially to the same tape, you need to use the non-rewinding device. In our examples that would be /dev/nrst0 or /dev/nrst1. Also, if the name of the mount point for the file system changes from time to time, you can save yourself some work by using the name of the disk partition in your backup script instead of the name of the mount point. For example, if the /judy directory is actually on /dev/sd0h, use that instead.

Options for Remote System Backups

An easy way to backup remote workstations to a server is to use a command that does a remote shell (rsh) from the server to the workstation, and then a remote dump (rdump) back. For an example, Listing 3 shows a dump command that dumps /dev/sd0h on the workstation called pegasus, and sends the dump to an 8mm 2.3 Gb drive (st1) on a server called mikey.

In order for the rsh portion of the command in Listing 3 to work when running dump as root, pegasus must allow root access from the server without a password. You can set up that access by placing mikey in the /.rhosts file on pegasus. However, to get the dump information back to mikey, pegasus needs to be in mikey's /.rhosts file. This creates a significant security risk for most sites. Remote workstations are not normally granted this privilege. Fortunately, there is a way around this problem.

Setting Up Secure Remote Dumps

Listing 4 uses the user@machine:device format for specifying the tapehost and drive to use. In this example, the user account is called backup. The backup account needs to be a member of the operator group (group 5), and the home directory must have a .rhosts file with a root entry for each machine. Alternatively, you can have a root entry for a netgroup that each remote machine belongs to. (See the man page on netgroup and rhosts for more information.)

A Simple Backup Script

Listing 5 is a versatile but easy-to-understand script that quickly gets you doing backups with dump. However, there are a number of variables you have to set first. Make sure you have the correct tape device and options set for the tape that you are using. Also, you need to set the name of the host that has the tape drive, and the hosts and file systems you want to dump.

If you take a look at the usage information in the parameter checking section, you'll see that the script has two mandatory parameters, level and Day, and two optional ones, tape2 and rew. Use the Day parameter for incremental, weekly, and monthly backups. The script is set up to do each separately. If you want to dump different file systems for several of the incrementals, the daily section can be broken up further. Also, notice that the level is always specified, even on weeklies and monthlies, just in case you want to do something other than a level 0 for these.

Listing 6 is an example of cron entries that execute the backup script, called /admin/bkup for this example, to run the dump schedule explained earlier. It schedules a monthly backup for Saturday morning at 1:00 A.M. on June 26, and on July 31. The monthly backup will replace the weekly, so you should either comment out the weekly for that night, or set up an automatic test to see if another backup is running.

One way to indicate that a backup is already running would be to create a file at the beginning of the script and delete it at the end. Then test for the existence of the file in the crontab entry. Don't run the script if the file exists. Also, set the time in the crontab entry so the monthly runs before the weekly does.

Using Restore

If you use the root crontab to run your backups, an email message will be sent to root containing the output from the script, if you use one, and from the dump command. Save the email message using a file name that indicates what tape the dump went to and the date dump was run. This information is essential to recovering lost files and should be kept until the tape is reused.

Once you determine the correct tape, use the corresponding output from the email message to figure out how many file systems on the tape to skip. Use the mt utility to position the tape. For example, suppose there are ten file systems on the tape:

mikey:/
mikey:/usr
mikey:/opt
pegasus:/
pegasus:/usr
pegasus:/opt
pegasus:/judy
wyvern:/
wyvern:/usr
wyvern:/opt

Now let's say I need to restore a file called sysadmin that was in pegasus:/judy. To do that, I would have to position the tape to the seventh file system (/judy). That means the tape needs to skip past the first six. Here's how to do that:

mikey:/> 1 # mt -f /dev/rst1 rew
mikey:/> 2 # mt -f /dev/nrst1 fsf 6

The first mt command rewinds the tape to the beginning. The second does an fsf (forward space file) for six file systems. Notice that the non-rewinding tape device is used on the second mt command. Otherwise the tape would have rewound back to the beginning after doing the fsf. Once the tape is positioned, it is ready for the restore utility.

The easiest and most informative way to use restore is in the interactive mode:

mikey:/> 3 # restore if /dev/nrst1

restore responds with a restore prompt. There are several commands now available. One of the best to use right away is what. This command responds with information on the date the dump was done, the level of the dump, and the file system. Using what ensures that you have the correct tape positioned at the correct spot.

restore responds to the command help by displaying a list of available commands. Refer to Listing 7 for the output of the help command. Three of the commands, ls, cd, and pwd, perform the same functions that UNIX commands do on disk.

Three other commands, add, delete, and extract, get files and directories off the tape. The add command adds to a list of files and directories to restore. The delete command removes entries. The extract command copies the files and directories on the list from tape to disk. By using add . it is possible to add all the entries in a directory. Take a look at Listing 8 for an example restoration of pegasus:/judy. Notice that the response to the prompt

Specify next volume #:

is "1" -- that's because the tape was a single volume tape.

Under normal circumstances, restore files to a directory such as /tmp, and then tar them over to where they belong. (Use tar, or cpio's -p option, instead of cp to make sure you don't change ownership and permissions!) However, if you are restoring a large directory, you may not have enough room in /tmp. In this case, just make sure that you cd to the mount point of the disk partition before executing the restore command, as shown in Listing 8.

If the file system is on a remote machine, don't forget to mount it first! restore will complain that lower-level directories already exist in the path of the directory you are trying to restore, but that will not hurt anything.

Further Reading

There are several System Administration manuals available on the market that discuss backups in general, dump in detail, and other utilities for doing backups, such as tar and cpio, as well. I recommend the following:

Nemeth, Evi, Garth Snyder, and Scott Seebass. UNIX System Administration Handbook. Englewood Cliffs, NJ: Prentice Hall, 1989. ISBN 0-13-933441-6.

Frisch, AEleen. Essential System Administration. Sebastopol, CA: O'Reilly & Associates, Inc., 1991. ISBN 0-937175-74-9.

Thomas, Rebecca, and Rik Farrow. UNIX Administration Guide for System V. Englewood Cliffs, NJ: Prentice Hall, 1989. ISBN 0-13-942889-5.

About the Author

Judith Ashworth was first exposed to the UNIX operating system in 1983 while working for the University of Texas at Austin Computation Center, and has been working with UNIX solidly since 1989. Since that time she has done both GUI (Graphical User Interface) application development and UNIX system administration. She is currently working for Tadpole Technology Customer Services, where she does SPARCbook Technical Support.