Auntie Amanda

Many Files and Directories

Amanda runs with a user account specially set up for the purpose. Before you can assign a backup job to Amanda, you need to know this user's name. By default, the name will be amanda and the group will be backup . (Some distributions use different names. On Debian and Ubuntu, e.g., the user is named backup .) The examples in this article use amanda as the user name.

Amanda versions before 3.3.9 have a vulnerability that lets this user execute arbitrary code with root privileges. A (manual) upgrade to version 3.3.9 is only necessary if you don't trust the Amanda user.

Amanda can be difficult to set up because of its numerous settings and configuration files. This article uses the simple example of backing up the /etc directory on the client machine client.example.com . The backup server is called server.example.com .

To launch Amanda, you need several directories on the server. First, make sure the directory /etc/amanda exists there. This directory must be owned by the Amanda user, which is the case with Ubuntu by default. If you need to create the directory, enter:

$ mkdir -p /etc/amanda
$ chown amanda /etc/amanda

If you want to store all the backups in the /amanda subdirectory on the server, let Amanda know by editing several configuration files, which are best grouped in a separate subdirectory below etc/amanda. The following example uses /etc/amanda/examples.

One configuration could look after backing up the home directories, and another could handle the less frequently performed backup of /etc. The name of the subdirectory is also the name of the configuration it holds. Both these directories must also belong to amanda:

$ mkdir -p /amanda /etc/amanda/examples
$ chown amanda /amanda /etc/amanda/examples

Amanda creates multiple files during the backup. In addition to the actual backups, you have, for example, the logs, all of which you could group below /amanda. However, it is better to create a separate subdirectory in each case. The log data would end up in /amanda/logs. Because these directories also need to belong to the amanda account, you might want to run the following command directly as the amanda user:

$ sudo -u amanda mkdir -p /amanda/vtapes/slot{1,2,3,4} /amanda/holding /amanda/state/{curinfo,log,index}

The backups end up in the directories /amanda/vtapes/slot1 to /amanda/vtapes/slot4 later on; /amanda/holding is the cache, /amanda/state/log is a dump for the logfiles, and the other two directories hold data created by Amanda.

Configuring the Server

Once all the directories exist, it is time to create a configuration. Listing 1 shows a simple example inspired by a tutorial in the Zmanda wiki [4]. The settings from Listing 1 belong in the /etc/amanda/examples/amanda.conf file. Like all other configuration files, Amanda needs access to them – ideally, you will want to create them directly while working as the amanda user.

01 org "An example"
02 infofile "/amanda/state/curinfo"
03 indexdir "/amanda/state/index"
04 logdir "/amanda/state/log"
05 dumpuser "amanda"
06 labelstr "MyData[0-9][0-9]"
07 autolabel "MyData%%" EMPTY VOLUME_ERROR
08 tpchanger "chg-disk:/amanda/vtapes"
09 tapecycle 4
10 dumpcycle 3 days
11 amrecover_changer "changer"
12 tapetype "EXAMPLE-TAPE"
13 define tapetype EXAMPLE-TAPE {
14     length 100 mbytes
15     filemark 4 kbytes
16 }
17 define dumptype simple-gnutar-tcp {
18     auth "bsdtcp"
19     program "GNUTAR"
20     compress client fast
21 }
22 holdingdisk hd1 {
23     directory "/amanda/holding"
24     use 50 mbytes
25     chunksize 1 mbyte
26 }

The first line beginning with org gives a description of the configuration. This description appears later in the subject line of any email notifications. Amanda stores its own data in infofile; the index for all the backups is stored in the indexdir directory, and all the logfiles are found in logdir. Amanda also creates the backups with the user account stated after dumpuser.

The following settings specify the location of the backups. Here is where you notice that Amanda was originally created for backups on tapes: Amanda refers to an archive containing the backup as the dumpfile, which is usually a simple TAR archive. Amanda saves the dumpfiles on volumes. A volume can be a tape, a DVD, or a subdirectory on the server.

Each volume stores a portion of the dumpfile and is given a label and a consecutive number. Based on the number, Amanda can reassemble the parts. Amanda automatically assigns the label based on the template stored below autolabel (line 7). Amanda later replaces the % with a consecutive number, which, in this case, is two digits. Based on the EMPTY and VOLUME_ERROR information, Amanda marks empty and incorrect volumes in the appropriate label. Generally the label must match the specifications in labelstr; only then will Amanda use the volume. This requirement prevents a tape inserted by mistake from causing problems.

The long string after tpchanger tells Amanda not to store the data on tapes but in the /amanda/vtapes directory on the hard disk (chg-disk). Amanda automatically distributes the backups across the subdirectories named slot1, slot2, and so on. From Amanda's perspective, each of the subdirectories is a separate (tape) drive or volume. tapecycle sets the number of active volumes. In Listing 1, the number of volumes is four (slot1 to slot4). Amanda only overwrites a volume if at least tapecycle - 1 volumes have been created and written to.

The number of days after which Amanda creates a complete backup follows dumpcycle. Thus, only incremental backups would be generated for three days in Listing 1. If you set the value to  , Amanda always creates a full backup. The next section sets the type and parameters of the tapes or the properties of the backup device. In Listing 1, each volume can hold 100MB of data. In the example, a maximum of 100MB are written to each of the slot1 to slot4 directories. If the backup is larger, Amanda distributes it across multiple volumes or tapes. Each type of tape is also given a unique name (in Listing 1, EXAMPLE-TAPE).

The section of Listing 1 following define dumptype (lines 17 to 21) determines how Amanda will create the backup. According to Listing 1, Amanda bundles all files with the tar program (see line 19 with program "GNUTAR") and compresses them on the client using a quick method (compress client fast). Then, the data flows via a TCP connection to the server (auth "bsdtcp"). Finally, these settings are saved as simple-gnutar-tcp. Because multiple clients can require different backup procedures (tar, for instance, is not available on some computers), you need to define several dumptype sections. The only important thing is that the names of the sections are different. A separate configuration file tells Amanda what dumptype to use for which client.

Amanda uses one or several holding disks as intermediate storage during the backup. The holdingdisk section (lines 22 to 26) specifies the key data for such a holding disk. In Listing 1, Amanda is allowed to cache data in the /amanda/holding directory, where it can use a maximum of 50MB space; any file in the /amanda/holding directory must not exceed a maximum of 1MB. You can add as many holdingdisk sections as you need to add more holding disks. Each holding disk must be given a unique name; the one in Listing 1 goes by the not very original name hd1. The Amanda developers recommend choosing the size of the holding disks to be larger than the backup of the largest partition of a client. If a terabyte partition weighs in at 500GB after compression, the holding disks need at least this amount of free space.

The amanda.conf file (Listing 1) defines where Amanda creates and stores backups. What Amanda actually saves is revealed in a second configuration file, /etc/amanda/ADMINexample/disklist. In this example, the disklist file contains only one line:

client.example.com /etc simple-gnutar-tcp

This line tells Amanda to extract all the files from the /etc subdirectory on the computer named client. The example.com file simply uses the tar command installed there (with the procedure defined in amanda.conf as simple-gnutar-tcp) to back up these files.

Establishing the Connection

In this example, the backup will use a TCP connection. For this connection to work, the amandad daemon must be running on both the client and the server. The daemon on the client fields the request for the backup, creates the backup, and then sends it back to the server via TCP. Conversely, the daemon waits for the server to send restore requests from a client. Launching amandad is the responsibility of the Internet super server, inetd or xinetd. If you have installed Amanda using your distribution's package manager, everything should be appropriately set up already. Otherwise, you just need to add the following additional line to both the client's and the server's /etc/inetd.conf file:

amanda stream tcp nowait backup /usr/lib/amanda/amandad amandad -auth=bsdtcp amdump amindexd amidxtaped

If you use xinetd, enter the settings from Listing 2 to the /etc/xinetd/amanda configuration file. In any case, you now only need to ensure that inetd or xinetd is running in the background. For more information and configuration examples for setting up inetd and xinetd, see the man page for amanda-auth.

01 service amanda
02 {
03              disable = no
04              flags = Ipv4
05              socket_type = stream
06              protocol = tcp
07              wait = no
08              user = backup
09              group = disk
10              groups = yes
11              server = /usr/lib/amanda/amandad
12              server_args = -auth=bsdtcp amdump amindexd amidxtaped
13 }