Section 14.4. Backing Up with AMANDA

14.4. Backing Up with AMANDA

Samba can be an effective part of a network backup solution, but it's got its limitations. Most importantly, it can be difficult to schedule backups, particularly on larger networks; you must add each machine individually to a network backup schedule. One solution to this problem is AMANDA, which was designed to automate the tape backup process as much as possible, while also providing tools to simplify the restore process. AMANDA serves as a "wrapper" around several other tools, and as such requires extra configuration. Once it's configured, though, AMANDA simplifies the day-to-day administration of a backup plan.

To begin using AMANDA, you should first understand its principles of operation: what can it do and how does it do it? Three types of configuration are then relevant: the AMANDA backup server, Linux backup clients, and Windows backup clients. Once you've configured all your systems, you can proceed to using AMANDA for both backups and restores.

14.4.1. AMANDA Principles

AMANDA was designed as a network-centric backup solution, in the sense that it's designed to treat a network as a single entity that's to be backed up. This contrasts with tar or even smbtar, which treat backups on a computer-by-computer basis. Of course, you must still tell AMANDA about the individual computers that are to be backed up, but you needn't be concerned with details such as scheduling when each system is backed up. Instead, let AMANDA work out those details, based on information you provide it concerning how often you want to complete a backup and what your network bandwidth is. Of course, you must ensure that backup clients are accessible to the backup server at the scheduled times. Because you may not know what those times are, it's best to make the backup clients accessible at all times.

AMANDA performs backups using two types of network protocols: its own unique tools and SMB/CIFS. AMANDA uses its own protocols to back up other Linux or Unix systems; these systems run tar or dump locally and transfer data to the AMANDA server. For Windows systems, AMANDA uses smbclient to transfer data using SMB/CIFS. In both cases, the backup clients must run server software and respond as servers. The AMANDA backup server, though, also runs server software, for the benefit of client-initiated restores. This configuration means that AMANDA can be trickier to configure than most backup server systems. Once configured, though, the backup procedure can be highly automated, and partial restores can be simpler, as well.

AMANDA hardcodes some values in its executables. Thus, mixing AMANDA client and server packages for different Linux distributions may not work very well. If your site has multiple Linux distributions, or Linux and other Unix-like systems, you may need to compile AMANDA locally to get these systems to interoperate. Pay particular attention to the --with-user and --with-group options, which set the AMANDA user and group. In theory, a low-priority backup user should work, but in practice, you may need to run it as root to back up all files on the backup clients. This isn't a concern for networks with a Linux AMANDA backup server and Windows backup clients; because the Windows backup clients run SMB/CIFS servers rather than AMANDA servers, no special coordination is necessary.

AMANDA's normal mode of operation is to first copy data from the backup client to a holding area on the backup server's hard disk and then copy this data to the backup tape. (AMANDA was designed with tape backups in mind and can't be used with other backup media.) AMANDA therefore works best with a large local hard disk, or at least something that's large enough to hold a substantial chunk of a day's backup. If your local hard disk is smaller than this, AMANDA will perform the backup in bursts, pulling as much data as it can from the client, backing it up to tape, pulling more from the client, and so on. This process is likely to be less efficient than retrieving a full backup and then spooling it all to tape.

14.4.2. Configuring an AMANDA Server

The bulk of the effort in AMANDA configuration is on the backup server side. Tasks include running the server programs for client-initiated restores, setting general AMANDA options, preparing tapes, and defining backup sets.

14.4.2.1 AMANDA server programs

The AMANDA backup server computer doesn't need to run any server programs for ordinary backup operations, but it does need to run two server programs to handle client-initiated restores: amandaidx and amidxtape. These programs are typically run from a super server (inetd or xinetd). If your distribution uses xinetd, and you install AMANDA from a package provided by your distribution, it may include one to three files in /etc/xinetd.d to handle the serversboth the servers for the backup server system and the server for the backup clients. (This third server is described in the Section 14.4.3.) If these files aren't present, you can create one or two files to do the job. These files should contain entries like these:

service amandaidx {    socket_type  = stream    protocol     = tcp    wait         = no    user         = amanda    group        = disk    server       = /usr/lib/amanda/amindexd    disable      = no } service amidxtape {    socket_type  = stream    protocol     = tcp    wait         = no    user         = amanda    group        = disk    server       = /usr/lib/amanda/amidxtaped    disable      = no }

These entries tell xinetd to handle the servers. You may need to adjust some items for your system; pay particular attention to the user and group entries, which should match the values used when the servers were compiled. (Consult your binary package's distribution if you installed a binary package.) You might also need to adjust the path to the server. If your package includes xinetd configuration files, you shouldn't need to adjust these features, but you may need to change the disable lines, as these usually ship set to yes, which disables the servers.

The user who runs AMANDA on the backup server must have read/write access to the backup device files.

If your distribution uses inetd rather than xinetd, you must create entries in /etc/inetd.conf to handle these two servers:

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

In addition to the inetd or xinetd configuration files themselves, you should check your /etc/services file to be sure that port numbers are registered under the names used in your super server registration:

amandaidx  10082/tcp amidxtape  10083/tcp

Once you've made these changes, restart or reload your super server. You can typically do this using a SysV startup script by typing /etc/init.d/xinetd restart or something similar. Consult your distribution's documentation if you have problems.

14.4.2.2 Setting AMANDA options

AMANDA uses two main configuration files, each stored under /etc/amanda or subdirectories of that directory:

amanda.conf

This file holds the main AMANDA configuration options. This file sets site-wide options.

disklist

This file specifies the computers that are to be backed up and the partitions on those computers that you want to back up. It's covered in more detail in Section 14.4.2.4.

In theory, these files can reside in /etc/amanda, or sometimes in /etc, /usr/local/etc, or a similar location. In practice, it's common to define multiple sets of configuration files, each of which resides in a subdirectory named after its purpose. For instance, you might use a directory called /etc/amanda/daily for daily backups and /etc/amanda/archive for long-term archival backups. You can then perform radically different types of backups by running AMANDA with appropriate options to use the configuration files you specify. Many AMANDA configurations provide a sample amanda.conf file in the /etc/amanda/example directory. You can copy this file to a new directory you create and modify it to suit your purpose.

Most amanda.conf options consist of a keyword followed by one or more options, such as netusage 800 Kbps to tell AMANDA that it may use up to 800 Kbps of network bandwidth. Some configuration options, though, require multiple lines. These use an opening curly brace ({) to mark the beginning of the block of lines that apply to an option and a closing curly brace (}) to mark the end of the block.

You can leave most of the options alone in a typical example configuration file. Here are some of the options you might need to adjust:

org

This option sets a name that appears in reports, so it's not critical for basic functioning, but you might as well set it.

mailto

Specify usernames or email addresses using this option, and AMANDA will send reports on its activities to those addresses.

dumpuser

AMANDA runs backups as the user you specify with this option. If it's unspecified, it uses a compile-time option that's specified via the --with-user option when building the program.

netusage

This option specifies the maximum amount of network bandwidth that AMANDA can expect to have available to it.

dumpcycle

You tell AMANDA how long you want a full network backup to take with this option. Typically, you specify a value in days or weeks, such as 5 days or 2 weeks.

runspercycle

This option sets the number of times that AMANDA expects its amdump program, which does most of the real work, to run in each dump cycle. Setting this value equal to the number of days in dumpcycle results in an expectation of one run per day, while setting it to a higher or lower value results in multiple runs per day or less than one run per day. (The amdump program is actually run by cron; this option just tells AMANDA what to expect for planning purposes.)

tapecycle

This option specifies the number of tapes used in a dump cycle. Ordinarily, it's the same as runspercycle plus a few for error handling; in case a tape goes bad and can't be used, you want AMANDA to be able to recover relatively gracefully.

runtapes

You can tell AMANDA to use multiple tapes per run by specifying the number with this option. The default value is 1, which is usually desirable.

tapedev

You tell AMANDA what tape device to use with this option. AMANDA expects to use nonrewinding tape devices, so be sure to point to one.

tapetype

To plan its backups, AMANDA must know several key things about your tape backup device. You therefore specify the tape type with this option, which refers to definitions that appear later in the amanda.conf file. (Search for define tapetype to find this list.) If you don't see your tape device in the list, you'll need to either locate one on the Internet (check the AMANDA home page, and click the TapeType link) or generate one yourself. To do the latter, you'll need the tapetype utility, which comes with the AMANDA source code but isn't built by default. Type make tapetype in the source code directory to build it. You should then insert a tape that holds no important data and type ./tapetype -f /dev/device to test the tape accessible from /dev/device. This operation erases all data on the tape and will probably take several hours. If your tape device supports hardware compression, you may be able to increase the reported tape length by the compression ratio (typically about 2), but if you then try to back up data that's not easily compressed, AMANDA may run out of space on the tape, which will cause problems.

labelstr

When preparing tapes, as described in the next section, you give each tape a name. You must provide a regular expression describing the form of this label; AMANDA will use only tapes that match this label. This helps prevent accidental erasure of tapes if you insert the wrong one in the tape drive.

Another important option is the description of holding disks. You can define one or more holding areas, and each definition spans multiple lines, as in:

holdingdisk hd1 {   comment "primary holding area"   directory "/var/spool/amanda"   use -500 MB   chunksize 2000 MB }

The comment is a comment for human use, and the directory specifies the location of the holding area. The use line is optional; when it's present, it specifies how much space may be used in this area. A negative use value tells AMANDA how much disk space to leave free; this example causes AMANDA to leave at least 500 MB available. The chunksize line is also optional, and it specifies the maximum size of individual files that are temporarily stored in the holding area. This feature can be useful on some older filesystems or 2.2.x kernels, which have file size limits of about 2 GB. A negative chunksize value tells AMANDA to attempt to pass files larger than the absolute value of the specified size directly to the tape device, which saves disk space but may result in slower operation, depending on your hardware.

14.4.2.3 Preparing tapes

AMANDA labels every tape that it uses, then keeps track of the tapes during the backup process. This arrangement enables AMANDA to tell you precisely what tape to insert in the drive when performing restores. To do any good, though, you must first label all the tapes you'll use for a backup set. To do this, use the amlabel command:

$ amlabel daily DailySet107

You must run this command as the user who will perform the backup. It takes the name of the backup configuration (that is, a subdirectory name within /etc/amanda) and a label as options. In this example, the label is DailySet107. This label must match the regular expression specified on the labelstr line in amanda.conf, or AMANDA won't be able to use the tape.

14.4.2.4 Defining dump types and backup sets

In order to accommodate different computers' backup needs, AMANDA provides a number of dump types near the end of the amanda.conf file. These dump types are specified with the define dumptype option, as in:

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

Each named dump type is referenced in the disklist file to set assorted backup options, each of which appears on its own line within the dump type definition. Some of the options you might want to set include:

compress

This option sets two options: whether compression occurs on the client or the server and the compression's speed/quality tradeoff (best, fast, or none).

exclude

You can exclude individual files from backup using this option. Alternatively, exclude list enables you to pass a list of filenames that AMANDA will exclude from backup. AMANDA excludes no files by default.

holdingdisk

Pass yes or no to this option to tell AMANDA whether to use a holding disk. The default value is yes.

index

Pass yes or no to this option to tell AMANDA whether to store an index of files that are backed up. You might want to omit the index on disks that are likely to be restored only in a full restore as a measure for saving disk space. The default value is yes.

kencrypt

This option takes yes and no values, and controls whether AMANDA uses Kerberos encryption. Setting it to yes requires that your network use Kerberos, as described in Chapter 9. The default value is no.

program

Pass "DUMP" (including the quote marks) as this option's parameter to have it use dump for backups on the remote system; pass "GNUTAR" to have it use tar. Given the limitations of dump, routinely using program "GNUTAR" is often wise. The default is "DUMP" for AMANDA backup clients, but only "GNUTAR" is valid for Samba clients, so that's the default.

skip-incr

If this option is yes (the default is no), disks that use this dump type are skipped when performing incremental backups.

priority

This option accepts values of low, medium, and high, which describe the importance of the disk for the backup. In case of errors or insufficient disk space, disks with higher priorities are saved, at least in the holding area, in preference to disks with lower priorities. The default value is medium.

These and more options are described in comments in the amanda.conf file, so if you'd like to achieve some effect not described here, check that file's comments. The example configuration file includes many dump types, so chances are you can use those that are provided. Peruse them to learn more. You can then create a disklist file, which specifies the backup client computers, the directories you want to back up, and the dump types you want to use for each directory:

# Be sure to back up the backup server buserver.example.org /      root-tar buserver.example.org /var   root-tar buserver.example.org /hold  holding-disk # Back up a Linux client buclient.example.org /      root-tar buclient.example.org /home  user-tar # Back up a Windows client buserver.example.org //GINGKO/DRIVEC  user-tar

The first set of entries in this example configuration backs up the backup server system. This means that the backup server must be configured as a backup client (as described in the next section), as well as being configured as a backup server.

For Linux or other Unix-like systems that run AMANDA software, you specify the hostname, a directory name, and a dump type. For Windows backup clients, you specify the backup server as the hostname and provide a hostname and share name in //HOST/SHARE format instead of a directory specification. AMANDA then uses Samba's smbclient to transfer the files. You must also create a password file, /etc/amandapass, which holds share names along with usernames and passwords:

//GINGKO/DRIVEC  mypassword //MAIZE/DRIVED   buuser%bupassword

This example sets a password alone for the DRIVEC share on GINGKO, and a username and password for the DRIVED share on MAIZE. Because this file contains unencrypted passwords, you should ensure that it's readable only to the backup user (and root, if the two aren't the same).

At this point, AMANDA is configured on the backup server; however, you must still configure it on any Linux clients and prepare Windows systems. Once this is done, you can actually begin using AMANDA for backups and restores.

14.4.3. Linux AMANDA Client Configuration

Linux AMANDA backup clients run a server program called amandad, which responds to commands from the backup server system. The amandad program is normally run from a super server. If you installed AMANDA from a distribution's package on a distribution that uses xinetd, it may have installed a file called /etc/xinetd.d/amanda to handle this server. If you use xinetd, and this file isn't present, you'll have to create it:

service amanda {    socket_type  = dgram    protocol     = udp    wait         = yes    user         = amanda    group        = disk    server       = /usr/lib/amanda/amandad    disable      = no }

As with the servers that are run on the AMANDA backup server computer, this one may need modification for your system. In particular, the user and group items may need adjustment. Be sure the specified user and group exist and have the necessary permissions to access the files you want backed up on the system. In practice, it's sometimes necessary to run the server as root, particularly if you want to back up files that only root may read. Even if your distribution provides a file to handle this server, you should check it and set disable = no; the default usually sets this value at yes, disabling the server.

If you use inetd as your super server, you must create an /etc/inetd.conf entry for amandad:

amanda  dgram  udp  wait  amanda.disk  amandad  amandad

The server run on the AMANDA backup client, like all servers, is a potential security risk, particularly if it's run as root. A miscreant who manages to access the server can read files from the computer, potentially including sensitive files such as password databases. Be sure the port used by the server (UDP port 10080) is well protected by firewall rules.

You must also ensure that the server's port is defined in /etc/services:

amanda  10080/udp

As a security measure, amandad uses an authorization file, .amandahosts, which is located in the home directory of the user who runs the server. This file contains the hostname of the backup server and the username of the user who runs the backup software on that system:

buserver.example.org amanda

The amandad server refuses to interact with amandad clients (that is, backup server systems) other than the one specified in this file. AMANDA doesn't use passwords for authentication, though.

Once all these features are set up, you should restart your super server. On most distributions, this can be done using SysV startup scripts, as in /etc/init.d/xinetd restart. Consult distribution-specific documentation for details.

14.4.4. Windows AMANDA Client Configuration

Because AMANDA uses SMB/CIFS to back up Windows systems, you needn't install or configure any special AMANDA software on these systems. Instead, configure them as you would for an SMB/CIFS backup using smbclient, as described earlier. Be sure to set the password for the backup user or share to the value you've set in the AMANDA backup server's /etc/amandapass file.

14.4.5. Backing Up and Restoring Data with AMANDA

To run a backup via AMANDA, use the amdump command. This command has the following syntax:

amdump config [ host [ disk ] ]

Normally, you just pass it a config name, which should match one of the subdirectory names in /etc/amanda. The amdump program then performs part of a network backup. The tool scans your configuration files to determine how many systems and disks it should back up over the course of a dump cycle. It can then perform an appropriate fraction of the full backup, the assumption being that the run you perform with this command is a regularly scheduled one. Of course, you must insert one of the tapes you prepared for this backup configuration in the tape drive before you issue this backup command.

Normally, you call amdump from cron. For instance, you might use a crontab entry like this to run amdump once every weeknight:

00 21 * * 1-5 /usr/sbin/amdump

You enter this line in the ~/crontab file for the user who you want to perform the backup, then type crontab -u user /home/user/crontab as root, where user is the username in question. The result is that cron will run amdump at 21:00 (9:00 P.M.) every weekday (1-5 in the final date field corresponds to Monday through Friday). Depending on your network bandwidth, tape capacity, and so on, each run can take anywhere from a few minutes to several hours to complete. After each run, AMANDA will email a report of its activities to the address specified with the mailto option in amanda.conf, so you can use that information to verify AMANDA's correct operation.

Restoring from an AMANDA backup requires special tools on the backup client. (For Windows backup clients, though, you perform these steps on the backup server system.) In particular, the amrecover tool enables you to browse the backup database maintained by the backup server. This tool presents its own amrecover> prompt and accepts commands you type. You can select files to recover and then extract them all from the backup with a single command. Specific commands you're likely to use include:

sethost hostname

Sets the name of the computer whose files you want to restore. The default is the localhost.

setdisk diskname

Sets the name of the disk on which the files you want to restore were originally held. It must match a name set in disklist.

listdisk diskname

Lists the contents of a disk.

setmode mode

Tells amrecover how to extract files for SMB/CIFS operations. Setting mode to smb causes shares to be extracted directly to the SMB/CIFS backup client computer; setting mode to tar causes files to be extracted to the local system.

mode

Displays the mode for extracting SMB/CIFS shares.

add items

Adds the specified items (files or directories) to a restore set.

extract

Begins the extraction process. To do any good, you must have added files to the restore set first. The tool prompts you to insert particular backup tapes, then recovers the data from those tapes.

In addition to these commands, amrecover accepts several more. Some of these, such as cd and ls, are similar to commands in bash or other common Linux shells; they enable you to move around the directories in the backup set and view files. Consult the amrecover manpage for more information.

As with local restores using tar or other tools, restores using amrecover are simplest if the systems involved are in more-or-less functional condition. To perform a full restore, you must have an emergency system working, as described in Section 14.2.4. This system must have a working version of the AMANDA backup client software running.