UNIX System Administration Handbook - Evi Nemeth [121]
Before running configure, run configure --help to see the complete list of options. In addition to deciding where the software should be installed, you must decide what user and group Amanda should run as. For each partition you intend to back up with dump, the corresponding raw device needs to be readable by this user. Often, you can handle access by chgrping the device files to a specially created group and setting Amanda to run as that group.
After running configure, run make and make install to complete the installation.
Every Amanda client needs to have access to the Amanda binaries. However, it’s not a good idea to have every client access the binaries through NFS, since there are times at which all the clients will need to run simultaneously (in particular, at the beginning of the backup procedure, when Amanda asks the clients to estimate their dump sizes). It’s best to install the binaries on each client’s local disks, usually somewhere under /usr/local.
The following programs should be installed on every client. They should never be run by hand.
amandad
handles all communication between the client and the central server; runs all the other client programs.
selfcheck
checks that the client is set up for Amanda: has correct device permissions, can find gzip, can write to /etc/dumpdates, etc.
sendbackup
performs the backups.
sendsize
estimates backup sizes at different dump levels.
Client machines need some other configuration as well. Both /etc/inetd.conf and /etc/services need to have a new line added for Amanda. Each device that you want to back up must be readable by Amanda’s group, and the /etc/dumpdates file must be writable by this group as well. Once you think everything has been set up correctly, use amcheck to verify the configuration.
The appropriate line for the inetd.conf file is shown below (assuming you choose “amanda” as the Amanda user and group when you installed the software).
amanda dgram udp wait amanda /usr/local/sbin/amandad amandad
This line can be used on both server and client. You may wish to further protect the backup system by calling Wietse Venema’s TCP wrappers package from inetd.conf; see page 666 for more information.
Here is the line for /etc/services:
amanda 10080/udp
A list of the Amanda server commands follows. Most take a command-line argument that tells them which Amanda configuration to use.
amdump does the nightly dumps; usually run by cron.
amflush flushes the holding disk to tape if there were problems.
amcleanup cleans up if the master host crashed during dumps.
amrestore handles restore operations from Amanda dumps.
amlabel writes Amanda labels on tape; used to avoid mistakes with overwriting wrong tapes, etc.
amadmin finds the right tape to restore from and performs various other administrative chores.
amcheck verifies that you are using the correct (expected) tape, that there is enough free space on the holding disk, and that client hosts are set up properly.
amtape manages stackers and tape changers.
amplot draws graphs of Amanda activity (e.g., holding disk and network usage) for each dump run.
Each configuration is kept in a separate directory and needs the files amanda.conf and disklist. The amanda.conf file specifies the server’s general configuration, and the disklist file specifies which clients and filesystems to back up. These files live only on the server.
The amanda.conf file
amanda.conf is quite a large file, so we discuss it in four logical pieces: local information, dump strategy, resource parameters, and dump type definitions. These pieces are purely our invention; neither Amanda nor the Amanda documentation distinguishes the parts of the amanda.conf file in this way.
The file format is fairly self-explanatory, so we present it in the form of a long example with commentary on each section. We begin with the local information section, which identifies