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:
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:
This is what I do on my system:
# note: of course your own tape drive is specified here
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.
# make install
For a complete, sparkling clean do-over:
# make distclean
# ./configure …
# make install
Add these lines to /etc/services on the server and the clients:
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
# killall -HUP inetd
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
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:
The client’s /home/amanda/.amandahosts file will look like this:
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
–with-tape-server=backup.server01.com use your own server name!
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.mydomain.com /home always-full
xena.mydomain.com /etc high-tar
gabrielle.mydomain.com /home high-tar
gabrielle.mydomain.com /opt/shared high-tar
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.