Cover V11, I04

Figure 1


Integrating Backup for a Multiple Operating System Network with Amanda

Edward L. Haletky

If you have a network of disparate operating systems, and a single tape drive, how do you back up your important data? The sample network discussed in this article consists of Apple Macintosh, Linux, Windows 2000, and various flavors of Linux and UNIX. Also, due to disk space limitations, there cannot be a single file server, and there is operating system-specific configuration data that cannot be stored on a single file server. Given a single DDS-3 tape drive, how do you back up the multiple file systems and configuration data required? There are several available options, but the Amanda backup tool ("Advanced Maryland Automatic Network Disk Archiver") provides the requirements for backing up the file systems and configuration data. This article describes how I used Amanda to organize backups on a complex heterogeneous network. For more on Amanda and how to configure it, see the "Backing Up the Network with Amanda," by David T. Smith (Sys Admin, April 2002).


My home office has a network of various computers including those running MacOS 8, Windows 2000, Tru64 Unix, IRIX, and various forms of UNIX for PCs including Linux and BSDi. However, there is only one tape drive to back up all these systems. My first solution was to designate critical versus non-critical systems and only back up the critical systems. This raised the issue of where to place the tape drive. Should I carry it from machine to machine, or use only one machine?

Initially, I used only one machine and, via remote copies, NFS, and AppleTalk shares, I backed up what was considered to be the critical data (user files and operating system configuration data). Never more than one complete backup of the operating system was ever made because the tape device was carried from machine to machine. This method was awful and led to connector problems, so something else was needed.

Creating the Solution

My first solution was to remote copy all critical data from remote machines and to share all necessary data from one file server. However, this led once more to single backups and brought about disk space issues. Then I stumbled across Amanda, which had a client and a server, as well as the ability to mount remote operating systems file shares. I combined Amanda with a few other tools and was able to make complete backups of all critical machines. Here is the setup.

I installed the following RPMs on the Red Hat (version 7.2) Linux computer that would serve as the Amanda server:

For the sake of security, deny access on the firewall to Amanda because amanda-client contains the amandad server used to create backups on remote clients. The following iptables command restricts access to the ports Amanda uses:
iptables -A eth0-in -p TCP --sport amanda -i eth0 -j DROP
iptables -A eth0-in -p TCP --dport amanda -i eth0 -j DROP
The Amanda server, where your tape or backup device lives, has several configuration files that need to be edited. One of the most important is the disklist file. The disklist file tells Amanda where to go and what type of backup is required. For example, if I put in the disklist to go to machine2, the backup command will run on the server and then communicate with the client's amandad process that performs the backup and sends the backup to the server to be eventually dumped to tape (Figure 1). However, this is not the case for non-UNIX machines.

For Windows machines, smbclient is employed to back up a share. While not allowing a complete machine (disk-level backup), the use of smbclient does allow critical data to be saved to tape. The same is true of AppleShare. For AppleShare backups to be made, the share must be mounted onto the backup server. So, unless you are trying to back up another UNIX/Linux system, you will need to mount the shares to the backup server. Amanda automatically mounts CIFS shares, so some other automated way is required to mount AppleShare file systems. (Of course, you can always leave your CIFS, AppleShare, and NFS shares mounted at all times.)

Create a Disklist File

To create a disklist file you must first pick a name for your backup set. I use DailySet1. In the directory /etc/amanda, create another directory by the name of DailySet1 and then create a disklist file. Here is one I use:

localhost / comp-root
localhost /boot comp-root
localhost hdc1 comp-root
localhost hdd1 comp-root
localhost /home comp-user
localhost /usr comp-root
localhost // comp-user-tar
localhost // comp-user-tar
machine2 /home comp-user
localhost /mnt/appleshare comp-user-tar

There are about three things to note here. First, you need to specify the host to contact. Specifying localhost performs the backup locally while machine2 informs the tool to contact the amandad process on the named machine. Second, specify either file share (including CIFS) names or disk device names for the name of the location to backup. Third, specify the type of backup to perform. (All of the definitions for this column appear in the amanda.conf file discussed later.)

Using the local host and the backup type of comp-root (which you will see below implies to use the dump command) back up the partitions labeled with /, /boot, and /usr. Again using comp-root, back up the explicit disk partitions /dev/hdc1 and /dev/hdd1. Then, using the comp-user backup type (with dump), back up the /home partitions on the localhost and on machine2. This is done by contacting the amandad process running on the client machine2, and having the client send the backup to the server for backup to tape.

Next, back up the /mnt/appleshare directory using comp-user-tar, which uses tar. Back up the AppleShare partition previously mounted from a MacOS 8 machine using the netatalk tool ("Integrating Macintosh Computers into Your Network", by Edward L. Haletky, Sys Admin November 2001). Finally, use smbclient to automatically mount the // and // from two different Windows machines for backup using type comp-user-tar. Read the mount information for CIFS from the file /etc/amandapass.

Below is an example of /etc/amandapass. Note that the username and password is specified in this file as well as the DOMAIN to use when performing the share from Windows using CIFS. Be sure that the permissions on this file are 600 or read/write only for the user, which should be amanda:

// username%password
// username%password DOMAIN
Configure amanda.conf

After the above is configured, look at the amanda.conf file. Below is a sample amanda.conf file with the changes made highlighted in bold. I will be only discussing these changes because the file is well documented.

# amanda.conf - sample Amanda configuration file.  This started off life
# as the actual config file in use at CS.UMD.EDU.
# If your configuration is called, say, "csd", then this file normally goes
# in /etc/amanda/csd/amanda.conf.

org "DailySet1"    # your organization name for reports
mailto "amanda"    # space separated list of operators at your site
dumpuser "amanda"  # the user to run dumps under
inparallel 4       # maximum dumpers that will run in parallel
netusage  600 Kbps # maximum net bandwidth for Amanda, in KB per sec

dumpcycle 0 days    # the number of days in the normal dump cycle
runspercycle 0 days # the number of amdump runs in dumpcycle days
tapecycle 1 tapes   # the number of tapes in rotation
            # 4 weeks (dumpcycle) times 5 tapes per week (just
            # the weekdays) plus a few to handle errors that
            # need amflush and so we do not overwrite the full
            # backups performed at the beginning of the previous
            # cycle
The header section of the amanda.conf is shown above, and there are several changes to make. You must specify your organization for reports. Because there is only one organization, I use the name of the backup for the organization. This helps define the reports. However, if there were multiple organizations to back up using different Amanda runs, the organization name would be important. I have set the dumpcycle and runspercycle to 0 days, implying that a backup will occur daily. Also changed is the tapecycle to state only one tape is to be used per cycle because there is no automatic tape changer in use:

### ### ###
# WARNING: don't use 'inf' for tapecycle, it's broken!
### ### ###
bumpsize 20 Mb  # minimum savings (threshold) to bump level 1 -> 2
bumpdays 1      # minimum days at each level
bumpmult 4      # threshold = bumpsize * bumpmult^(level-1)
etimeout 300    # number of seconds per filesystem for estimates.
#etimeout -600  # total number of seconds for estimates.
# a positive number will be multiplied by the number of filesystems on
# each host; a negative number will be taken as an absolute total time-out.
# The default is 5 minutes per filesystem.

# 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.

# Some tape changers require tapedev to be defined; others will use
# their own tape device selection mechanism.  Some use a separate tape
# changer device (changerdev), others will simply ignore this
# parameter.  Some rely on a configuration file (changerfile) to
# obtain more information about tape devices, number of slots, etc;
# others just need to store some data in files, whose names will start
# with changerfile.  For more information about individual tape
# changers, read docs/TAPE.CHANGERS.

# At most one changerfile entry must be defined; select the most
# appropriate one for your configuration.  If you select man-changer,
# keep the first one; if you decide not to use a tape changer, you may
# comment them all out.

runtapes 1        # number of tapes to be used in a single run of amdump
#tpchanger "chg-manual"  # the tape-changer glue script
tapedev "/dev/nst0"      # the no-rewind tape device to be used
#rawtapedev "/dev/null"  # the raw device to be used (ftape only)
#changerfile "/var/lib/amanda/DailySet1/changer"
#changerfile "/var/lib/amanda/DailySet1/changer-status"
#changerfile "/etc/amanda/DailySet1/changer.conf"
#changerdev "/dev/null"

tapetype DDS3            # what kind of tape it is (see tapetypes below)
labelstr "^DailySet1[0-9][0-9]*$" #label constraint regex: all tapes must match
Now we get to some of the guts of the system. Many changes were made to the commented sections so that they stay in sync with the rest of the changes. Since the backup is named DailySet1, it behooves us to ensure there is no confusion when we uncomment things in the future. We are only allowing one tape to be used for a backup, or a single run of the backup command amdump. We specify a no-rewind tape device, which is /dev/nst0 on this Linux box. The name, nst0, implies that this is a no-rewind SCSI-tape at position 0 (i.e., the first SCSI-tape device in the box).

Holding Disks

The type of tape to use is also required. Use the keyword DDS3 (defined below), to indicate the DDS3 tape represented by /dev/nst0. Because each tape gets labeled, specify the labelstr (label string) to use as DailySet1 with a bunch of regular expressions at the end to match all the tape names (i.e., this would match a label name DailySet1100):

# 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.
# The advantages include: tape drive is more likely to operate in
# streaming mode (which reduces tape and drive wear, reduces total dump
# time); multiple dumps can be done in parallel (which can dramatically
# reduce total dump time. The main disadvantage is that dumps on the
# holding disk need to be flushed (with amflush) to tape after an
# operating system crash or a tape failure.
# If no holding disks are specified then all dumps will be written
# directly to tape.  If a dump is too big to fit on the holding disk than
# it will be written directly to tape.  If more than one holding disk is
# specified then they will all be used round-robin.

holdingdisk hd1 {
    comment "main holding disk"
    directory "/var/tmp"      # where the holding disk is
    use 290 Mb        # how much space can we use on it
                      # a negative value mean:
                      #        use all space except that value
                      #    chunksize 2 Gb   
                      # size of chunk if you want big dump to be
                      # dumped on multiple files on holding disks
                      #  N Kb/Mb/Gb split disks in chunks of size N
                      #  0          split disks in INT_MAX/1024 Kb chunks
                      # -N Kb/Mb/Gb dont split, dump larger
                      #             filesystems directly to tape
                      #             (example: -2 Gb)
Holding disks is a tricky option; by specifying a holding disk below in the backup types, you can back up all your data to a disk partition so that you can later flush these backups to tape once your tape device is ready.

The holding disk is very useful if you have a single cartridge tape device, but on machines with small disks, your disk space will disappear, which is a catch-22. You want to back up every day, for instance, but you may forget to put the tape into the device, which implies that you need to store the backup somewhere. But if you do not have enough disk space, where do you store the backups? This is an awful condition if you cannot get to the tape device to change the cartridge, which is a major selling point for expensive tape changers.

I recommend that you configure a holding disk and then decide whether to use it either in your backup script, or in your backup type definitions (defined below). Note that in this case, /var/tmp is the location of the holding disk defined as hd1, which is an Amanda disk specification and not related to the operating system device specification. If you must use a holding disk, I suggest using a separate disk specifically as a holding disk:

#holdingdisk hd2 {
#    directory "/dumps2/amanda"
#    use 1000 Mb
#    }
#holdingdisk hd3 {
#    directory "/mnt/disk4"
#    use 1000 Mb
#    }

# If amanda cannot find a tape on which to store backups, it will run
# as many backups as it can to the holding disks.  In order to save
# space for unattended backups, by default, amanda will only perform
# incremental backups in this case, i.e., it will reserve 100% of the
# holding disk space for the so-called degraded mode backups.
# However, if you specify a different value for the 'reserve'
# parameter, amanda will not degrade backups if they will fit in the
# non-reserved portion of the holding disk.

# reserve 30 # percent

# This means save at least 30% of the holding disk space for degraded
# mode backups.  

# Amanda needs a few Mb of diskspace for the log and debug files,
# as well as a database.  This stuff can grow large, so the conf
# directory isn't usually appropriate.  Some sites use /usr/local/var and
# some /usr/adm.
# Create an amanda directory under there.  You need a separate infofile
# and logdir for each configuration, so create subdirectories for each
# conf and put the files there.  Specify the locations below.

infofile "/var/lib/amanda/DailySet1/curinfo"      #database filename
logdir   "/var/lib/amanda/DailySet1"              # log directory
indexdir "/var/lib/amanda/DailySet1/index"        # index directory
#tapelist "/var/lib/amanda/DailySet1/tapelist"    # list of used tapes
# tapelist is stored, by default, in the directory that contains amanda.conf
Now specify the location of all the log files. /var/lib/amanda is the actual home directory for the amanda user. It is best to place the log files into a per-backup directory structure (i.e., DailySet1 is the name of this backup). This alleviates log file confusion in the future:

# 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.

# A filemark is the amount of wasted space every time a tape section
# ends.  If you run 'make tapetype' in tape-src, you'll get a program
# that generates tapetype entries, but it is slow as hell, use it only
# if you really must and, if you do, make sure you post the data to
# the amanda mailing list, so that others can use what you found out
# by searching the archives.

# For completeness Amanda should calculate the inter-record gaps too,
# but it doesn't.  For EXABYTE and DAT tapes this is ok.  Anyone using
# 9 tracks for amanda and need IRG calculations?  Drop me a note if
# so.

# If you want amanda to print postscript paper tape labels
# add a line after the comment in the tapetype of the form
#    lbl-templ "/path/to/postscript/template/"

# if you want the label to go to a printer other than the default
# for your system, you can also add a line above for a different
# printer. (i usually add that line after the dumpuser specification)

# dumpuser "operator"     # the user to run dumps under
# printer "mypostscript"  # printer to print paper label on

# here is an example of my definition for an EXB-8500

# define tapetype EXB-8500 {
# ...
#     lbl-templ "/usr/local/amanda/config/"
# }

define tapetype QIC-60 {
    comment "Archive Viper"
    length 60 mbytes
    filemark 100 kbytes         # don't know a better value
    speed 100 kbytes            # ditto

define tapetype DEC-DLT2000 {
    comment "DEC Differential Digital Linear Tape 2000"
    length 15000 mbytes
    filemark 8 kbytes
    speed 1250 kbytes

# goluboff@butch.Colorado.EDU
# in amanda-users (Thu Dec 26 01:55:38 MEZ 1996)
define tapetype DLT {
    comment "DLT tape drives"
    length 20000 mbytes          # 20 Gig tapes
    filemark 2000 kbytes         # I don't know what this means
    speed 1536 kbytes            # 1.5 Mb/s

define tapetype SURESTORE-1200E {
    comment "HP AutoLoader"
    length 3900 mbytes
    filemark 100 kbytes
    speed 500 kbytes

define tapetype EXB-8500 {
    comment "Exabyte EXB-8500 drive on decent machine"
    length 4200 mbytes
    filemark 48 kbytes
    speed 474 kbytes

define tapetype EXB-8200 {
    comment "Exabyte EXB-8200 drive on decent machine"
    length 2200 mbytes
    filemark 2130 kbytes
    speed 240 kbytes

define tapetype HP-DAT {
    comment "DAT tape drives"
    # data provided by Rob Browning <>
    length 1930 mbytes
    filemark 111 kbytes
    speed 468 kbytes

define tapetype DAT {
    comment "DAT tape drives"
    length 1000 mbytes         # these numbers are not accurate
    filemark 100 kbyte         # but you get the idea
    speed 100 kbytes

define tapetype MIMSY-MEGATAPE {
    comment "Megatape (Exabyte based) drive through Emulex on Vax 8600"
    length 2200 mbytes
    filemark 2130 kbytes
    speed 170 kbytes           # limited by the Emulex bus interface, ugh

define tapetype DDS3 {
    comment "Generic DDS3"
    length 12288 mbytes
    filemark 0 kbytes
    speed 1024 kbytes
Now specify the definition for the tape you are going to use. The above was taken directly from the Amanda Web site ( as the specification for a tape that was not previously defined within this file. There are quite a few definitions, but DDS3 style is not part of them. Thus, we add our own definition:

# dumptypes
# These are referred to by the disklist file.  The dumptype specifies
# certain parameters for dumping including:
#   auth       - authentication scheme to use between server and client.
#                Valid values are "bsd" and "krb4".  Default: [auth bsd]
#   comment -    just a comment string
#   comprate       - set default compression rate.  Should be followed by
#   one or
#            two numbers, optionally separated by a comma.  The 1st is
#            the full compression rate; the 2nd is the incremental rate.
#            If the second is omitted, it is assumed equal to the first.
#            The numbers represent the amount of the original file the
#            compressed file is expected to take up.
#            Default: [comprate 0.50, 0.50]
#   compress     - specify compression of the backed up data.  Valid
#   values are:
#             "none"        - don't compress the dump output.
#             "client best" - compress on the client using the best (and
#                          probably slowest) algorithm.
#             "client fast" - compress on the client using fast
#             algorithm.
#             "server best" - compress on the tape host using the best
#             (and
#                        probably slowest) algorithm.
#             "server fast" - compress on the tape host using a fast
#                         algorithm.  This may be useful when a fast
#                         tape host is backing up slow clients.
#             Default: [compress client fast]
#   dumpcycle     - set the number of days in the dump cycle, ie, set how
#             often a
#             full dump should be performed.  Default: from DUMPCYCLE
#             above
#   exclude - specify files and directories to be excluded from the dump.
#             Useful with gnutar only; silently ignored by dump and
#             samba.
#             Valid values are:
#             "pattern"       - a shell glob pattern defining which files
#                             to exclude.
#                             gnutar gets --exclude="pattern"
#             list "filename" - a file (on the client!) containing
#                           patterns
#                           re's (1 per line) defining which files to
#                           exclude.
#                           gnutar gets --exclude-from="filename"
#             Note that the 'full pathname' of a file within its
#             filesystem starts with './', because of the way amanda runs
#             gnutar: 'tar -C $mountpoint -cf - --lots-of-options .'
#            (note
#             the final dot!)  Thus, if you're backing up '/usr' with a
#             diskfile entry like ''host /usr gnutar-root', but you don't
#             want to backup /usr/tmp, your exclude list should contain
#             the pattern './tmp', as this is relative to the '/usr'
#             above.
#             Please refer to the man-page of gnutar for more
#             information.
#             Default: include all files
#   holdingdisk   - should the holding disk be used for this dump.
#             Useful for
#             dumping the holding disk itself.  Default: [holdingdisk
#             yes]
#   ignore -  do not back this filesystem up.  Useful for sharing a
#             single
#             disklist in several configurations.
#   index   - keep an index of the files backed up.  Default: [index no]
#   kencryp - encrypt the data stream between the client and
#             server.
#             Default: [kencrypt no]
#   maxdumps - max number of concurrent dumps to run on the client.
#             Default: [maxdumps 1]
#   priority - priority level of the dump.  Valid levels are "low",
#            "medium"
#             or "high".  These are really only used when Amanda has no
#             tape to write to because of some error.  In that "degraded
#             mode", as many incrementals as will fit on the holding disk
#             are done, higher priority first, to insure the important
#             disks are at least dumped.  Default: [priority medium]
#   program - specify the dump system to use.  Valid values are "DUMP"
#             and
#            "GNUTAR".  Default: [program "DUMP"].
#   record  - record the dump in /etc/dumpdates.  Default: [record yes]
#   skip-full - skip the disk when a level 0 is due, to allow full
#             backups
#             outside Amanda, eg when the machine is in single-user mode.
#   skip-incr - skip the disk when the level 0 is NOT due.  This is
#             used in
#             archive configurations, where only full dumps are done and
#             the tapes saved.
#   starttime - delay the start of the dump?  Default: no delay
#   strategy  - set the dump strategy.  Valid strategies are
#             currently:
#             "standard" - the standard one.
#             "nofull"   - do level 1 dumps every time.  This can be
#                        used,
#                        for example, for small root filesystems that
#                        only change slightly relative to a site-wide
#                        prototype.  Amanda then backs up just the
#                        changes.
#             "noinc"    - do level 0 dumps every time.
#                        Unfortunately, this is not currently
#                        implemented.  Use 'dumpcycle 0'
#                        instead.
#             "skip"     - skip all dumps.  Useful for sharing a single
#                        disklist in several configurations.
#                        Default: [strategy standard]
# Note that you may specify previously defined dumptypes as a shorthand
# way of defining parameters.

define dumptype global {
    comment "Global definitions"
    # This is quite useful for setting global parameters, so you don't have
    # to type them everywhere.  All dumptype definitions in this sample file
    # do include these definitions, either directly or indirectly.
    # There's nothing special about the name 'global'; if you create any
    # dumptype that does not contain the word 'global' or the name of any
    # other dumptype that contains it, these definitions won't apply.
    # Note that these definitions may be overridden in other
    # dumptypes, if the redefinitions appear *after* the 'global'
    # dumptype name.
    # You may want to use this for globally enabling or disabling
    # indexing, recording, etc.  Some examples:
    index yes
    # record no
    holdingdisk yes
The default backup type, labeled as dump type here, is used as the basis for all backups. Each dump type builds upon the global dumptype. Note that here we enable indexing and holding disk usage (see above for holding disk caveats), since these will be used in every subsequent dump type:

define dumptype always-full {
    comment "Full dump of this filesystem always"
    compress none
    priority high
    dumpcycle 0

define dumptype root-tar {
    program "GNUTAR"
    comment "root partitions dumped with tar"
    compress server best
    exclude "/proc"
    priority low
In this dumptype, we add one line to the existing definition. That line will exclude the /proc file system. Since the GNUTAR program will backup everything from the specified directory on down, it is best to exclude the /proc filesystem, which is non-restorable anyway. /proc represents your system's memory layout and kernel configurations. Note that the root-tar dumptype is included by almost every other -tar dumptype:

define dumptype user-tar {
    comment "user partitions dumped with tar"
    priority medium

define dumptype high-tar {
    comment "partitions dumped with tar"
    priority high

define dumptype comp-root-tar {
    comment "Root partitions with compression"
    compress client fast

define dumptype comp-user-tar {
    exclude "./kits"
    compress client fast
The comp-user-tar dumptype depends on the user-tar dumptype, which depends upon the root-tar dumptype, which depends upon the global dumptype. This is critical to understand because we are now specifying yet another exclude directory; in this case, we are excluding the directory ./kits. Thus, we are excluding the directories /proc and ./kits from being backed up to tape. On our system, ./kits represents a copy of several CD-ROMS, so backups already exist:

define dumptype holding-disk {
    comment "The master-host holding disk itself"
    holdingdisk no # do not use the holding disk
    priority medium

define dumptype comp-user {
    comment "Non-root partitions on reasonably fast machines"
    compress client fast
    priority medium

define dumptype nocomp-user {
    comment "Non-root partitions on slow machines"
    compress none

define dumptype comp-root {
    comment "Root partitions with compression"
    compress client fast
    priority low

define dumptype nocomp-root {
    comment "Root partitions without compression"
    compress none

define dumptype comp-high {
    comment "very important partitions on fast machines"
    compress client best
    priority high

define dumptype nocomp-high {
    comment "very important partitions on slow machines"
    compress none

define dumptype nocomp-test {
    comment "test dump without compression, no /etc/dumpdates recording"
    compress none
    record no
    priority medium

define dumptype comp-test {
    comment "test dump with compression, no /etc/dumpdates recording"
    compress client fast

# network interfaces
# These are referred to by the disklist file.  They define the attributes
# of the network interface that the remote machine is accessed through.
# Notes: - netusage above defines the attributes that are used when the
#          disklist entry doesn't specify otherwise.
#        - the values below are only samples.
#        - specifying an interface does not force the traffic to pass
#          through that interface.  Your OS routing tables do that.  This
#          is just a mechanism to stop Amanda trashing your network.
# Attributes are:
#     use         -bandwidth above which amanda won't start
#                  backups using this interface.  Note that if
#                  a single backup will take more than that,
#                  amanda won't try to make it run slower!

define interface local {
    comment "a local disk"
    use 1000 kbps

define interface eth1 {
    comment "10 Mbps ethernet"
    use 400 kbps
Finally, we need to specify which Ethernet card to use when contacting any of the machines in question. Eth1 specifies the secondary Ethernet card on the gateway, which we are also using as our Amanda server, hence the need for the iptables command specified above to lock things down:

# You may include other amanda configuration files, so you can share
# dumptypes, tapetypes and interface definitions among several
# configurations.

#includefile "/etc/amanda/amanda.conf.main"
After the amanda.conf file is written, it is time to label the tapes to be used. The labeling process, as well as amcheck, can also be used to verify the contents of your amanda.conf. However, if you do not have a labeled tape in the tape drive, amcheck will complain, so label the tapes. It is as simple as inserting the tape and running the command, which produces a /etc/amanda/DailySet1/tapelist file:

amlabel DailySet1 DailySet101
repeat for every tape.... But change the numbers

20011219 DailySet101 reuse
20011121 DailySet102 reuse
20011213 DailySet103 reuse
20011214 DailySet104 reuse
20011103 DailySet105 reuse
20011202 DailySet106 reuse
20011029 DailySet117 reuse
20011105 DailySet127 reuse
20011119 DailySet137 reuse
20011203 DailySet147 reuse
20010910 DailySet118 reuse
20011210 DailySet128 reuse
The above naming convention is straightforward. I use twelve tapes in the backup rotation: one for each day Monday (101) through Saturday (106), one for four weeks of Sundays (117-147), and two for my two months of backups (118-128).

Once the tapes are labeled and your amanda.conf file is complete, it is time to do a backup. Because it is best to run several Amanda commands at once to perform a backup, I will place them in a script with a chunk of code to mount any necessary devices and to determine if a cartridge is in the tape device. Here is suggested backup script:

# perform mounts in calling script as this script is run as the amanda
# user.

# specify whether to use a holding disk. I.e to run when a tape is not
# present.
# Get a date for the log file name. Amanda names the logfile for us, we
# just need
# to report on the proper logfile?
da='date +"%Y%m%d"'# Check to see if tape lives
yr='date +"%Y"'

# using mt determine if a tape is available and ONLINE.
rc='mt status | tail -1 | awk '/ONLINE/ {print "true"}''

if [ Z"$holdingdisk" = Z"true" ]
      # Use a holding disk so who cares if a tape is available.
if [ Z"$rc" = Z"true" ]
      # determine if everything is in order. This not only checks the
      # amanda.conf but also
      # the availability of directories and tape labelling
      /usr/sbin/amcheck -m DailySet1

      # Now perform the dump specified in disklist
      /usr/sbin/amdump DailySet1

      # Okay since that is done now we need a report to be sent. A lot of
      # duplication but the
      # report reorganizes a little to be more readable.
      /usr/sbin/amreport DailySet1 -l DailySet1/log.$da.0

      # And frankly it is best to verify your backups so do it here. This
      # will
      # restore each
      # dump to your holdingdisk to verify it is proper.
      /usr/sbin/amverify DailySet1

      # eject the tape.
      mt offline
Email Notification

After the backup is performed, a bunch of email will be sent to the specified user, in this case amanda. In my /etc/aliases file, I have specified that amanda mail should also be sent to the root user so that I can review it all together. The messages below tell me that the backups were successful but the CIFS backups had strange characteristics. Further down in the mail is an explanation that states the CIFS was not browseable but it still could be used in a backup. There is also a summary of the quantity of data backed up to tape, per-file system. You get used to the total backup size; 9 GB is normal for this group of systems. Sample Mail:

These dumps were to tape DailySet103. 
The next tape Amanda expects to use is: DailySet118.

localhost // lev 0 STRANGE
localhost // lev 0 STRANGE


                              Total         Full      Daily
                           --------     --------   --------
Estimate Time (hrs:min)        0:03 
Run Time (hrs:min)             3:42 
Dump Time (hrs:min)            3:37         3:37      0:00
Output Size (meg)            9705.0       9705.0       0.0
Original Size (meg)         13944.1      13944.1       0.0
Avg Compressed Size (%)        69.6         69.6        --
Filesystems Dumped                8            8         0
Avg Dump Rate (k/s)           762.6        762.6        --

Tape Time (hrs:min)            3:38         3:38      0:00
Tape Size (meg)              9705.2       9705.2       0.0
Tape Used (%)                  79.0         79.0       0.0
Filesystems Taped                 8            8         0
Avg Tp Write Rate (k/s)       759.5        759.5        --


/-- localhost // lev 0 STRANGE
sendbackup: start [localhost:// level 0]
sendbackup: info BACKUP=/usr/bin/smbclient
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/usr/bin/smbclient -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
| added interface ip= bcast= nmask=
| session request to failed (Called name not present)
| session request to 10 failed (Called name not present)
? ERRDOS - ERRnoaccess listing \System Volume Information\*
| tar: dumped 793 files and directories
| Total bytes written: 1163900416
sendbackup: size 1136622
sendbackup: end

/-- localhost // lev 0 STRANGE
sendbackup: start [localhost:// level 0]
sendbackup: info BACKUP=/usr/bin/smbclient
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/usr/bin/smbclient -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
| added interface ip= bcast= nmask=
| session request to failed (Called name not present)
| session request to 10 failed (Called name not present)
? ERRDOS - ERRnoaccess listing \System Volume Information\*
| tar: dumped 3864 files and directories
| Total bytes written: 1470119936
sendbackup: size 1435664
sendbackup: end
   taper: tape DailySet103 kb 9938144 fm 8 [OK]


                                   DUMPER STATS           TAPER STATS
--------------------- - -------------- ----- ----------- -------------
localhost /           0 221960 79744   35.9   1:011306.8   1:28  906.9
localhost -0.0.5/Data 0 14356641018304 70.9  34:13 496.0  34:14  495.9
localhost -0.9/Photos 0 11366221088800 95.8  37:07 488.9  37:07  488.9
localhost /boot       0 18550 13216    71.2   0:071890.0   0:30  434.5
localhost /home       0 27466001924160 70.1  35:26 905.0  35:27  904.7
localhost /usr        0 36137601288480 35.7  24:57 860.6  24:58  860.2
localhost hdc1        0 25154602087232 83.0  39:27 881.7  39:28  881.4
localhost hdd1        0 25901702437952 94.1  44:52 905.6  44:53  905.3

(brought to you by Amanda version 2.4.2p2)
crontab output shows the amcheck was successful as was the amverify:

Tapes: DailySet103
No errors found!

amverify DailySet1
Fri Dec 21 05:43:39 CST 2001

Using device /dev/nst0
Volume DailySet103, Date 20011221
Checked localhost._boot.20011221.0
Checked localhost._.20011221.0
Checked localhost._usr.20011221.0
Checked localhost.__10.0.0.9_Photos.20011221.0
Checked localhost._home.20011221.0
Checked localhost.hdc1.20011221.0
Checked localhost.__10.0.0.5_Data.20011221.0
Checked localhost.hdd1.20011221.0
End-of-Tape detected.
If a flush is in order, I recommend that this step be done by hand. It would be extremely difficult to automate the use of amflush if there were not a tape changer involved. You will need to perform the flush for every missed backup using a combination of inserting the proper cartridge then running the amflush command as the amanda user.

Another critical bit is that all the tools only work as the amanda user, so your backup script should be run as amanda -- but daily. This can be performed by placing a script in /etc/cron.daily that turns around and, as root, uses the su command to run the backup script as the amanda user. Note that by placing a script in /etc/cron.daily there is no messy crontab entry to make. Be sure that the amanda user has write and read access to the tape device /dev/nst0. This backup script should also perform all the necessary mounts to back up alternative sharing mechanisms, like AppleShare:

mount /mnt/appleshare
su - amanda -c /var/lib/amanda/backup
umount /mnt/appleshare
You can also add the following crontab as well as the amanda user using crontab -e. However, you do not get mounting of necessary shares using this method:

02 2 * * * $HOME/backup

You have now successfully completed the configuration of and performed a backup using the Amanda backup tool. The 12-tape rotation gives a nice daily, weekly, and monthly backup necessary for network servers. Granted, having a yearly backup would be wonderful, but I have found that two months in reserve is sufficient for my personal needs. Measure your backup needs carefully and keep as many months or weeks as necessary. This article goes into the configuration and usage of the Amanda tool, but not the determination of what style of backup is necessary for your network. For further reference, I recommend UNIX Backup and Recovery by W. Curtis Preston (O'Reilly and Associates), which has a chapter on Amanda.

Edward L. Haletky graduated from Purdue University in 1988 with a degree in Aeronautical and Astronautical Engineering. Since then, he has worked programming graphics and other lower-level libraries on various UNIX platforms. He currently works for Compaq Computer Corporation in the High Performance Computing Expert Team, dealing with Tru64 and Linux Clustering technologies and environments.