Garry Garrett's Homepage

The makers of BSD unix invented a program to make backups of filesystems called "dump" and a companion program to restore these dumps called "restore". A modified version of dump/restore was written to make use of .rhosts entries to remotely backup/restore filesystems to a tape drive that is on a remote computer. Derivations of dump/restore exist in all major flavors of Unix today.

One of the key concepts that is integral to "dump" is the concept of levels of incrementals. Each dump has a "level" assigned to it. A Level 5 dump will backup everything since the last level 5 (or less) dump (i.e. an incremental dump of all the files that have changed since the last level 5 dump, or the last level 4 dump or the last level 3 dump, etc.). There are levels 0-9, however, level 0 is a special case in that it indicates a full dump, not just the files that have changed since the last level 0 dump. The man pages for the various flavors of dump have various recommended schemes for how you should do your dumps (i.e. on Sunday you do a full, on Monday you do a level 9, on Tuesday you do another level 9, on Wednesday you do a level 3, etc.).

"dump" will make 4 passes over the filesystem being backed up. The first pass collects information about the directories to be backed up. The second pass collects information about the files to be backed up. The third pass writes the directories to the output device (normally a tape). The fourth pass writes the files to the output device. By keeping the directories and files separate, the restore command can read the directory information and allow the user to look at what files are on the tape and then selectively restore them interactively. This is why the backup separates out directories from other files. As "dump" progresses, it will report it's progress, along with an estimate on how long the backup will take. Initally, this estimate is a bit off because it counts the number of bytes of files written, divided by the time since the backup started. This includes the time that the first 3 passes over the data took. As the backup progresses (every 5-10 minutes) and updates on the progress continue, these estimates become more accurate. If a file has changed (say in size) from pass 2 to pass 4, then this is reported. If you run out of tape, you will be prompted to insert a second tape (volume #2) and let "dump" know once that tape is ready to go. This allows you to backup filesystems that are large enough that they will not fit on a single tape. If "dump" is not being run interactively, it will simply exit with an error.

Suppose you have a filesystem, /xyz, that you want to do a full backup of on a local tape drive. Here's how you would do that:

Suppose, instead, that you want to do a level 7 backup on /xyz and that you don't want the tape drive to rewind when you are done (perhaps because you are going to put down a dump of another filesystem onto the tape right after this one)

In order for "rdump" to work, you need to use a .rhosts entry. This has security ramifications as it may allow other traffic between 2 machines (rlogin, rsh, etc.) that you don't intend to allow. Suppose we have 2 computers, A and B. A has a filesystem /xyz that we want to backup. B has a tape drive that we want to use. To make sure that you have your .rhosts entry correct, you will want to login to B from A (use telnet or rlogin, etc.) and type: "who am i". What this does is it runs the "who" command, to see who's logged into B, but it just pulls out your own entry from this output. The output of who includes where you are logged in from. If A is in B's /etc/hosts files, you may simply see "A". If A is resolved via DNS, you may see something like "A.domain.name". If A is not being resolved at all, you may see an IP address. Whatever you see in the output of "who am i" is the same thing that is going to be searched for in the .rhosts file. You may want to make sure that A is in machine B's /etc/hosts file, and that /etc/hosts is checked before other means of resolving names (like DNS, or NIS, etc.) to ensure that someone cannot spoof A's address and make use of this .rhosts entry to gain unathorized access to machine B. So, you sample .rhosts file on B might look like this:

A root

Usually, you would put this .rhosts file in root's home directory. In order to make sure that you have access to all the files that you are backing up, you will probably want to run "rdump" as root on machine A. Some derivations of "rdump" allow you to specify a username, so that instead of accessing machine B as root, you are accessing it at some less privaleged user (look at your man pages for the correct syntax on specifying that), in which case you would add the above information to this less privaleged user's .rhosts entry. An easy way to test that you have your .rhosts correct is to use the "rsh" commmand to run a simple command on machine B from machine A. For example, "rsh B ls /".

Your "rdump" client program will speak to a program "rmt" on the server in order to do a backup. BSD put the "rmt" command in /etc, but System V puts it in /usr/sbin (usually). Linux has followed the BSD methodology and has an /etc/rmt file. If you want to backup a System V computer to a Linus machine, you may need to make a link, /usr/sbin/rmt, to /etc/rmt. AIX, being System V, has an /usr/sbin/rmt file. To backup a Linux machine to an tape drive on an AIX machine, you will need to create a link, /etc/rmt, which points to /usr/sbin/rmt. Solaris 2.x/SunOS5.x is System V, however, Solaris 1.x/SunOS4.x was BSD. For backwards compatibility, Solaris 2.x already has a link /etc/rmt that points to /usr/sbin/rmt.

Suppose that you want to do a level 3 backup of /xyz on machine A, and you want to write that to a tape drive on machine B, and you want to use a block size of 64. Here is what you run on A:

Suppose that you want to do a level 4 dump to a remote machine B, as the user "user" (instead of root):

Solaris's "ufsdump" will, by default, automatically sense the end of tape, even remotely, presuming that the remote host is able to do that. If you specify block size and density, the end of tape will be caculated from those figures (usually incorrectly) instead. You can influence this calcuation by specifying "s" to tell ufsdump the size (the length) of the tape. Linux's "rdump" will calculate end of tape from the block size/density (using the default if you don't specify one). Linux will automatically sense the end of tape, if (and only if) you pass it an argument "-a". This argument will override the calculation even if you specify block size/density. AIX's "rdump" will not detect the end of tape; it will calculate (again, using block size and density) how long it thinks the tape is and will assume that it has hit the end of the tape when it has written enough bytes out to the remote host. You can, however, use "-L" to explicity tell AIX how long the tape is. Of course, with hardware compression used by most modern tape drives, how much you can fit on a tape is largely dependant upon how well the files that you are writing to tape compress. The "length" of a modern tape drive is, by its very nature, variable. In any case, the system is going to calcuate how much data will fit on the tape, you will want to round down a bit in that problems will occur if you really do hit the end of the tape, but you have not written enough bytes that rdump/ufsdump thinks that you have hit the end of the tape. The moral of the story is round down.

Of course, you don't do backups just to do backups. You usually hope never to have to restore them, but, after all, restoring the files is why you do the backups in the first place. As you might expect, "restore" restores files off of a local tape drive, where as rrestore restores files off of a remote tape drive. All the same things need to be in place to run rrestore as need to be in place for rdump (.rhosts, etc.).

The "restore" command has a required argument, which must be one (and only one) of the following: i, r, R, t, and x. The "t" argument says to "test" a restore, which is mainly used to show you what files are in on the tape. The "x" argument will mindelessly extract all the files off of a dump. The "i" argument says to restore files interactively. The "r" and "R" arguments are seldom used (see the man pages for their use). Interactive is the most commonly used mode of restore/rrestore.

With any restore, you will be prompted for which volume to insert. If your dump all fit onto one tape, then you will always have one and only one volume, namely "volume 1". If you were to have a dump that spilled onto 2 tapes, you would have a volume #1, and a volume #2. When restoring, you start with volume #2, and then do volume #1. This is because volume #1's list of files and directories assume that everything fit onto one tape, whereas the list of files and directories at the beginning of volume #2 knows which files fit onto volume #1 and which files fit onto volume #2, etc. For this reason, you should always start a restore with the last volume, and work backwards.

For an "x" or a "t", restore (or rrestore) will simply go about it's business and start restoring. For an interactive restore, the "restore" command will read the directory structure (i.e. pass 3 when you made the dump), and will give you a prompt. Consult the man pages for restore to find out all the commands that you can issue at this prompt, or issue the "help" command. The ones that are commonly used are: ls, cd, pwd, add, delete, extract, and quit. You may recognize some of these commands as commands you can issue at a shell prompt to navigate a filesystem. "ls" will show you a list of files. You are presented with the directory structure of what files are in this dump. You may have to "cd" to change directories to a subdirectory to look at files there. You can use "pwd" to print your working (current) directory (i.e. where, in the filesystem on the tape backup, that you have cd'ed into). You have no command to change your current directory in the disk filesystem that you are restoring to - you need to change directories to wherever you want to restore to before you issue the restore command. "ls" does not take all the arguments that /bin/ls does. You can't see things like date/time stamps on the files in the dumped filesystem. Names of directories will show up in "ls" with a trailing "/" on the end to indicate that they are directories. Names of files that are on the "extraction list" will show up with a astrisk appended to their names. Once you have found a file or directory that you want to restore, you can type "add name" where "name" is the name of the file or directory. If "name" is a file, that file gets added to the extraction list. If "name" is a directory, then that directory is recursively added to the extraction list. You can then use "delete" to remove files/directories from the extraction list. When you are done picking and choosing which files to extract, you can type "extract" to extract them (exiting "restore" when you are done) or you can issue "quit" to exit out of "restore" without extracting anything. Note: when you "add" a file, the "restore" command will, at that time, create a directory tree to put the extracted files into. If you later delete the file from the extraction list, those created subdirectories will remain. "add" and "delete" will accept wildcards. Many people use interactive restores, even though they are going to extract everything, to get a chance to "doublecheck" and make sure that what they are extracting is what they think they are extracting. When you restore, the restore command may also create a file called "restoresymboltable" or ".restoresymtab", etc. which is a symbol table indicating what has been restored. Unless you know how to read this file (and most people don't), usually you just delete it (you may want to leave it around as a reminder that some files have been restored).

When you dump a filesystem, all of the files within that filesystem that are dumped onto tape are dumped with relative paths (e.g. if you dump /usr, then /usr/lib, will show up as "./lib"). When you restore, your restored files are extracted using relative paths, which are relative to the mount point of the filesystem (e.g. if you dumped /usr, and then you cd into /tmp/xyz and rand restore, restoring ./include/sys/*, then you will create /tmp/xyz/include/sys/*, etc. - if you quit out before you restore, you still create the directories /tmp/xyz/include and /tmp/xyz/include/sys, etc.). It is not uncommon to restore files to a different directory than you dumped them from so that you can selectively move into place only those files that you want to.

Here is an example of using restore/ufsrestore to read from a local tape drive, restoring interactively:

Here is an example of using rrestore/ufsrestore to mindlessly restore everything from a remote tape drive, without rewinding it:

That's really about it. Of course, in the ideal world, you want the filesystem that you are backing up to be as quiet as possible. For example, in solaris, you could unmount the filesystem so that it is not in use at the time: "ufsdump 0f /dev/rmt/0 /dev/rdsk/c0t1d2s3" (where /dev/rdsk/c0t1d2s3 is the raw device associated with /xyz). It is sometimes best to shutdown a box and boot up into single user mode / maintainence mode, etc. I say reboot, rather than shutdown into some kind of maintainence mode because, although shutting down into single user mode and booting up into single user mode, should net you the same thing (i.e. the same processes running), that is rarely the case (this is becuase often programmers write a "startup" script to start up a daemon, but fail to think about shutting a daemon down, thus if you come down into a given run level, you have more running than if you booted up into that same run level).

You can also use dump to move filesystems on a box. The following example copies a directory /from into a directory /to

I'll probably add to / restructure this document later, but I'll go ahead and publish this for now. Feel free to give me some feedback or if you have information about versions of "dump" on other OSes, please pass it along.