Red Hat Linux Networking , System Administration (P28) pot

Directory and file names:
prefix=PREFIX install architecture-independent files in
PREFIX
[/usr/local]
exec-prefix=EPREFIX install architecture-dependent files in
EPREFIX
[same as prefix]

Host type:
build=BUILD configure for building on BUILD [BUILD=HOST]
host=HOST configure for HOST [guessed]
target=TARGET configure for TARGET [TARGET=HOST]
Features and packages:
disable-FEATURE do not include FEATURE (same as enable-
FEATURE=no)
enable-FEATURE[=ARG] include FEATURE [ARG=yes]
with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
without-PACKAGE do not use PACKAGE (same as with-PACKAGE=no)
x-includes=DIR X include files are in DIR
x-libraries=DIR X library files are in DIR
enable and with options recognized:
with-pkg use software installed in /usr/pkg tree
with-libedit support fancy BSD command input editing
with-readline support fancy command input editing
The key options in the example output are prefix and the three options
that appear under the heading enable and with options recognized,
with-pkg, with-libedit, and with-readline. prefix
enables you to specify an installation directory other than the default (indicated
in brackets, []), /usr/local. For this example, the root installation directory is
/tmp/bctest, specified as prefix=/tmp/bctest on configure’s com-
mand line. The second group of command line options enables other features.

This example uses with-readline, which turns on support for the GNU
readline library. The readline library enables command line editing inside the bc
program, just as the bash shell permits editing the shell command line.
After selecting the desired options, run configure with the appropriate
options, as shown in the following example. (Again, the output has been
edited to conserve space.)
$ ./configure prefix=/tmp/bctest with-readline
creating cache ./config.cache
checking for a BSD compatible install /usr/bin/install -c
checking whether build environment is sane yes
checking whether make sets ${MAKE} yes
checking for working aclocal found
checking for working autoconf found
checking for working automake found
774 Chapter 30
38_599496 ch30.qxd 8/30/05 7:36 PM Page 774
checking for working autoheader found
checking for working makeinfo found
checking for gcc gcc
checking whether the C compiler (gcc ) works yes

checking for readline in -lreadline yes
checking for readline/readline.h yes
Using the readline library.
updating cache ./config.cache
creating ./config.status
creating Makefile
creating bc/Makefile
creating dc/Makefile
creating doc/Makefile

creating lib/Makefile
creating config.h
The lines beginning with checking indicate that configure is testing for the
presence of a certain feature such as gcc. Because the command line specified
with-readline, the last two checking lines make sure the readline library
is installed (checking for readline in -lreadline yes) and that the
appropriate header file, readline.h, is installed. Once all of the tests are
completed, configure uses the test results to create a number of Makefiles
and a header file.
TIP If you are in the habit of building software as the root user, stop! It is
extremely rare to require root access to build software. The only step that
needs root access is the make install step, which requires write permissions to
the installation directories. We routinely build the kernel and major system
applications as mortal users, only using su when we are ready to install.
At this point, you are ready to build bc.
Building the Software Package
To build bc, type make and press Enter. The following example shows the end
of the build process’s output:
$ make

gcc -DHAVE_CONFIG_H -I. -I. -I -I./ -I./ /h -g -O2 -Wall
-funsigned-char -c dc.c
gcc -DHAVE_CONFIG_H -I. -I. -I -I./ -I./ /h -g -O2 -Wall
-funsigned-char -c misc.c
gcc -DHAVE_CONFIG_H -I. -I. -I -I./ -I./ /h -g -O2 -Wall
-funsigned-char -c eval.c
Installing and Upgrading Software Packages 775
38_599496 ch30.qxd 8/30/05 7:36 PM Page 775
gcc -DHAVE_CONFIG_H -I. -I. -I -I./ -I./ /h -g -O2 -Wall
-funsigned-char -c stack.c

gcc -DHAVE_CONFIG_H -I. -I. -I -I./ -I./ /h -g -O2 -Wall
-funsigned-char -c array.c
gcc -DHAVE_CONFIG_H -I. -I. -I -I./ -I./ /h -g -O2 -Wall
-funsigned-char -c numeric.c
gcc -DHAVE_CONFIG_H -I. -I. -I -I./ -I./ /h -g -O2 -Wall
-funsigned-char -c string.c
gcc -g -O2 -Wall -funsigned-char -o dc dc.o misc.o eval.o sta
ck.o array.o numeric.o string.o /lib/libbc.a
make[2]: Leaving directory `/tmp/bc-1.06/dc’
Making all in doc
make[2]: Entering directory `/tmp/bc-1.06/doc’
make[2]: Nothing to be done for `all’.
make[2]: Leaving directory `/tmp/bc-1.06/doc’
make[2]: Entering directory `/tmp/bc-1.06’
make[2]: Leaving directory `/tmp/bc-1.06’
make[1]: Leaving directory `/tmp/bc-1.06’
Depending on the size and complexity of the program you are building,
make’s output might be extensive. In the example shown, you see the final
compiler invocations and, most importantly, no errors. Accordingly, the next
step is to test the build.
Testing the Build
Many programs, especially those from the GNU projects, include some sort of
test suite to validate the program. The idea is to make sure that the program
works properly before installing it. In some cases, you execute the make test
command to run the test suite. In other cases, as with bc, a special subdirec-
tory of the build tree, conveniently named test or Test, contains the test
suite. Each package handles testing slightly differently, so read the package
documentation. In the case of bc, the test suite lives in a subdirectory named
Test, and a shell script named timetest performs the actual test. In this
case, timetest evaluates how long it takes bc to perform certain mathemat-

ical calculations, but it also serves to ensure that bc built properly. The follow-
ing commands invoke bc’s test suite:
$ cd Test
$ ./timetest
timetest takes at least 10 minutes to run, so have a cup of coffee or your
favorite beverage while the test runs. If no errors occur during the test, you are
ready to install it.
776 Chapter 30
38_599496 ch30.qxd 8/30/05 7:36 PM Page 776
Installing the Software
In the case of bc, as with many, many other programs installed from source,
installing the built and tested program is simply a matter of executing the
command make install in the build tree’s base directory (/tmp/bc-1.0.6,
in this case). Programs that are more complex might have additional com-
mands, such as make install-docs to install only documentation, that
break up the installation into more steps or that perform only part of the instal-
lation. Still other packages might use scripts to perform the installation.
Regardless of the process, however, the goal is the same: Install program exe-
cutables and documentation in the proper directories, create any needed sub-
directories, and set the appropriate file ownership and permissions on the
installed files.
In the case of the bc package, the installation command is a simple make
install, as shown in the following code:
$ make install

/bin/sh /mkinstalldirs /tmp/bctest/bin
mkdir /tmp/bctest
mkdir /tmp/bctest/bin
/usr/bin/install -c bc /tmp/bctest/bin/bc

make install-man1
make[3]: Entering directory `/tmp/bc-1.06/doc’
/bin/sh /mkinstalldirs /tmp/bctest/man/man1
mkdir /tmp/bctest/man
mkdir /tmp/bctest/man/man1
/usr/bin/install -c -m 644 ./bc.1 /tmp/bctest/man/man1/bc.1
/usr/bin/install -c -m 644 ./dc.1 /tmp/bctest/man/man1/dc.1

The output, edited to conserve space, shows the creation of the installation
directory, /tmp/bctest (recall the prefix=/tmp/bctest command line
option passed to configure), a subdirectory for the binary (/tmp/bctest/bin)
and the subdirectory for the manual pages, /tmp/bctest/man/man1. The
output also shows the invocation of the install program that actually per-
forms the installation. The -c option is ignored because it is used for compati-
bility with install programs used on proprietary UNIX systems. The -m option
sets the file permissions using the octal permission notation. So, -m 644 makes
the files bc.1 and dc.1 (which are manual pages) read/write for the file owner
and read-only for the file group and all other users.
Installing and Upgrading Software Packages 777
38_599496 ch30.qxd 8/30/05 7:36 PM Page 777
NOTE For more information about the install program, read the manual
page (man install) or the TeX-info page (info install).
At this point, package installation is complete. Although this example of
building and installing a package from a source tarball is simple, the basic pro-
cedure is the same for all packages: unpack the source archive, configure it as
necessary, build it, test the program, and then install it. One final exhortation
before proceeding to the next section: Read the documentation! Most software
you obtain in source code form includes one or more files explaining how to
build and install the software; we strongly encourage you to read these files to
make sure that your system meets all the prerequisites, such as having the

proper library versions or other software components. The documentation is
there to help you, so take advantage of it and save yourself some frustration-
induced hair loss!
Summary
This chapter covered a lot of territory. You learned how to use each of RPM’s
major operating modes, including querying the RPM database; installing,
upgrading, and removing RPMs; and maintaining the RPM database. You also
learned methods for obtaining the version information of installed software.
The chapter listed some popular software repositories and how to use them.
Finally, you learned how to build and install software from source using both
the traditional tools (tar, gcc, make, install) and RPM’s higher-level inter-
face to these tools.
778 Chapter 30
38_599496 ch30.qxd 8/30/05 7:36 PM Page 778
779
Backing Up and Restoring
the File System
IN THIS CHAPTER
■■ Creating a Backup Plan
■■ Choosing Media for Backups
■■ Understanding Backup Methods
■■ Tape Rotation
■■ Using Backup Tools
In this chapter, you learn how to make backups of your files and restore dam-
aged file systems from backups. It is important to make backups of the file sys-
tem to avoid the loss of important information in the case of catastrophic
hardware or software failure. An efficient backup and restoration process can
minimize downtime and prevent the need to recreate lost work. In this chap-
ter, you learn how to choose a backup medium and how to use backup tools.
Red Hat Enterprise Linux provides several packages for dealing with the

backup and restoration of the file system. The tar and dump commands pro-
vide low-level interfaces to system backups. In addition, sophisticated backup
tools, such as AMANDA, can do automatic backups of multiple machines.
Creating a Backup Plan
Determining what to back up on a particular machine depends largely on
what data the machine contains and how the machine is used. However, there
are some general guidelines that can be useful in determining what to back up.
Generally, temporary and cached files need not be backed up. The contents
of the /tmp directory, for instance, are usually deleted when the machine is
CHAPTER
31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 779
rebooted. Therefore, it is all right to not back up these files. Also, the cache
directory used by Mozilla and found in users’ .mozilla directory is auto-
matically regenerated by Mozilla if it is deleted. You may find it worthwhile to
investigate whether any other packages installed on the machine generate sig-
nificant amounts of ignorable temporary data.
Depending on the situation, it may or may not be advisable to back up the
machine’s system files. If the machine is a standard installation of Red Hat
Enterprise Linux without any customizations or extra packages installed, the
system files can be restored by reinstalling Red Hat Linux. The tradeoff is that
reinstalling and reconfiguring a system probably takes more time and atten-
tion than restoring the file system from backup. However, this tradeoff may be
worthwhile because of the amount of backup media that can be saved. In the
particular case that a single Red Hat installation is copied verbatim onto many
machines, it may be appropriate to back up the system files of just one of the
machines. If the system files are identical across machines, a single backup
should restore all of them. In any case it is probably wise to back up at least the
/etc directory of each machine. Probably the machines have at least some dif-
fering configuration information, such as network and hostname settings.

One other thing needs to be backed up and indeed needs to be backed up
via a special method: database files. Doing a straight tar from database files
won’t save you from a database crash, because the database files will all be
in different states, having been written to backup when opened. Oracle,
Informix, Sybase, and so forth all allow the administrator to export the table
data in text or other delimited file as well as put the database tablespaces in
backup mode. In backup mode, the data to be written goes to a memory cache
rather than the file, and transaction logs are updated only when the cache is
flushed. This procedure slows things down but makes certain that the data-
base will survive a crash.
The other aspect of the file system, other than the system files that need to
be backed up, is the user files. Generally, all user files are stored in subdirecto-
ries of the /home directory. You should find it easy, therefore, to back up all
user files at one time. Even when the entire file system — both system and user
files — is being backed up, you should still back them up separately. System
and user files can have different relative priority depending on the situation.
The user files are important because they may be irreplaceable, whereas many
of the system files generally can be replaced by reinstalling Red Hat Linux. On
the other hand, restoration of the system files is necessary for the machine to
function and provide services, whereas the machine can be totally functional
without restoration of the user files. Such priority considerations must be
made when designing a backup strategy.
Give special thought to resources that do not easily fall into the system and
user categories. Information stored in SQL databases, for instance, is often
780 Chapter 31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 780
technically owned by root or by a special system user, but also often contains
irreplaceable content entered by users. This kind of data can often be the most
important to back up. You may find it beneficial to investigate which of the
installed packages use this kind of data. Other examples besides databases are

Web servers and mailing list archivers.
Choosing Media for Backups
A variety of backup media are available on the market today. Which backup
media you use depends on a number of factors and the particular needs of the
situation. You should consider how often files are backed up, how long the
backups need to last, how redundant the backups need to be, and how much
money can be allocated to purchasing backup media. Table 31-1 provides a
comparison of backup media.
Table 31-1 Comparison of Backup Media
MEDIUM CAPACITY RELIABILITY COST SPEED
Magnetic tape High High Cheap Slow
Writable CDs Medium Medium Cheap Fast
Hard drive High High Expensive Fast
Floppy disks Low Low Cheap Slow
DVD High High Medium Slow
Zip disks Medium Low Medium Slow
Flash ROM Medium High Expensive Fast
Removable hard High High Expensive Fast
drive (FireWire)
Removable hard High High Expensive Medium
drive (USB)
Understanding Backup Methods
To save time and money in creating backups and restoring corrupted file sys-
tems and in purchasing backup media, it is important to institute a methodology
for creating scheduled backups. The number of different backup methodologies
is unlimited. How you should perform backups depends on the particular needs
Backing Up and Restoring the File System 781
39_599496 ch31.qxd 8/30/05 7:13 PM Page 781
of your institution and computing infrastructure. The scheduling and type of
backups depends on the type of backup media being used, the importance of the

data, and the amount of downtime you can tolerate.
The simplest backup methodology is creating a full backup. A full backup
copies the entire file system to the backup medium. This methodology can be
good for small systems in which there is not much data to back up or systems
in which the data is very important, where it is changing rapidly, and where
historical snapshots of the system at different points in time are useful.
Performing frequent full backups has several disadvantages. Full backups
take a long time to perform if there is a lot of data to back up or if the backup
medium is slow. To get a clear snapshot of the system, you may need to sus-
pend the execution of processes that modify the file system while the backup
process takes place. If backups take a long time, the downtime might be pro-
hibitive. Full backups have no disadvantages when it comes to restoring an
entire file system from backup. However, there is a disadvantage when restor-
ing a partial file system from backup. If a sequential medium, such as mag-
netic tape, is used, it must be searched sequentially to find the files that need
to be restored. This process can cause a partial restoration to take as long as a
full file system restoration in the worst case. Full backups also take signifi-
cantly more space to archive than incremental backups. This situation is not
too much of a disadvantage if you reuse the same backup media; you can just
overwrite the old backup with the new one. However, it is often advisable to
keep multiple generations of backups. Sometimes problems with the file sys-
tem, such as corrupted or erased files, are not detected or reported immedi-
ately. If the file system is backed up once a day on the same backup tapes and
an accidentally erased file is not found for two days, it cannot be recovered. On
the other hand, if the file system is backed up once a week, any files lost
between backups cannot be recovered. Keeping multiple full backups also has
a disadvantage. If a full backup is made every day, the amount of archive
media necessary to store it quickly becomes prohibitive.
The alternative to doing full backups is to do incremental backups. An incre-
mental backup archives only the files that have changed or been added since

the last backup. Incremental backups solve all of the disadvantages of full
backups. Incremental backups are fast. In fact, the more often you do them, the
faster they are because there is less to back up. Since the backups are smaller,
searching from a given backup for a particular file is faster, thus making par-
tial restorations faster if you need to restore from a particular known incre-
mental backup archive. Because less is backed up each time, less media is
used, so either less backup media needs to be bought or a longer history can be
kept in the same amount of backup media. In the latter case, backups are more
robust against lost or damaged files that are not discovered for a while.
782 Chapter 31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 782
Using incremental backups has disadvantages as well. While incremental
backups are faster for retrieving individual files, they are slower for restoring
entire file systems. To explain this problem, imagine that you have a week-
long backup cycle. On the first day of the week, you make a full backup. The
rest of the week, you make an incremental backup. If a file system is erased
accidentally on the last day of the week (right before a new full backup is to be
made), you have to start at the last full backup and then load in a whole week
of tapes to entirely restore the file system. If you made a full backup every day,
you would have to load only the full backup, then you would be done restor-
ing the file system.
When to use full backups and when to use incremental backups depends on
the particular data stored on the machines, the way the machines are used, and
how much money can be allocated to buying backup media. After you have
decided on a backup methodology, you must configure your tools to use this
methodology. Full and incremental backups can be implemented in scripts on
top of the primitive backup tools such as tar. More advanced tools such as
dump and AMANDA have built-in support for backup levels and scheduling
of various kinds of backups. AMANDA even has a complex configuration lan-
guage that lets you specify all kinds of details about the various types of back-

ups you might want to do, the length of your backup cycle, and what files
should be excluded from backup (such as private or temporary files).
Another thing to consider is the criticality of the system. If the system must
be up at all times and downtime is a critical situation, then full backups are
necessary to minimize downtime. One strategy for backing up critical
machines is to create a separate volume group on mirrored disks solely for
backups and use it as an intermediate area to copy files to prior to writing
them to tape. A compressed tar file can be created on disk and then be writ-
ten to tape faster than a normal tar file can. Also, since a backup exists on
disk, the tape archive is only used as a last resort if the disk archive fails. This
strategy is similar to the one that the AMANDAautomated backup utility uses
to take into account faulty backup devices or media. Even if the tape drive
fails, the backup on disk can be written to tape when the problem has been
solved.
Tape Rotation
Another consideration after you select a backup method is a proper tape rota-
tion schedule. A well-thought-out schedule can lower your media costs and
increase the life of your tapes, while ensuring that every file is protected. Sev-
eral popular tape rotation methods are currently in use.
Backing Up and Restoring the File System 783
39_599496 ch31.qxd 8/30/05 7:13 PM Page 783
Grandfather-father-son (GFS) is probably the most common tape rotation
scheme. The grandfather backup is a monthly full backup, the father is a
weekly full backup, and the son is a daily incremental backup. It is usually a
good idea, and more secure, to store at least the full monthly backups off-site.
In the event of a catastrophe at your location, a fire that damaged or destroyed
your on-site backups, for example, you would be able to restore your data
from tapes stored off-site.
TIP For a detailed explanation of tape rotation methods, a good place to
look is the Seagate Web site: seagate.com/products/tapesales/backup

/A2g1.html.
Using Backup Tools
Fedora Core and Red Hat Enterprise Linux provide numerous tools for doing
file system backups. There are tools for interacting with backup media, such as
ftape for manipulating tapes drives and cdrecord for writing to CD drives.
Command line tools such as tar and dump allow for low-level control of file
system backups and also easy automation through scripting. Using only shell
scripts and periodic scheduling through cron jobs, you can develop a robust
automated backup solution for many situations. Graphical tools also exist to cre-
ate a more user-friendly interface for performing manual backups. Advanced
backup tools that can be configured to fully automate the process of backing up
multiple machines do exist.
Command Line Tools
Fedora Core and Red Hat Enterprise Linux provide a number of command
line tools for performing backups and restoring from backups. The tools for
interacting directly with backup media are mt-st and cdrecord. The stan-
dard tools for creating archives are tar and dump for tape archives and
mkisofs for CD archives. Each command provides a different interface and a
number of options.
Using mt-st
The mt-st package is a collection of command line tools for accessing and man-
aging magnetic tape drives (the mt part of the package) and also includes the
module that is used to control the SCSI tape drive (the st part of the package),
or an IDE drive in SCSI emulation mode. This package is installed by default
784 Chapter 31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 784
on Fedora Core and Enterprise Linux and is intended to control tape drives
connected to a SCSI bus. You can check to be sure the package is installed by
entering the following at a command line interface.
rpm -q mt-st

The command will return mt-st <version number> if the package is
installed and nothing if the package is not installed. In the event that the pack-
age is not installed, find it on the installation CDs and install it using the fol-
lowing command:
rpm -Uvh mt-st<version number>(Be sure to use the proper version number)
To be able to communicate with your tape drive, the st module must be
loaded. You can determine whether the st module is loaded by entering the
following command:
/sbin/modinfo st
If the module is installed you will see output similar to this:
filename: /lib/modules/2.6.10-1.770_FC3/kernel/drivers/scsi/st.ko
author: Kai Makisara
description: SCSI Tape Driver
license: GPL
parm: buffer_kbs:Default driver buffer size for fixed block mode (KB;
32)
parm: max_sg_segs:Maximum number of scatter/gather segments to use
(256)
parm: try_direct_io:Try direct I/O between user buffer and tape drive
(1)
parm: try_rdio:Try direct read i/o when possible
parm: try_wdio:Try direct write i/o when possible
vermagic: 2.6.10-1.770_FC3 686 REGPARM 4KSTACKS gcc-3.4
depends: scsi_mod
srcversion: 0ECB594BCDEAA75405B3302
If the module is not installed, you will see a module not found message. You
can install the module using the following command:
insmod st
After you install the module, you should reboot the server so the st module
can identify and connect the tape nodes, which are /dev/st#. When the sys-

tem finishes booting, you can use the dmesg command to get a listing of the
tape device. Look for information similar to the following:
Backing Up and Restoring the File System 785
39_599496 ch31.qxd 8/30/05 7:13 PM Page 785
(scsi0:A:6): 10.000MB/s transfers (10.000MHz, offset 15)
Vendor: COMPAQ Model: DLT4000 Rev: D887
Type: Sequential-Access ANSI SCSI revision: 02
st: Version 20040403, fixed bufsize 32768, s/g segs 256
Attached scsi tape st0 at scsi0, channel 0, id 6, lun 0
st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 1048575
From this output, you can see the SCSI tape drive is identified as st0. To
communicate with this drive you would use /dev/st0. There are actually
eight device nodes associated with the tape device. Four of the nodes indicate
autorewind nodes and four indicate no rewind nodes. The autorewind nodes
are indicated by st0*, and the nonrewind nodes are indicated by nst0*. You
can see a listing of these different nodes by running the ls -ld command for
the devices. For example, to see the autorewind nodes do this:
ls /dev/st0*
You will see this output:
/dev/st0 /dev/st0a /dev/st01 /dev/st0m
To see the no rewind nodes, enter ls /dev/nst0*, and you will see the
following:
/dev/nst0 /dev/nst0a /dev/nst01 /dev/nst0m
When you are communicating with the tape device, you use /dev/st0*
when you want to rewind the tape and /dev/nst0* when you do not want to
rewind the tape. You will see some examples later in the section on the mt and
tar commands.
The mt command is used to perform many tape control functions, such as
scanning, rewinding, and ejecting magnetic tapes. Take a look at some examples.
You must be root to access the tape drives. As root, you can test a new mag-

netic tape by inserting it into the tape drive and using the following command:
mt -f /dev/st0 status
This command will return output similar to the following:
drive type = Generic SCSI-2 tape
drive status = 318767104
sense key error = 0
residue count = 0
file number = 0
block number = 0
Tape block size 0 bytes. Density code 0x13 (DDS (61000 bpi)).
Soft error count since last status=0
786 Chapter 31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 786
General status bits on (45010000):
BOT WR_PROT ONLINE IM_REP_EN
In addition to giving you status information about the tape, it will rewind it
to the beginning. If you run the same command but use /dev/nst0 instead,
you would receive the status information, but the tape does not rewind. There
are many options available to you with the mt command. The best source of
information is the mt manual page, which you can access by typing man mt at
a command line.
Using the cdrecord Package
To make backups on CDs under Red Hat Enterprise Linux, you need the
cdrecord package installed. It contains several commands such as cdrecord,
devdump, isodump, isoinfo, isovfy, and readcd. These commands are
useful utilities for creating and managing writable CDs.
The disadvantage to making backups on CD is that you must first create a
CD image on the file system and then copy the CD image to the actual CD all
in one step. This process requires that you have empty space on a single file
system partition that is large enough to hold a CD image (up to 650 MB). You

create a CD image with the mkisofs command:
mkisofs -o /tmp/cd.image /home/terry
NOTE You can also use mkisofs to send content to stdout and then feed
directly into cdrecord. Using this method does run the risk of the output being
larger than the CD capacity and possibly buffer underruns on slow systems that
don’t use burnproof or a similar technology. A good idea is to run the du -s
command for each directory you want to back up to determine if it will fit on
a CD/DVD.
This command makes a CD image file in the /tmp directory called
cd.image. The CD image file contains all the files in the /home/terry direc-
tory. You must have enough space to make the image file on the partition hold-
ing the /tmp directory. You can determine how much is free with the df
command. You can determine how much space the image file is going to take
up with the du /home/terry command. By default, mkisofs preserves the
ownership and permissions from the file system in the CD image.
To burn the image file to an actual CD, you must determine which device
has the CD drive and its device number, logical unit number, and device ID.
You can find this information with the following command:
cdrecord -scanbus
Backing Up and Restoring the File System 787
39_599496 ch31.qxd 8/30/05 7:13 PM Page 787
The output of the cdrecord command follows. The line that shows the CD
drive type and manufacturer is the one you are interested in. At the beginning
of the line is the SCSI ID information shown as 1,0,0, which is the SCSI device
number (1), the logical unit number (0), and the device ID (0).
cdrecord-Clone 2.01-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg
Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to

/>Note: The author of cdrecord should not be bothered with problems in this
version.
scsidev: ‘ATA’
devname: ‘ATA’
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Using libscg version ‘schily-0.8’.
cdrecord: Warning: using inofficial libscg transport code version (schily - Red
Hat-scsi-linux-sg.c-1.83-RH ‘@(#)scsi-linux-sg.c 1.83 04/05/20 Copyright
1997 J. Schilling’).
scsibus1:
1,0,0 100) ‘HL-DT-ST’ ‘RW/DVD GCC-4243N’ ‘1.07’ Removable CD-ROM
1,1,0 101) *
1,2,0 102) *
1,3,0 103) *
1,4,0 104) *
1,5,0 105) *
1,6,0 106) *
1,7,0 107) *
You supply the SCSI device number, the device ID, and the logical unit num-
ber to the cdrecord command, in that order, as part of the dev option. A sam-
ple cdrecord command is as follows:
cdrecord -v dev=1,0,0 -data /tmp/cd.image
This command does not generally produce a bootable CD. For a CD to be
bootable, the image file being recorded onto the CD needs to follow a specific
format. Also, your BIOS must support booting from your particular CD-ROM.
To produce a bootable image file, you need to follow several steps. First, you
need to obtain a boot image. If you have a bootable CD-ROM in the disk drive,
the boot image can be written to a file with the following command:
dd if=/dev/fd0 of=boot.img bs=10k count=144

TIP One handy boot image is the diskboot.img, which is on disk one of the
Fedora Core and Red Hat Enterprise installation disks.
788 Chapter 31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 788
This command puts the boot image in the file boot.img. You must put this
somewhere in the directory that you are going to put on the CD. In the exam-
ple provided, you could create a directory /home/terry/boot and place the
file there. You also need to give mkisofs some extra parameters to have it cre-
ate a bootable image.
mkisofs -r -b /home/terry/boot/boot.img -c
/home/terry/boot/boot.catalog -o /tmp/cd.image /home/terry
The boot.catalog file need not already exist. It is generated by mkisofs.
The command line option just tells mkisofs where in the image to store the
generated file.
Using dump
The dump package consists of several commands for backing up and restoring
the file system. The dump command is used to do backups of either entire par-
titions or individual directories of ext2 and ext3 file systems. The restore
command is used to restore an entire partition, individual directories, or indi-
vidual files.
Syntax of the dump Command
The first argument to the dump command is a list of options. Following that are
all arguments required by the various options in the same order as the options
were specified. The last argument is the file system to back up. Table 31-2 lists
the available dump options.
Table 31-2 Dump Options
OPTION MEANING TYPE
B The number of records per volume Number
b The number of kilobytes per dump record Number
h The dump level at which to use nodump flags Number

f Name of file or device to write to Filename
d Tape density Number
n Tell dump to send a message when done None
s Length of dump tape Number in feet
u Record the date of this dump in /etc/dumpdates None
T Add only files older than the given time Time (ctime)
(continued)
Backing Up and Restoring the File System 789
39_599496 ch31.qxd 8/30/05 7:13 PM Page 789
Table 31-2 (continued)
OPTION MEANING TYPE
W List the file systems that need to be backed up None
w List individual files that need to be backed up None
0–9 Specify a dump level of 0 through 9 None
CAUTION Using dump on a live file system can be dangerous and unreliable.
For more information on this topic, see redhat.com/archives/ext3-users
/2003-January/msg00034.html.
Sample dump Command
If you want to see a sample of the output from the dump command, try enter-
ing the command shown here:
dump 0uf /dev/nst0 /dev/hda3
This command specifies that the file system on /dev/hda3should be backed
up on the magnetic tape on device /dev/nst0. It specifies that the backup
should use backup level 0 (full backup) and write the time of the backup to the
/etc/dumpdates file. The /etc/dumpdates file is used to keep track of the
dates when your information was backed up.
Using restore
The restore command is used to retrieve files from the backups created with
dump. You can use restore to restore an entire file system or you can use it
to interactively select which files you want to restore.

The syntax for the restore command is the same as that for the dump com-
mand, although it has different options. Table 31-3 lists the options.
Table 31-3 Restore Options
OPTION MEANING TYPE
r Restores the entire dump archive None
C Compares the files on the file system to those None
in the dump archive
R Starts the restore from a particular tape in a None
multivolume sequence
790 Chapter 31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 790
Table 31-3 (continued)
OPTION MEANING TYPE
x Extracts only specified files List of files
t Lists the contents of the dump archive List of files
I Restores files in interactive mode None
b Blocks size of the dump in kilobytes Number
D Names the file system to be compared against File system
f Names dump archive to restore from Filename
h Recreates directories but does not restore None
their contents
m Extracts files by inode number instead of name None
N Prints filenames rather than extracting them None
s Specifies the tape number to start on when Number
using the R option
T Specifies where to write temporary files Directory
v Specifies verbose mode None
y Does not prompt when bad blocks are encountered None
Restoring the File System
To restore a damaged or erased file system, you must first recreate the direc-

tory or partition that has been lost. If, for instance, you want to recreate the
/home directory, which existed by itself on the /dev/hdb1 partition, you
could use the following commands:
mkfs /dev/hdb1
mount /dev/hdb1 /home
Note that this command erases all of the data on the /dev/hdb1 partition.
This method of restoration is useful only for restoring all of the files previously
archived with dump. If any files have been added, modified, or deleted since
the last backup, those changes are lost. Restoring individual files is covered in
the section “Using Restore Interactively.” Also, if mkfs is accidentally run on a
different partition than the one meant to be restored, all of the data on the par-
tition on which it is mistakenly run is irrevocably erased.
The restore command must be run inside the directory that is going to be
restored. So, restore can restore the /home directory with the following
commands:
Backing Up and Restoring the File System 791
39_599496 ch31.qxd 8/30/05 7:13 PM Page 791
cd /home
restore rf /dev/nst0
The r flag tells restore to restore the entire archive rather than just some
files. The f flag tells restore that the archive is located on the device
/dev/rft0.
Using restore Interactively
The restore command, in addition to being used to restore an entire file sys-
tem, can also be used in an interactive mode, which enables you to restore
individual files. The interactive mode is invoked as follows:
restore if /dev/nst0
This command runs restore in interactive mode and specifies that it
should restore from the archive on the device /dev/rft0. The interactive
mode enables you to type options to restore and lets you control restore’s

behavior. It includes the options shown in Table 31-4.
Table 31-4 Restore Commands
COMMAND MEANING
add Adds a file or directory to the list of files to be extracted. If a
directory is specified, all contained files, subdirectories, and files
contained in subdirectories are extracted. File paths are relative
to the current directory being viewed in the dump archive.
cd Changes which directory within the dump archive is being
viewed.
delete Removes a file or directory from the list of files to be extracted.
If a directory is specified, all files in that directory, subdirectories,
and files in subdirectories are removed from the list as well.
Note that this does not affect what is stored in the dump
archive, but rather which files are extracted during the restore.
extract Extracts all files and directories currently in the list of files to
extract and restores them in the file system.
help Lists available commands.
ls Lists the contents of the directory currently being viewed in the
dump archive. If a directory is specified, the contents of the
specified directory are listed rather than the contents of the
current directory. Files and directories marked with * in the file
listing are currently marked for extraction.
pwd Prints the path within the dump archive of the directory
currently being viewed.
792 Chapter 31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 792
Table 31-4 (continued)
COMMAND MEANING
quit Exits the restore program. No other actions are taken by restore.
setmodes Rather than extracting the files, this sets the permissions on the

files in the file system so that they match the permissions of the
files in the dump archive that are marked for extraction.
verbose Switches verbose mode on or off.
Using tar
Fedora Core and Red Hat Enterprise Linux include the GNU version of tar. It
includes some extensions to the older standard versions of tar, including multi-
volume archiving, an automated process in which tar prompts for new media to
be inserted whenever it runs out of space. The tar program is a utility originally
designed for making magnetic tape backups, but is useful for any kind of
archiving purpose. When making archives, it is important to specify a leading
./ for files. That creates a relative path, which will be necessary when restoring
the files later.
The tar command requires one command option followed by any number
of optional options. Table 31-5 lists the command options.
Table 31-5 tar Options
COMMAND EXPLANATION
A Appends the contents of the given tar files to the specified tar
archive.
d Finds differences between what’s in the tar archive and what’s in
the file system.
j Filters the archive through the bzip filter. Used to compress or
decompress files ending with bz2 extension.
r Appends the given files to the specified tar archive.
t Lists the contents of the specified tar archive.
u Appends the given files to the specified tar archive, but only if
they are newer than the files in the tar archive.
x Extracts the given files from the specified tar archive.
z Filters the archive through the gzip filter. Used to compress or
decompress files ending with gz extension.
Backing Up and Restoring the File System 793

39_599496 ch31.qxd 8/30/05 7:13 PM Page 793
In addition to specifying a command, you must specify a device or file to act
as the destination of the tar archive.
Creating a tar Archive
The tar command was originally designed to create tape archives; in fact tar
is a contraction of tape archive. But, you can create tar archives and save them
anywhere on your system, not just to a tape drive. To create a tar file use the
following command syntax.
tar cvf (name of tar file to create) (list of files to add)
If you wanted to create a tar file of the files testing1.txt, test-
ing2.txt, and testing3.txt and place them into a tar archive called
testing.tar, you would issue this command:
tar cvf testing.tar testing1.txt testing2.txt testing3.txt
In this example, you could use wildcards to make your job easier by using
testing*.txt instead of typing the filenames individually.
You can also use tar to back up entire directories by issuing the directory
name you want to tar instead of filenames. For example, if you wanted to tar
a directory called ch4 to the tape drive, you would issue this command:
tar cvf /dev/st0 ch4
This command would create a tar file called ch4.tar that would contain
the contents of ch4, including all files as well as any subdirectories and rewind
the tape to the beginning.
Extracting a Tar Archive
To extract a tar archive, use the following syntax:
tar x (name of tar file)
To extract the tar file created in the previous section, issue this command:
tar x testing.tar
This would extract the files from the tar file and place them in the current
directory. If you extract a tar file containing a directory and subdirectories, if
any, the directory and its subdirectories will be extracted into their original

directory structure at the location from where the tar command was issued.
For example, to extract the sample directory you created previously, you
would type the following:
tar xvf /dev/st0
794 Chapter 31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 794
This command would extract the sample directory, and any files or subdi-
rectories it contained, from the tape and place it at the location from where the
tar command was run.
Advanced Tools
This section discusses a number of advanced backup tools, including
AMANDA, the amdump test, and pax.
Using AMANDA
The Advanced Maryland Automatic Network Disk Archiver (AMANDA)
package is a set of tools for doing backups of multiple machines over the net-
work. Using AMANDA, you can configure your Red Hat Linux machine to be
a centralized backup server for the other machines in the network, including
Windows systems. AMANDA is included with Fedora Core and Red Hat
Enterprise Linux. To use AMANDA, install the following packages:
■■ amanda
■■ amanda-client
■■ amanda-server
■■ Gnuplot
You need to install the amanda-server and gnuplot packages only on the
machine that is going to be the backup server. However, you must install
amanda-client on any machine that you want to back up using AMANDA. You
must install the base amanda package on both the client and server machines.
The amanda package contains several commands, shown in Table 31-6.
Table 31-6 AMANDA Commands
COMMAND USE

amdump Normally executed periodically by a cron job, this utility is run
on the AMANDA server. It requests backups from the various
AMANDA clients.
amflush If amdump has trouble writing backups to tape, they are kept in
temporary storage space on disk until the problem is
corrected. After the problem is fixed, this command is run to
write the data in the temporary storage space to the tapes.
amcleanup If the AMANDA server crashes during the running of amdump,
this utility should be run to clean up after the interrupted
amdump.
(continued)
Backing Up and Restoring the File System 795
39_599496 ch31.qxd 8/30/05 7:13 PM Page 795
Table 31-6 (continued)
COMMAND USE
amrecover This utility provides a way to select which tapes should be
used to recover files.
amrestore This utility is used to restore individual files or directories or
entire partitions from AMANDA backups.
amlabel This utility is used to write an AMANDA label onto a tape. You
must use this command to label tapes before they can be
written to with amdump.
amcheck This utility should be run before amdump to verify that the
correct tape is in the drive.
amadmin This utility does various administrative tasks.
amtape This utility is used for low-level tape control, such as loading
and ejecting disks.
amverify This utility checks AMANDA tapes for errors.
amrmtape This utility deletes a tape with a particular label from the
AMANDA tape database.

amstatus This utility reports on the current status of a running amdump
program.
Installing AMANDA
After installing the necessary RPMs, some additional installation is required to
get AMANDA running. You must create subdirectories in the /etc/amanda
and /usr/admn/amanda directories for each backup schedule you are going
to run. For instance, if you plan to run a backup schedule called test, you
must execute the following commands:
mkdir -p /etc/amanda/test
mkdir -p /usr/admn/amanda/normal
You also need to create some temporary space for AMANDA to keep files,
which it is in the process of backing up. So if, for instance, you want to create
this space as a directory on your root partition, you can use the following com-
mand to make an amanda directory:
mkdir /amanda
796 Chapter 31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 796
Configuring AMANDA
To configure AMANDA, you must make changes to the amanda.conf file
and put it in the subdirectory in /etc/amanda that you created. A sample
amanda.conf file is created during AMANDAinstallation. So in the example,
for instance, it would be called /etc/amanda/test/amanda.conf. The
amanda.conf file has many options, shown in Table 31-7, but has defaults for
most of them.
Table 31-7 amanda.conf Options
OPTION EXAMPLE MEANING
org “name” org This option specifies the name
“Tristero” used in reports generated by AMANDA.
mailto mailto “root This option specifies account names that
“accounts” example” Amanda should put in charge of the

backup process.
dumpuser dumpuser This option specifies the user account that
“account” “Amanda” the AMANDA dump process should run as.
inparallel inparallel 5 This entry specifies the number of amdump
number processes that can run simultaneously.
netusage netusage This entry indicates the bandwidth that
num unit 1000 Kpbs AMANDA is allowed to consume while
doing backups. It should be set such that
even if all of the allocated bandwidth is
consumed there is still enough bandwidth
for other tasks that might operate at the
same time as the AMANDA backup process.
dumpcycle dumpcycle This option specifies the length of the
num unit 1 week backup cycle.
runspercycle runspercycle 7 This option specifies the number of
num backups that should be done during a
single dump cycle. So, with a dump cycle
of 1 week and seven runs per cycle,
AMANDA makes one full backup and six
incremental backups every week.
tapespercycle tapespercycle This option specifies how many tapes are
num unit 7 tapes available for use in a single backup cycle.
runtapes num runtapes 1 This option specifies how many tapes are
available for use in each backup.
tapedev tapedev This option specifies the device name of
“device” “/dev/rft0” the tape device.
Backing Up and Restoring the File System 797
39_599496 ch31.qxd 8/30/05 7:13 PM Page 797
The amanda.conf file also has some complex options, which consist of
blocks with multiple subfields. The holdingdisk block defines a temporary

storage space for holding data that is being backed up. You can define multi-
ple holdingdisk blocks in a single file. The definition has the following format:
Holdingdisk name
{
directory “name”
use num unit
}
Example holdingdisk block:
Holdingdisk example
{
directory “/example”
use 4 Gb
}
The tapetype block defines a particular kind of magnetic tape that might be
used in backups. It defines properties about the tape such as length and speed.
The tapetype definition has the following format:
Define tapetype name
{
comment “freeform string”
length num unit
filemark num unit
speed num unit
}
Example tapetype definition:
Define tapetype EXAMPLE
{
comment “These are fictional numbers.”
Length 5000 mbytes
Filemark 100 kbytes
Speed 500 kbytes

}
The interface block defines a particular network interface that can be used
for communication between an Amanda server and client. The interface defi-
nition specifies how much bandwidth can be used on that particular network
interface. The syntax of the definition is as follows:
798 Chapter 31
39_599496 ch31.qxd 8/30/05 7:13 PM Page 798