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 servers—both 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.

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.

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

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:

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.

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.

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:

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

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.