« Previous 1 2 3 4 Next »
Network backups with Amanda
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.
Listing 1
amanda.conf Example
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
.
Listing 2
Settings for xinetd
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 }
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)