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

Background

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:

amanda-2.4.2p2-4
amanda-server-2.4.2p2-4
amanda-devel-2.4.2p2-4
amanda-client-2.4.2p2-4

iptables -A eth0-in -p TCP --sport amanda -i eth0 -j DROP
iptables -A eth0-in -p TCP --dport amanda -i eth0 -j DROP

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:

/etc/Amanda/DailySet1/disklist:
localhost / comp-root
localhost /boot comp-root
localhost hdc1 comp-root
localhost hdd1 comp-root
localhost /home comp-user
localhost /usr comp-root
localhost //10.0.0.9/Photos comp-user-tar
localhost //10.0.0.5/Data 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 //10.0.0.9/Photos and //10.0.0.5/Data 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:

//10.0.0.9/Photos username%password
//10.0.0.5/Data username%password DOMAIN

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.

/etc/amanda/DailySet1/amanda.conf:
#
# 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

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

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)
    }

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

# 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/label.ps"

# 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/lbl.exabyte.ps"
# }


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 <rlb@cs.utexas.edu>
    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
}

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

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

define dumptype root-tar {
    global
    program "GNUTAR"
    comment "root partitions dumped with tar"
    compress server best
    index
    exclude "/proc"
    priority low

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

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

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

define dumptype comp-user-tar {
    user-tar
    exclude "./kits"
    compress client fast
}

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

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

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

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

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

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

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

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

define dumptype comp-test {
    nocomp-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
}

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

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

/etc/amanda/DailySet1/tapelist:
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

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:

/var/lib/amanda/backup:
#!/bin/sh
# 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.
holdingdisk=false
# 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" ]
then
      # Use a holding disk so who cares if a tape is available.
      rc="true"
fi
if [ Z"$rc" = Z"true" ]
then
      # 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
fi

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.

FAILURE AND STRANGE DUMP SUMMARY:
localhost //10.0.0.9/Photos lev 0 STRANGE
localhost //10.0.0.5/Data lev 0 STRANGE

STATISTICS:

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

FAILED AND STRANGE DUMP DETAILS:

/-- localhost //10.0.0.9/Photos lev 0 STRANGE
sendbackup: start [localhost://10.0.0.9/Photos 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=10.0.0.4 bcast=10.0.0.255 nmask=255.255.255.0
| session request to 10.0.0.9 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 //10.0.0.5/Data lev 0 STRANGE
sendbackup: start [localhost://10.0.0.5/Data 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=10.0.0.4 bcast=10.0.0.255 nmask=255.255.255.0
| session request to 10.0.0.5 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
\--------
NOTES:
   taper: tape DailySet103 kb 9938144 fm 8 [OK]

DUMP SUMMARY:

                                   DUMPER STATS           TAPER STATS
HOSTNAME  DISK        L ORIG-KB OUT-KB COMP% MMM:SS KB/s  MMM:SS KB/s
--------------------- - -------------- ----- ----------- -------------
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)

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.

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

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.