Using AMANDA

The preceding sections have described fairly basic backup options and configurations. If your network hosts just a handful of computers, you may be satisfied to perform backups manually using these methods , or to write scripts to be run from cron jobs that perform backups on an automatic basis. For larger networks, though, more sophisticated tools are in order. That's the function of the Advanced Maryland Automatic Network Disk Archiver (AMANDA). This package glues together other network backup tools to help automate backups across small, mid- sized , or even large networks. The AMANDA Web page is http://www.amanda.org. You can obtain the software from there, or from the distributions that ship with it, such as Debian, Red Hat, Mandrake, and SuSE.

WARNING

AMANDA hard-codes some critical values in its executables, so mixing binaries acquired from different distributions may not work. If your environment includes multiple distributions, it may be best to build the package from source yourself. Be sure to specify the same user and group with the --with-user and --with-group options to configure on all your systems. You may want to create a special user and group for AMANDA operations.

The Function of AMANDA

AMANDA includes both backup server and backup client software. You install the server software on the backup server, and backup client soft ware on the backup clients . These programs communicate with each other using their own protocols; NFS, rshd , and the like are not used by AMANDA. (When AMANDA backs up Windows systems, though, it uses smbclient and the standard Windows SMB/CIFS server package, as described earlier.)

In addition to functioning as a conduit for network connections, AMANDA serves as a scheduling tool. It's often helpful, or even necessary, to carefully schedule different types of backups, particularly in large networks. Specifically, you probably don't need to back up every file on every computer with every backup. Such a policy would consume an inordinate amount of network bandwidth, even if the backups were scheduled to start in off hours ”the backup might not complete for days, depending on the network size . When using simple tools like tar run from cron jobs, it's common to use the --listed-incremental option, or its equivalent in other packages, to minimize the impact of backups. AMANDA can help manage network backup bandwidth by keeping track of which computers have been backed up at any given time, and whether they've received full or incremental backups. AMANDA can then schedule computers for appropriate backup types on specific days of a multiday backup rotation.

Like a Samba backup server that uses processed backups, AMANDA normally functions by first copying data from the backup clients to the backup server's hard disk, and then copying those files to tape. (You can configure AMANDA to send data directly to tape, but such a configuration is likely to be slower than the normal configuration.) Therefore, an AMANDA server works best when it has a large hard disk ”large enough for at least one day's backups plus the normal system software. Having double the normal day's backup capacity allows you to dump one backup to tape while retrieving another backup set from the network. AMANDA can function with less than this amount of free disk space, but it will then have to perform a single backup in chunks . For instance, with 1GB of free space, AMANDA might grab 1GB of data from backup clients, write that data to tape, then fetch another 1GB of data, and so on.

Configuring Clients for AMANDA

AMANDA uses a server-initiated backup strategy, so the AMANDA clients need to run server software. For Linux and UNIX clients, this software ships with AMANDA, and is known as amandad . It's normally run from a super server. An appropriate /etc/inetd.conf file entry to launch this server resembles the following:

 amanda  dgram  udp  wait  amanda  amandad  amandad

You may need to add an explicit path to the amandad executable for your system. If your distribution uses xinetd rather than inetd , you'll need to adjust this entry for xinetd , as discussed in Chapter 4. This entry runs the amandad server as the user amanda , which must exist on the computer; you can change this to suit your own needs.

NOTE

The AMANDA documentation describes launching the package using a special username and group dedicated to backups, such as amanda , but this approach often doesn't work. You may need to launch amandad as root to get it to work.

For the super server configuration to work, your /etc/services file must contain an entry for the amanda service. A suitable entry looks like this:

 amanda  10080/udp

After creating appropriate super server and /etc/services entries, you should restart your super server to make the AMANDA backup client software available to the backup server. The rest of the configuration for your client occurs on the backup server computer.

NOTE

The AMANDA backup server must be backed up along with other systems on the network. For this reason, the backup server itself is usually configured as a backup client, as well as being configured as the backup server.

The backup client requires an authorization file, called .amandahosts , to be stored in the home directory of the AMANDA user's home directory. This file should contain the fully qualified domain name of the backup server and the name of the backup user on that system, separated by a space or tab. For instance, the following file allows amanda on the buserver.threeroomco.com backup server to perform backups:

 buserver.threeroomco.com amanda

As noted earlier, AMANDA uses the SMB/CIFS server on Windows systems to back up those computers. You can configure Windows computers as AMANDA backup clients as described earlier in "Sharing Files to Back Up."

Configuring the AMANDA Backup Server

Because the AMANDA backup server functions as a network client for normal backup operations, it doesn't need to run actual server software for these functions. AMANDA does support client-initiated restores , though, so the AMANDA package includes two server programs that run on the backup server. These allow clients to view packages available for restoration, and to initiate a restore operation. As with the server software run on backup clients, these programs are typically run from a super server. Appropriate /etc/inetd.conf entries look like this:

 amandaidx  stream  tcp  nowait  amanda  amindexd  amindexd amidxtape  stream  tcp  nowait  amanda  amidxtaped  amidxtaped

As with the backup client software, you may need to add an explicit path to the executables, and of course if your system uses xinetd , you'll need to create appropriate configurations for that package, as discussed in Chapter 4. The matching /etc/services entries for these lines are as follows :

 amandaidx  10082/tcp amidxtape  10083/tcp

The user who runs AMANDA, which is normally the same user specified in the super server configuration file for running the AMANDA servers, should have read-write access to the nonrewinding tape device file. Without this permission, AMANDA won't be able to access the tape to perform backups.

Creating an AMANDA Configuration

The AMANDA package is controlled through the amanda.conf file, which may be located in a subdirectory of /etc , /usr/local/etc , or a similar location. Typically, AMANDA uses its own two-tiered subdirectory for its configuration file. This subdirectory should be readable only by the AMANDA user ( amanda in this example). The first tier of AMANDA's subdirectory is called amanda , and the second tier is named after the backup configuration. For instance, there might be a /usr/local/etc/amanda/Daily for routine daily backups and a /usr/local/etc/amanda/Archive for archival backups, each with its own configuration file. If you installed AMANDA from source code, you'll find a sample configuration file in the example subdirectory of the source package.

Setting Basic Options

The amanda.conf file format consists of lines that contain keywords followed by one or more values. For instance, a line that tells AMANDA how long it can take to process an entire network backup might be:

 dumpcycle 4 weeks

A few configuration options span multiple lines. These are surrounded by curly braces ( {} ), and define a set of related options.

You can leave many configuration options at their default values. Some that you may want to adjust include the following:

org ” This sets the name of your organization, as used in reports that AMANDA generates. It's largely cosmetic, but you might as well set it to something reasonable.
mailto ” AMANDA e- mails reports on its activities to the addresses listed in this option. You may specify multiple addresses, separated by spaces.
dumpuser ” This is the username that runs the backup. This defaults to the value specified with the --with-user option to configure when you built AMANDA.
dumpcycle ” This is the number of days in a dump cycle (a complete network backup).
runspercycle ” AMANDA can run every day, multiple times per day, or once every several days, as you wish, by setting this parameter. For instance, if dumpcycle is set to four weeks, setting runspercycle to 20 causes AMANDA to compute what to back up based on one run per weekday. Setting this value to 4 causes AMANDA to assume it will be run just once a week. (Note that AMANDA is actually run from cron jobs; these settings just tell AMANDA what to expect, and therefore how to plan its backups.)
tapecycle ” This sets the number of tapes used in a dump cycle. It's normally slightly larger than runspercycle to allow for tapes with errors.
tapetype ” You tell AMANDA what type of tape device you have so that the package can compute how quickly it can back up data and other information. The middle of the example amanda.conf file defines several tape types, and you should set the tapetype option to one of these. If you don't see a suitable tape type, you'll have to create one. The most reliable way to do this is to use the tapetype utility, which is included with AMANDA but isn't built by default. Go to the tape-src subdirectory of the source package and type make tapetype . Then mount a scratch tape in the tape drive and type ./tapetype -f /dev/ tapedevice (where tapedevice is your device filename) to get a list of values for your drive. This operation will probably take several hours, and will erase all the data on the tape. If your tape drive supports hardware compression, you can probably multiply the length value by 1.5 or 2, but if you back up data that's not easily compressed, such multiplication may cause failures if the tape runs out of space.
tapedev ” This is the Linux device file for the nonrewinding interface for your tape device. In most cases, it will be /dev/nst0 or /dev/nht0 .
netusage ” This is the maximum network bandwidth AMANDA can expect to achive.
labelstr ” This is a regular expression that AMANDA uses to assign names to backup tapes. You'll have to prepare tapes with names based on this value, as described shortly, in the section "Preparing Tapes."
tpchanger , changerfile , and changerdev ” If your tape drive is a changer model, you must define its operation by providing a changer file definition and a pointer to the changer device file. Some example files are included in the example directory of the source distribution.
Log files ” AMANDA sets log file locations with the infofile and logdir options. Similarly, index files containing lists of files that have been backed up are set with the indexdir option. You might or might not want to change these values, but you should definitely check them.

In addition to setting these basic values, you must also configure a holding area for data. This is achieved with the holdingdisk option, which takes a multi-line value consisting of several suboptions. These include directory (where the files are to be stored) and use (how much space you can use on the disk). If your backup server is short on disk space, you can set a negative value for chunksize . This will cause files larger than the absolute value of the chunksize to be sent directly to tape, bypassing the holding area. (Positive values of chunksize cause AMANDA to temporarily break up large files for storage in the holding area. This can be very useful if your holding disk filesystem or kernel doesn't support large files. For instance, 2.2. x kernels on x 86 CPUs only support 2GB files.)

Preparing Tapes

AMANDA needs to see tapes that have been prelabeled as ones it may use. To do this, use the amlabel utility as the user who will run backups:

 $  amlabel Daily DailySet123

The Daily option to amlabel sets the subdirectory in which the matching amanda.conf file resides, so that amlabel can read the appropriate configuration options. The DailySet123 option is the label to give to the backup tape. This value should match the regular expression set with the labelstr option in amanda.conf , or AMANDA won't be able to use the tape. In most cases, AMANDA will back up a network to a set of tapes, so you'll need to label several tapes. You may want to develop some naming scheme for these tapes to help you differentiate among them.

Defining Dump Types

Near the end of the sample amanda.conf file are a number of dumptype definitions. These specify how a given client, or a single filesystem on the client, is to be backed up. Features you can set in these definitions include:

compress [client server] [best fast none] ” You can specify that compression be performed on the backup client or the backup server, depending upon available CPU and network resources. You can also set compression to be more efficient but use more CPU time ( best ) or be faster but less efficient ( fast ). The none option explicitly disables compression.
exclude [list] " string " ” AMANDA passes string to the ”exclude or --exclude-from options to tar , depending on whether list is included as well.
holdingdisk boolean ” Set boolean to yes or no to tell AMANDA to use a holding disk area or not.
index boolean ” Set boolean to yes or no to tell AMANDA whether to create an index of the files in the backup set. Without an index, restores are much more tedious , but an index consumes disk space you might prefer to devote to other purposes.
kencrypt boolean ” You can tell AMANDA to encrypt data sent across the network with Kerberos protocols with this option. Setting boolean to yes requires that your network be configured to use Kerberos, as described in Chapter 6, Authenticating Users via Kerberos.
program " string " ” AMANDA may use either GNU tar or the OS- and filesystem-specific dump program to perform backups, and this is the option that sets which to use. The default is usually dump (set by a string of DUMP ), but tar may be selected by setting string to GNUTAR . (When backing up via Samba, the default is to use tar .)
skip-incr boolean ” If boolean is true, filesystems that use this dump type will be skipped during incremental backups.

There are other options you can set in a dump type definition. Some of these are the same as those set in earlier sections of the file, such as dumpcycle . Others are described in the amanda man page. Most dump type definitions begin with the name of another definition. This sets a series of values based on that earlier definition. You can use this to set default values. For instance, the default amanda.conf file uses a definition called global that's included in other definitions.

Keep in mind that a single backup may use multiple dump types. For instance, you might back up critical system files without using compression, but compress data in less important directories. Similarly, you might use dump to back up ext2fs partitions, but tar to back up ReiserFS partitions.

Defining a Backup Set

The amanda.conf file includes many important backup options, but it doesn't specify the names of backup client systems or the directories to be backed up on those clients. This is the job of the disklist file, which resides in the same directory as amanda.conf . The AMANDA source ships with a sample disklist file, but of course yours will be very different from this sample.

The disklist file consists of a series of lines, each of which contains three fields: The hostname of the backup client, the area to be backed up, and the dump type to be used in backing up that area. The area to be backed up may be specified as a device filename (such as /dev/hda2 or simply hda2 ) or as a mount point (such as /home ). This file may also include comments, which are preceded by pound signs ( # ). Listing 17.2 shows a simple disklist file.

Listing 17.2 A sample `disklist` file

 # Back up the backup server itself buserver.threeroomco.com  /               root-tar buserver.threeroomco.com  /var            user-tar buserver.threeroomco.com  /hold           holding-disk # Back up a Linux or UNIX client buclient.threeroomco.com  /               root-tar buclient.threeroomco.com  /home           user-tar # Back up a Windows client buserver.threeroomco.com  //WINPC/DRIVEC  user-tar

Most of these entries should be self-explanatory. You might or might not use the default dump types, but if you do they're likely to include the ones shown in Listing 17.2. The /hold partition on buserver.threeroomco.com is the AMANDA holding area. This dump type includes the holdingdisk no option to prevent an attempt to use this area to back itself up. If this partition held nothing but holding area files, you might skip it entirely. The Windows client is backed up by specifying a Linux or UNIX system on which Samba is installed and working, and listing the NetBIOS name ( WINPC ) and share name ( DRIVEC ) of the Windows client to be backed up. Listing 17.2 uses the backup server itself as the Samba system, but you can use another system if you prefer. (Using the backup server reduces unnecessary network traffic, though.) The Windows system's drive need not be mounted to be backed up; AMANDA calls on the Samba system to use smbclient to do the job. Essentially, the Samba system uses smbclient much like a regular backup client uses tar or dump . To work, you must create a file called /etc/amandapass on the Samba system. Place the Windows share name followed by the password in this file. AMANDA sends SAMBA as the username, so if you back up Windows NT, 2000, or XP systems, those systems must have such a user defined. You can change the default username by using the --with-samba-user option to configure when building AMANDA.

Running an AMANDA Backup

To run an AMANDA backup, you use the amdump program on the backup server computer. Type the program name, followed by the backup set name (that is, the name of the directory in which the configuration files are stored). For instance, you might type amdump Daily . Of course, you must first insert an appropriate backup tape that you've already prepared with amlabel , as described earlier, in the section "Preparing Tapes." AMANDA will review the areas that need to be backed up and perform an appropriate backup. This backup might not process every computer on the network, or even all of a single computer. Depending upon settings for configuration options like dumpcycle and the capacity settings in your tape type definition, AMANDA may back up just some computers, or perform partial backups rather than full backups. Assuming you haven't created a dump cycle that's too short, though, AMANDA will back up your entire network over the course of that cycle.

Of course, you probably don't want to run amdump manually. It's best to run it in a cron job, probably at some time when your network isn't being heavily used, such as late at night. You should try to ensure that the backup clients will be available at these times, though. Many users are used to shutting off their computers when they leave work, so you may need to break them of such habits.

When AMANDA finishes its backup, it sends an e-mail report of its activities to the addresses specified using the mailto option in amanda.conf . You can examine this report to spot any problems, such as computers that weren't accessible or a tape that filled up unexpectedly.