Enjoy Fast Network Backups & Restores With Amanda, Part 2

Wednesday Jul 31st 2002 by Carla Schroder

Last week Carla Schroder introduced Amanda, a fast and stable network-based backup tool. This week she examines the basics of installation, configuration, and maintenance of this powerful tool.

Amanda: Reliable, Fast Network Backup & Restore part 2 by Carla Schroder

Installing and configuring Amanda is rather complex. The payoff is a stable, reliable backup that needs little attention. There are many options, depending on your network architecture and backup policies. If you're already familiar with network tape backups and stackers, you'll feel right at home. If not, expect to spend a few weeks getting the hang of it.

This is by no means a complete tutorial, that would take several more articles. This should fill in the gaps in the documentation, I learned a lot of this the hard way.

Get the latest and greatest tarball from amanda.org. While you're there, check the patches page. I don't recommend installing from RPM or from your distribution CD, unless your distribution comes with good documentation, because it will install differently, possibly even weirdly. If Amanda is already installed from an RPM, remove it. (I'm running it on a Red Hat Linux box, Amanda will run on any UNIX.)

Sanity-saving hint: To make finding files easier when you're making a lot of changes, manually update the locate database periodically:

# updatedb

Now unpack the tarball into /usr/src, which is the proper place to store sources. This step is essential: find docs/install, docs/SYSTEM.NOTES, and README. Read them all the way through before you touch a thing.

Amanda runs as a user with limited privileges, so we must create a user and a group. Create user 'amanda', group is 'backup'. User 'amanda' also needs to belong to the 'disk' group, so that it has read access to all files. 'amanda' needs a shell account and a /home directory.

Now run configure, as root. Several options need to be given, there is no generic installation. example/config.site explains all the options in detail. There are two ways to configure Amanda: use command-line options, or edit and use the config.site file. The latter is a good option for a complex configuration. This is the simplest install possible, Amanda must have these options set or it will not install:

# ./config \
--with-user=amanda \
--with-group=backup \

This is what I do on my system:

# ./config \
--with-user=amanda \
--with-group=backup \
--with-gnutar=/bin/tar \
--with-tape-device=/dev/ht0 \

# note: of course your own tape drive is specified here
--with-configdir=/etc/amanda \
--with-config=daily \

If you're backing up Samba clients, add

--with-smbclient=[path to smbclient]

Set back and relax while config fills your screen with row after row of exciting commentary. Then run

# make
# make install

For a complete, sparkling clean do-over:

# make distclean
# ./configure ...
# make
# make install

Add these lines to /etc/services on the server and the clients:

amanda 10080/udp
amandaidx 10082/tcp
amidxtape 10083/tcp

Create a directory to hold config files:

# mkdir /etc/amanda

User 'amanda' should own this directory and its contents:

# chown -R amanda.backup /etc/amanda

Now we need a place to store logs and indexes. Be sure this agrees with amanda.conf. Yes, I agree, the Amanda installation really could have done a lot of this:

# mkdir /etc/amanda/daily
# chown -R amanda.backup /etc/amanda/daily

Copy amanda.conf and disklist from the /example directory to /etc/amanda/daily. These are the two config files you will use the most.

Edit /etc/inetd.conf. Verify the filepaths, this is what works on my system:

-amanda dgram udp wait amanda /usr/sbin/tcpd /usr/local/libexec/amandad
-amandaidx stream tcp nowait amanda /usr/sbin/tcpd /usr/local/amanda/libexec/amindexd
-amidxtape stream tcp nowait amanda /usr/sbin/tcpd

Restart inetd:

# killall -HUP inetd

Holding Disk
This is a vital component. A dedicated hard drive is best, a partition next best, a file is OK. Running Amanda without a holding disk is possible, and pointless. Ideally it is large enough to hold two complete dumps.

# mkdir [path]/dumps
# chown amanda.backup [path]/dumps/
chmod 660 [path]/dumps

Label Tapes
Tapes must be labeled before use, using what else, amlabel. Do this as user 'amanda':

$ amlabel Daily Daily001

Now create an .amandahosts file in /home/amanda, on both the server and clients. This verifies access rights. Then protect it:

# chown amanda.backup /home/amanda/.amandahosts
# chmod 600 /home/amanda/.amandahosts

On the server, this contains a list of all the approved clients:

node1.mydomain.com root
node2.mydomain.com root
node3.mydomain.com root

The client's /home/amanda/.amandahosts file will look like this:

backup.server01.com amanda

Unix Client
Install from the same sources as the server. Create user 'amanda', belonging to groups 'backup' and 'disk', just like on the server. Do not give the client amanda a shell account.

Client configuration options are the same as the server, except add

--without-server \
--with-debugging \
--with-tape-server=backup.server01.com \
use your own server name!
--with-index-server=backup.server01.com \

Windows Clients
If you're running a mixed network, I shall assume Samba is already up and running. (Yeah, I know what they say about assume...) Set the host name to the name of the UNIX machine running Samba, and the area to be backed up to the Windows share name. There is a native Win32 client, I find it easier to use Samba.

And now, the moment you've been waiting for: configuring amanda.conf itself. I refer you to John R. Jackson's excellent book "UNIX Backup and Recovery", which contains a chapter just for Amanda. He has kindly posted it online at backupcentral.com. Same goes for disklist. Here are some sample lines from my disklist file:

# xena
xena.mydomain.com /home always-full
xena.mydomain.com /etc high-tar

# gabrielle
gabrielle.mydomain.com /home high-tar
gabrielle.mydomain.com /opt/shared high-tar

Restoring Files
Despite your heroic efforts to keep your system running like a Swiss watch, things happen. Durned users and stuff. Files are not user-restorable, for security reasons. Log in from the client machine and run amrestore. It presents an FTP-style directory of backed-up files.

Testing & Monitoring
amcheck is a nice little utility that tests all sorts of useful things, like file permissions, and host availability. File permissions can drive you batty, but for security they are extremely important. Amanda is chock-full of useful logs. For me the most troublesome part was continually running into files and directories that didn't exist, because Amanda does not create them. The other major problem area is networking issues. The network has to work right for Amanda to work right. Once it's up and running, it just goes and goes. Amanda is light on hand-holding, heavy-duty on performance.

Using Amanda, by John R. Jackson
Win32 Client

» See All Articles by Columnist Carla Shroder

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved