A few newer versions of dump have done away with these options and provided a new size in kilobytes option that you can use to specify the size of the volume in kilobytes. Even so, I personally use the s and d options with every dump command I run so that I don't have to remember how different versions work. You will find this is a common theme throughout this book: the more things you can
Page 80
Avoid Creating a dump Backup Across Multiple Volumes
By "across multiple volumes," I mean that this is a single dump backup that starts on one volume, runs until it hits LEOT or PEOT, and then continues on another volume. For example, if you have a 4-GB DDS tape drive and are backing up a 2-GB filesystem and a 3-GB filesystem, the first dump backup would fit on the tape. The second one would fill up the rest of the tape, requiring you to insert a second tape to allow dump to finish. (See Figure 3-2.)
In my opinion, creating a backup in this manner is asking for trouble. If you have no choice, then you must do it, but it raises some questions and adds difficulty to your restore. For example, you have to load tape 1 and start reading it before you can load tape 2. It's already hard enough to do a restore in the first place! Also, I start wondering about how safe the files are that are stored near the end of the first tape. Are you sure they're safe? The dump command can be funny sometimes.
Figure 3-2.
Example of a multiple-volume dump backup
do the same everywhere, the fewer things you have to worry about. The more per-host and per-OS customization you do, the more trouble you can get into. (For example, the size in kilobytes option uses a different letter on each version of Unix that supports it!) In this case, using the archaic size and density options actually makes writing shell scripts much easier, since you can use the same options on most versions of Unix.
What happens, then, if you don't use either the s, d, or size in kilobytes options? On some Unix flavors, dump uses the default values for size and density (except for AIX, which has apparently done away with these options altogether). Unfortunately, the default values usually are set to work with a nine-track tape. (Solaris has changed its default values to be slightly more sensible.) If this happens, dump will think it needs several volumes. The output of dump will look something like the following:
DUMP: Estimated 5860 blocks (3006KB) on 39.00 tapes.
Page 81 Notice that it thinks it's going to need 39 tapes. This is what can happen if you do not use the size and density options to specify the capacity of the volume. As mentioned before, you can easily disable this feature by setting these values to some ridiculously high figure, so that dump never thinks that it's run out of tape. (I personally use numbers like 1,000,000 for both.)
Option: specifying a backup device file (f)
The f option specifies the name of the backup device to which you are sending the data. (This "device," of course, could be either an actual tape device or a file sitting on a disk, optical platter, or CD.) If you are expecting to use the hardware compression feature of your tape drive, make sure that you choose the device that supports compression. If you want to send the data to a drive on another system, use the format remote_system_name:device. Most versions of Unix support using remote devices in dump.
Remote devices require that the host with the remote device trust this host via the /.rhosts file. If you try to use a remote device from a nontrusted system, you might get the dreaded message:
Permission Denied
To test if you are a trusted host, try issuing the following command as root:
rsh remote_system uname -a
If it does not work, then you need to put a line with this system's name in the remote system's ~root/.rhosts file.
The use of rsh and /.rhosts files is a major security hole, and many sites no longer allow their use! Don't go creating /.rhosts files everywhere and blame it on me. Make sure you investigate whether you are allowed to use rsh at your site before you start using it. If you are not allowed to use rsh, you might want to look at implementing ssh as a drop-in replacement for rsh. See "Using dd and rsh (or ssh) as a Conduit Between Systems" later in this chapter for more information.
Unfortunately, in today's mixed environments, you don't always know what other systems think a particular system's name is. The remote system might be using DNS, NIS, or a local hosts file. When you rsh to a system, it initially sees you as an IP address. It then does a gethostbyaddr() and tries to resolve that address into a name.
Depending on how your particular system is set up, it may consult DNS, NIS, or the local /etc/hosts file-the order in which it consults these sources also varies with your setup. If it uses the local hosts file or NIS for address resolution, it
Page 82 may or may not appear with a fully qualified domain name such as apollo.domain.com. If it uses DNS, then it will appear with the fully qualified domain name. It is important to know this, since this is the name that you must put into the .rhosts file. Suppose your system is called apollo, and the remote system is elvis. If you want to rsh from apollo to elvis, you should try the easy step first. On elvis, you would enter this command:
echo apollo >>/.rhosts
If that doesn't work, then apollo appears as something else to elvis (e.g., apollo.domain.com). To find out for sure, you can telnet to elvis from apollo, then use commands like last, who, tty, or netstat and look at the field that lists the system from which you came. If it turns out to be apollo.domain.com, then put that into the /.
rhosts file on elvis. (For example, at one client site, it would appear as apollo. DOMAIN.COM.) Once you have put the correct name in /.rhosts, the rsh should work.
Option: displaying which filesystems need to be backed up (W and w)
The W and w options of dump are available on most Unix systems and display information about which filesystems need to be backed up. Usually the w option displays information on all filesystems, while the W option lists only those filesystems that need to be backed up, based on the backup level you have chosen. These options have slight variations between Unix flavors, so read the appropriate manpage.
Other options: interesting options for Solaris's ufsdump utility
Solaris's ufsdump has a few options not found in other versions of Unix. It supports the -l (autoloader), o (off-line), a (archive file), and v (verify) options:
• The l, or autoloader, option ejects the tape if it reaches PEOT before dump is done. It then waits up to two minutes for the next tape to be inserted. This works well with sequential autoloaders.
• The o, or offline, option merely ejects the tape at the end of the backup, protecting the tape from being overwritten by another process.
• The a, or archive file, option writes dump's table of contents to archive_file (as well as writes it to the volume, as all dump commands do). This file can then be used by ufsrestore to see if a file is on a given volume without having to mount that media.
• The v, or verify, option compares the backup to the actual filesystem. While this may sound good in theory, it requires the filesystem to be unmounted, which is not practical in many applications.
Page 83 What a dump Backup Looks Like
This section explains one primary difference between dump and its cousins, tar and cpio. dump writes a table of contents at the beginning of each volume, while tar and cpio do not.
dump records an index on the volume
The index is read during an interactive restore, allowing you to do commands like cd and ls on this table of contents, viewing and selecting files that you want for the restore. (The restore utility is discussed later in this chapter.) This interactive restore feature is one of restore's biggest advantages over tar and cpio. There is one important thing to note about this index: it is made at the beginning of the backup, before it has tried to actually back up anything. The presence of the index makes the interactive restore efficient, since you don't have to read the whole volume before you can see what's on it. But the fact that it's created before the backup data is written, and possibly minutes or hours before the data is written to tape, means that files made during the backup are not included, and files deleted during the backup are listed on the index but are not actually on the volume.
Using the index to create a table of contents
You can create a table of contents of a dump volume by physically reading the contents of the index that dump creates and seeing what dump intended to write to the volume. Also, it is important to mention that this reading of the volume in no way guarantees the integrity of the actual file on the volume, any more so than an ls -l on a file in a directory verifies its integrity. You may be wondering why this discussion is included here, in the section about dump; it is because making this table of contents should be a part of every dump backup that you take. Having said that, how does one create a table of contents of a dump file? First, what does a "dump file"
really mean? Perhaps an illustration would help. See Figure 3-3.
Figure 3-3.
The format of a dump tape
A volume created by dump may have multiple dump files, sometimes called "partitions," on it. Each file ends in an end-of-file (EOF) mark, symbolized in Figure 3-3 by shaded areas.
Page 84
You have two options if you want to obtain a table of contents for ''Dump file 3" in Figure 3-3:
• You can tell restore to read the third file on a tape using the s option; this causes restore to skip files 1 and 2 and read file 3. (This option does not apply to disk-based dump backups.)
• You can manually position the tape (using mt or tpctl) so that it is sitting at the beginning of that file. You then tell restore to read it as if it were the first file on the tape.
You must know the blocking factor in which the volume was written. If you are not sure, then try the default by not specifying a blocking factor. If that doesn't work, see "How Do I Read This Volume?" near the end of this chapter.
The first method is the easiest, since it involves only one step. The syntax of the command is as follows:
$ restore tsbfy file blocking-factor device
To read the third dump file on the tape with a blocking factor of 32, use the following command:
$ restore tsbfy 3 32 /dev/rmt/0cbn
• The t option tells restore to read the volume index and give you a table of contents.
• The s option, and its accompanying argument 3, tells restore to read the third dump file on a tape.
• The b option, and its accompanying argument 32, tells restore that you used a blocking factor of 32 when you wrote this dump file.
• The f option, and its accompanying argument dev, specifies that the dump file is on that device.
• The y option tells restore to continue in the case of errors, instead of asking you if you want to continue.
If you do choose to manually manipulate the tape, as in the second option, you need to be familiar with your Unix version's magnetic tape command. This is usually mt. It has five options-status, rewind, offline, fsf, and fsr-four of which you might use when manipulating dump tapes. The format of the command is:
$ mt -t device argument
Page 85
If you are planning to position the tape, make sure you are using a nonrewinding device, such as /dev/rmt/On. Otherwise, it will rewind as soon as you finish positioning it!
Some versions of mt use a -f instead of a -t. The device argument is the no-rewind tape device that you are using, such as /dev/rmt/On. Then specify one of the following for argument
status
This gives you the ioctl status of the tape device. It does not require an accompanying argument.
rewind
This rewinds the tape to the beginning. This option is spelled rew on some versions of Unix. It does not require an accompanying argument.
offline
This ejects the tape from the tape drive. This option is spelled offl on some versions of Unix. It does not require an accompanying argument.
fsf x
This is short for "forward space file." It positions the tape forward x file marks, where x is a number greater than 0. (If you do not specify a value for x, it defaults to 1.) If you are at the beginning of the tape, you are at file 1, so if you want to be at file 3, you need to go forward two files. This requires an fsf 2, as in mt-t device fsf 2.
fsr x
This is short for "forward space record," and is not needed when manipulating dump tapes. (If you do not specify a value for x, it defaults to 1.) The following are examples of how to use the mt command. To rewind the tape/dev/rmt/0cbn, issue the command:
# mt -t /dev/rmt/0cbn rewind
To forward the tape /dev/rmt/0cbn to the second file on the tape, issue the command:
# mt -t /dev/rmt/0cbn fsf 1
To eject the tape /dev/rmt/0cbn, issue the command:
# mt -t /dev/rmt/0cbn offline
To get the status of the tape /dev/rmt/0cbn, issue the command:
# mt -t /dev/rmt/0cbn status
Page 86 Once you position the tape to the proper file, you simply use the same restore command as before, leaving off the s option and its argument:
$ restore tbfy 32 /dev/rmt/0cbn
Whichever method you use, the table of contents is sent to standard output, which you should redirect into a file. One important thing to note about this output is that the name of the filesystem dumped to this volume is not in the output. This table of contents is relative to that filesystem, whatever its name was. For example, if you backed up /var, and you were looking for /var/adm/messages, the output would look something like this:
345353 /adm/messages
I recommend that you create a table of contents for each dump volume when you make it and store this output in a file that matches the name of the volume. Obviously you should use a unique name, like:
./dump.system.filesystem.level0.Oct19.1999
Saving the tables of contents in this way is very handy when you're searching for file, and you can't seem to find it on any volume. A quick grep of all the dump files shows you which volume you need.
Automating Your dump Backups: The hostdump.sh Utility
If you are using dump for your regular system backups, like any backup methodology, it should be automated. Simply putting a single-line dump command in cron is not enough; you need a script that includes at least the following features:
• Sanity and return-code checks to ensure that dump and restore are doing what you think they're doing
• An "intelligent" way of deciding which filesystem to back up, rather than just an include list (see "Are You Backing Up What You Think You're Backing Up?" in Chapter 2 for more information on include lists)
• Some method of dealing with hosts that won't fit on a single volume
• Creation of a table of contents by reading the volumes after the backup and saving the table of contents to a file (once again, this table of contents can be used when you are looking for a particular file. If you name the table of contents the same as the volume, simply grep for the filename out of table-of-contents, and you've got the names of the volumes that have the file you are looking for)
This section presents hostdump.sh, a shell script that has grown over the years to include all of the preceding features, as well as a few more. It was first written Page 87 several years ago to back up Ultrix boxes, and it has grown to support many other Unix versions. The script currently supports almost every version of Unix that I could find that uses some form of dump. It should run unmodified on each version of Unix listed at the top of the program. I continue to update it based on reader input, including bug fixes and adding other Unix versions. The script is available on the web site listed in the front of the book and is included with the accompanying CD-ROM.
If your version of Unix is supported by hostdump.sh, it's pretty much plug-and-play. All you have to do is put in a volume, give it a device name and hostname, and it does the rest. hostdump.sh backs up all the hosts that you list to the device that you specify. It automatically determines the names of all the filesystems and their filesystem types. If the filesystem type supports dump, it calls the appropriate command. If it is an unknown filesystem or one that does not have a good dump command, hostdump.sh uses cpio. The script also puts two extra tar files on the volume. The first is a header put on the first partition of the tape* that lists all the filesystems on the volume and the commands that were used to back them up. After all backups are done, it then rereads the table of contents of each of the backups and places that information into another tar file at the end of the volume. (The tar file at the beginning of the volume contains detailed instructions on how to find and read the tar file at the end of the volume, including which partition it will be placed on.)
To back up one or more Unix systems, simply tell the script what level of backup to perform, what device to use, what file to log to, and what systems to back up. To do this, issue the following hostdump.sh command:
# hostdump.sh level device logfile system_list
For example, to perform a level 0 backup of apollo and elvis to /dev/rmt/Ocbn on apollo and log it to /tmp/backup.log, issue the following command on apollo:
# hostdump.sh 0 / dev/rmt/Ocbn /tmp/backup.log apollo elvis
hostdump.sh automatically determines the names of all the filesystem and backs them up to the backup drive device that you specify. Sometimes you don't want to
hostdump.sh automatically determines the names of all the filesystem and backs them up to the backup drive device that you specify. Sometimes you don't want to