Restoring Backed Up Files

The restore command is used to retrieve files from a backup tape or other medium that was created by dump. You can use restore to recover an entire file system or to interactively select individual files. It recovers files from the specified media and copies them into the current directory (the one you ran the recover command in), re-creating subdirectories as needed. Much as with the dump command, the first parameter passed to the restore command is a list of single character option codes, as shown in Table 13-5.

Table 13-5: Restore Command Options
Restore Options	Description
-r	Restore the entire dump archive.
-C	Compare the contents of the dump file with the files on the disk. This is used to check the success of a restore.
-R	Start the restore from a particular tape of a multitape backup. This is useful for restarting an interrupted restore.
-X filelist	Extract only specific files or directories from the archive. This option takes one argument, a list of files or directories to extract.
-T file	List the contents of the dump archive. If a file or directory is given as an argument, list only the occurrence of that file, directory, or anything within the directory.
-i	Restore files in interactive mode.
-b blocksize	Specify the block size of the dump in kilobytes. This option takes a numeric argument.
-D filesystem	Specify the name of the file system to be compared when using the -C option. The file system name is passed as an argument.
-F script	Specify the name of the dump archive to restore from. This option takes an alphanumeric argument.
-h	If this option is specified, restore re-creates directories marked for extraction but will not extract their contents.
-m	Files are extracted by inode number instead of name. This is generally not very useful.
-N	Instead of extracting files, print their names.
-s file#	Specify the dump file to start with on a multiple file tape. This takes a numeric argument.
-T directory	Tells restore where to write any temporary files. This is useful if you booted from a floppy (which has no space for temporary files).
-v	Run in verbose mode. This causes restore to print information about each file as it restores it.
-y	The restore command will always continue when it encounters a bad block, rather than asking you if you want to continue.

Restoring an entire file system

Let's return to our earlier example of the Friday disk crash. You installed a shiny new hard drive and your backup tapes are in hand. It is time to restore the files. For the purpose of this example, I assume that the crashed drive contained only the /home partition and that the Red Hat Linux operating system is still intact. If the crashed drive had contained the Red Hat Linux operating system, you would first have to reinstall Red Hat Linux before restoring the backup.

Before any files can be recovered to your new hard drive, an empty file system must be created on it. You will use the mkfs command to do this. The mkfs command can accept a variety of parameters, but usually you only need to supply the name of the device to create the file system on. Thus, to prepare the new hard drive type:

# mkfs /dev/hda6

Alternatively, because our /home drive is listed in the /etc/fstab file, we can simply specify the /home mountpoint and mkfs will figure out the correct device. Thus, the preceding command could be replaced with this:

# mkfs /home

Caution?

You should, of course, exercise extreme caution when using the mkfs command. If you specify the wrong device name, you could unintentionally wipe out all data on an existing file system.

After creating a file system on your new disk, mount the partition to a temporary mount point.

# mkdir /mnt/test
# mount /dev/hda6 /mnt/test

This connects the new file system to the /mnt/test directory. Now change into the directory (cd /mnt/test) and use the restore command to recover the entire file system off of your backup tape. Of course, it is assumed that you have loaded the tape into the tape drive.

# cd /mnt/test
# restore rf /dev/nrft0

When the restore is finished, you can unmount the partition and remount it to the appropriate mount point. If you have restored the file system to a different physical partition than it was originally on, be sure to modify the /etc/fstab file appropriately so that the correct partition is mounted next time the system is rebooted.

Recovering individual files

The restore command can also be used to recover individual files and directories. By using restore in interactive mode, you can type a series of restore commands to selectively restore files. To run restore in interactive mode, use the i parameter instead of r:

# restore if /dev/nrst0

The restore command will then read the file index from the backup tape and present you with a restore prompt. At this prompt, you can type the commands that enable you to select which directories and files to recover. You can navigate the directory structure of the backup index much the same way that you navigate an actual file system using a shell prompt. The interactive restore command even has its own version of the familiar cd and ls commands, as shown in Table 13-6.

Table 13-6: Interactive restore Commands
Command	Description
add	Add a file or directory to the list of files to be extracted. If a directory is marked for extraction, all of the directories and files within it will also be extracted.
cd	Change the current directory being viewed within the dump archive. Works similar to the cd command used at a shell prompt.
delete	Delete a file or directory from the list of files to be extracted. Deleting a directory from the list results in all of the files and directories within it also being deleted.
extract	Extract all of the marked files and directories from the archive and write them back to the file system.
help	List the available commands.
ls	List the contents of the current directory. If a directory name is provided as an argument, list the contents of that directory. Files or directories marked for extraction have a * character in front of them.
pwd	Print the full path name of the current directory of the dump archive.
quit	Exit the interactive restore program.
setmodes	Do not restore the files; instead, set the modes of already existing files on the target disk to match the modes recorded in the dump file. This is useful for recovering from a restore that was prematurely aborted.
verbose	Toggles verbose output versus quiet output during the restore process. Verbose output mode will echo information to the screen for every file that is restored.

As an example, pretend that the user joe has accidentally deleted his Mail subdirectory from his home directory. Joe happens to be your boss, so it is urgent that you recover his files. Here is how you may go about it.

Load the appropriate tape into the tape drive and log in as root. Use the cd command to go to the top of the /home partition, and then run the restore program in interactive mode:

# cd /home
# restore if /dev/nrft0

Verify that you have the backup tape for the /home partition by entering the ls command. You should see something like the following list of directories, representing users that have home directories in /home:

restore > ls
.:
bob/        jane/       joe/        lost+found/ mary/       thad/

Yes, this is the home partition. Now change the current directory to Joe's home directory using the cd command. Type ls again to view the contents of his home directory.

restore > cd joe
restore > ls
./joe:
.mozilla/           Desktop/            report.html
.tcshrc             Mail/               letter.txt
.xinitrc            News/               www/

Now mark the Mail directory for extraction using the add command:

restore > add Mail

If you use the ls command again, you see that the Mail directory is preceded with an asterisk (*) character, which means it has been marked for extraction.

restore > ls
./joe:
.mozilla/            Desktop/             report.html
.tcshrc             *Mail/                letter.txt
.xinitrc             News/                www/

Now use the extract command to begin the extraction process. restore will prompt you for the number of the tape to start with. This is a single tape backup, so just enter the number 1. When it prompts you to "set owner/mode for '.'?," answer yes by typing y and pressing Enter. restore will then set restore the file permissions (if necessary) of the directory it is restoring to. This isn't critical when extracting individual files like this, but you should always answer yes to this prompt when doing a full restore. Anyway, your screen should now contain the following:

restore > extract
You have not read any tapes yet.
Unless you know which volume your file(s) are on you
should start with the last volume and work toward the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
restore >

At this point, the files have been recovered and you can exit the restore program by issuing the quit command. That's all there is to it. You now know the basics of using the dump and restore commands.

Configuring Amanda for network backups

Using Amanda (the Advanced Maryland Automatic Network Disk Archiver), you can use a single large-capacity tape drive on a server to back up files from multiple computers over a network. The Amanda package includes a variety of commands. The online man page for Amanda describes the commands as shown in Table 13-7.

Table 13-7: Backup Commands Used with Amanda
Command	Description
amdump	Do automatic Amanda backups. It is normally run by cron on a computer called the tape server host and requests backups of file systems located on backup clients. amdump backs up all disks in the disklist file to tape or, if there is a problem, to a special holding disk. After all backups are done, amdump sends mail reporting failures and successes.
amflush	Flush backups from the holding disk to tape. amflush is used after amdump has reported it could not write backups to tape for some reason. When this happens, backups stay in the holding disk. After the tape problem is corrected, run amflush to write backups from the holding disk to the tape.
amcleanup	Clean up after an interrupted amdump. This command is only needed if amdump was unable to complete for some reason, usually because the tape server host crashed while amdump was running.
amrecover	Provide an interactive interface to browse the Amanda index files and select which tapes to recover files from. amrecover can also run amrestore and the system restore program (such as tar) sometimes.
amrestore	Read an Amanda tape, searching for requested backups. amrestore is suitable for everything from interactive restores of single files to a full restore of all partitions on a failed disk.
amlabel	Write an Amanda format label onto a tape. All Amanda tapes must be labeled with amlabel. amdump and amflush will not write to an unlabeled tape.
amcheck	Verify the correct tape is in the tape drive and that all file systems on all backup client systems are ready to be backed up. Can optionally be run by cron before amdump, so someone will get mail warning that backups will fail unless corrective action is taken.
amadmin	Take care of administrative tasks, such as finding out which tapes are needed to restore a file system, forcing hosts to do full backups of selected disks, and looking at schedule balance information.
amtape	Take care of tape changer control operations, such as loading particular tapes, ejecting tapes, and scanning the tape rack.
amverify	Check Amanda backup tapes for errors (GNU tar format backups only).
amrmtape	Delete a tape from the tape list and from the Amanda database.
amstatus	Give the status of a running amdump.

The amdump command is the one that you will use the most, but before you can get started, you need to configure a few things on both the backup server (the system with the tape drive) and the backup clients (the systems being backed up).

Creating Amanda directories

You need to create some directories to hold the Amanda configuration files and to provide a location to write Amanda log files. The configuration files go in an /etc/amanda directory, and the log files go in /var/lib/amanda. In both cases, you should log in as the amanda user and create subdirectories within those directories, one subdirectory for each backup schedule that you intend to run and an index file, as shown here:

Note?

For security reasons, you should do all amanda administration as the amanda user. To do this, the root user should create a password for amanda by typing passwd amanda and entering the new password. The rest of this procedure assumes that you are logged in as the amanda user.

# su - amanda
$ mkdir -p /var/lib/amanda/normal
$ mkdir –p /var/lib/amanda/normal/index
$ mkdir -p /etc/amanda/normal

For the purpose of this example, I have created only a normal backup configuration that backs up the data drives on several machines. You may also decide to create an upgrade backup configuration that backs up the operating system partitions. You could then run that backup before you perform any operating system upgrades.

You also need to specify a holding disk that Amanda can use to temporarily spool backups before it writes them to disk. This directory should have a lot of free space. I have a large /home partition on my server, so I created an Amanda directory there to use as a holding disk:

# mkdir /home/amanda
# chmod 700 /home/amanda
# chown amanda /home/amanda
# chgrp disk /home/amanda

Creating the amanda.conf file

Next, as the amanda user, you must create two configuration files for Amanda and store them in the /etc/amanda/normal directory: amanda.conf and disklist. You can start by copying samples of these files from the /etc/amanda/DailySet1 directory as follows:

$ cd /etc/amanda/DailySet1
$ cp amanda.conf disklist /etc/amanda/normal

The amanda.conf file sets a variety of general configuration values, and the disklist file defines which machines and partitions to back up. The amanda.conf file can be rather complicated, but, fortunately, most of its values can be left at their default values. Here is a simplified amanda.conf file with some comments embedded in it to help explain things:

#
# amanda.conf - sample Amanda configuration file. This started life as
#               the actual config file in use at CS.UMD.EDU.
   
org "GLACI"        # your organization name for reports
mailto "amanda"    # space separated list of operators at your site
dumpuser "amanda"  # the user to run dumps under
   
# Specify tape device and/or tape changer. If you don't have a tape
# changer, and you don't want to use more than one tape per run of
# amdump, just comment out the definition of tpchanger.
   
runtapes 1              # number of tapes to be used in a single
                        # run of amdump
tapedev "/dev/nrft0"    # the no-rewind tape device to be used
rawtapedev "/dev/rft0"  # the raw device to be used (ftape only)
   
tapetype HP-DAT   # what kind of tape it is
         # (see tapetypes below)
labelstr "^normal[0-9][0-9]*$"   # label constraint all
                                 # tapes must match
   
# Specify holding disks. These are used as a temporary
# staging area for dumps before they are written to tape and
# are recommended for most sites.
   
holdingdisk hd1 {
    comment "main holding disk"
    directory "/home/amanda"   # where the holding disk is
    use 290 Mb                 # how much space can we use on it
    chunksize -1               # size of chunk
    }
   
# Note that, although the keyword below is infofile, it is
# only so for historic reasons, since now it is supposed to
# be a directory (unless you have selected some database
# format other than the `text' default)
   
infofile "/usr/adm/amanda/normal/curinfo"   # database DIRECTORY
logdir   "/usr/sdm/amanda/normal"      # log directory
indexdir "/usr/adm/amanda/normal/index"   # index directory
   
# tapetypes
   
# Define the type of tape you use here, and use it in "tapetype"
# above. Some typical types of tapes are included here. The
# tapetype tells amanda how many MB will fit on the tape, how
# big the filemarks are, and how fast the tape device is.
   
define tapetype HP-DAT {
    comment "DAT tape drives"
    # data provided by Rob Browning <rlb@cs.utexas.edu>
    length 1930 mbytes
    filemark 111 kbytes
    speed 468 kbytes
}
   
# dumptypes
#
# These are referred to by the disklist file.
   
define dumptype global {
    comment "Global definitions"
    # This is quite useful for setting global parameters, so you
    # don't have to type them everywhere.
}
   
define dumptype always-full {
    global
    comment "Full dump of this filesystem always"
    compress none
    priority high
    dumpcycle 0
}

This example amanda.conf was trimmed down from a larger example I copied from the /etc/amanda/DailySet1 directory. The example amanda.conf file provides additional information on the available configuration options. Also, the online man page for Amanda should be helpful (type man amanda to read it). You can find more instructions in the /usr/share/doc/amanda-server* directory. Generally, you have to do the following:

Modify the org name for reports.
Change the device names set for tapedev and rawtapedev to match your tape device.
Select a tape type entry that is appropriate for your tape drive.
Change the name of the directory specified in the holding disk section to match the directory you created earlier.

Creating a disklist file

You also must create a disklist file in the /etc/amanda/normal directory. This simply contains a list of the systems and disk partitions to back up. The qualifier always-full is included on each entry to tell Amanda what type of backup to perform. It means to use full, rather than incremental, backups.

# sample Amanda2 disklist file
#
# File format is:
#
#       hostname diskdev dumptype [spindle [interface]]
#
# where the dumptypes are defined by you in amanda.conf.
   
dexter hda5 always-full
dexter hda6 always-full
dexter hda7 always-full
dexter hda8 always-full
   
daffy hda5 always-full
daffy hda6 always-full
daffy hda7 always-full
daffy hdb1 always-full
daffy hdb2 always-full

This example file backs up two systems, dexter and daffy. The order of the systems and the partitions is selected so that the most important data is backed up first. This way, if a tape drive becomes full, you have still managed to back up the most important data.

Adding Amanda network services

Amanda is designed to perform backups over a network. The following amanda services are defined in the /etc/services file:

amanda          10080/udp
amanda          10080/tcp
amandaidx       10082/tcp
amidxtape       10083/tcp

On the amanda server

To offer these services to the network in Red Hat Linux, you need to configure the xinetd daemon to listen for those services. You do this by enabling the amandaidx and amidxtape services by typing the following (as root user):

# chkconfig amidxtape on
# chkconfig amandaidx on

This enables Amanda to accept requests from the client system and to start the backup process without any user intervention. You need to tell the xinetd daemon to reload the /etc/xinetd.d files before this change takes place. You can do this by typing the following as root user:

# /etc/init.d/xinetd restart

On each amanda client

You next need to configure the .amandahosts file in the /var/lib/amanda directory on each computer (client) that the amanda server will backup from. This file should contain the fully qualified host and domain name of any backup servers that will connect to this client. When you begin, only your localhost is defined in this file as your backup server. To add another computer as a backup server, you could type the following (replacing amandahost with the name of the backup server, while you are logged in as the amanda user):

$ echo amandahost >> /var/lib/amanda/.amandahosts

You also need to make sure that the amanda client daemon is configured to run on the client. You do this by enabling the amanda service by typing the following (as root user) :

# chkconfig amanda on

This enables the amanda client to communicate with the amanda server. You need to tell the xinetd daemon to reload the /etc/xinetd.d files before this change takes place. You can do this by typing the following as root user:

# /etc/init.d/xinetd restart

Performing an Amanda backup

Now that everything is configured, you are ready to perform an Amanda backup. While logged in as root, type the following command:

# /usr/sbin/amdump normal

This runs the amdump command and tells it to read the configuration files it finds in the /etc/amanda/normal directory created earlier. It then works its way down the list of systems and partitions in the disklist file, backing up each partition in the order it occurs. The results of the amdump are written to the /var/lib/amanda/normal directory. Read the files you find there to check on the results of the backup. (See the previous section on how to create a disklist file to understand the process that amdump goes through.)

You can, of course, automate this process with cron. To create an amdump schedule similar to the regular dump schedule discussed in an earlier section, do the following. While logged in as root, enter the crontab command with the -e option:

# crontab -e

This opens the root crontab file in an editor. Add the following lines to the end of the file:

0 22 * * 0 /usr/sbin/amdump normal
0 22 * * 1 /usr/sbin/amdump incremental
0 22 * * 2 /usr/sbin/amdump incremental
0 22 * * 3 /usr/sbin/amdump incremental
0 22 * * 4 /usr/sbin/amdump incremental
0 22 * * 5 /usr/sbin/amdump incremental
0 22 * * 6 /usr/sbin/amdump incremental

Save and exit the file. The cron daemon will now run amdump at 10:00 p.m. (22:00 in military time) every day of the week. This example assumes that a second incremental configuration has been created. You can do this by creating a subdirectory named incremental under /etc/amanda and populating it with appropriately modified amanda.conf and disklist files. You must also create a subdirectory named incremental under /usr/adm/amanda so that amanda has somewhere to write the logfiles for this configuration.

It may be a bit of work to get it all in place, but once you do, Amanda can make your network backups much easier to manage. It may be overkill for a small office, but in a large enterprise network situation, it enables Red Hat Linux to act as a powerful backup server.