Section 4.2. Configuring Amanda

4.2. Configuring Amanda

Now let's take a look at how to configure Amanda backup. Detailed instructions about how to install and configure the Amanda client and server are available from http://wiki.zmanda.com. Here we provide a configuration roadmap. The preferred way to install Amanda is from RPMs found at http://www.zmanda.com, but if you want to compile from source, this section presents the basic procedures for installing the client and the server.

While one machine can be both a client and a server, there is no need to perform both procedures; installing the server normally installs the client.

To compile the Amanda client from source:

1. Create an amandabackup user in the disk group. This user must be the same as the backup user.

2. Unpack, compile, and install Amanda from the source archive. Specify configure options for a client-only compile, and install.

3. Add Amanda-related entries to /etc/services and the /etc/xinetd.d directory, and restart xinetd.

4. Specify which servers are allowed to connect by editing the .amandahosts file to enable authentication between client and server.

To install the Amanda server, you can also use RPMs. If you want to compile the server from source:

1. Create an amandabackup user in the disk group. The backup user should belong to the user group that has read and write access to the media.

2. Unpack, compile, and install from the source archive. Specify options for a client-and-server install.

3. Add Amanda-related entries to the /etc/xinetd.d directory, and restart xinetd.

Once the server is installed, configure the Amanda server:

1. Create the Amanda configuration directory /etc/amanda/<config name> (in case you use Zmanda packages).

2. Copy a sample of amanda.conf into /etc/amanda/<config name>.

3. Create a disklist file in /etc/amanda/<config name>.

4. Edit the .amandahosts file to enable authentication between client and server.

5. Edit configuration files amanda.conf and disklist.

6. Add client configuration to the disklist file.

7. Set up the device (create device nodes or directories) if you are using virtual tapes.

8. Label the media (tapes or vtapes) using amlabel.

9. Configure a cron job to schedule Amanda backup runs.

10. Run amcheck to verify that there are no problems with configuration, client/server communications, the holding disk, or the tape.

Figure 4-5 shows the configuration files for our sample network.

Figure 4-5. Amanda configuration files

The most important file for configuring Amanda setup is amanda.conf. The example file is quite large (more than 700 lines, which is why we don't include an example here; see http://wiki.zmanda.com for details), but fairly self-explanatory. This file defines how you do your backups, using settings that include:

• Local settings, such as name of your organization, email address to send backup completion report and warnings, and location of Amanda directories

• Device and network settings, such as names of your tape devices, tape type definitions, tape changer script, tape labeling template, and network bandwidth for Amanda to use

• Backup policy settings such as dump cycle, specifics about incremental backups, number of backup runs per dump cycle, and number of tapes in rotation

• Holding disk locations with capacities available to Amanda

• Instructions for how to perform backups, such as whether to use dump or GNU tar and details about indexing data, encryption, and compression

The disklist file specifies what to back up. For example, to back up the /home directories for clients Iron and Copper in Figure 4-5 requires the following disk list entries (DLEs):

# hostname diskname dumptype  Copper /home1 stable Copper /home2 stable Iron   /home3 normal Iron   /home4 normal

Dumptypes are defined in the amanda.conf file. They specify backup-related parameters, such as whether to compress the backups, whether to record backup results in / etc/dumpdates, the disk's relative priority, and exclude lists. Here are sample definitions for the dumptypes normal and stable that we used for Copper and Iron entries in the disklist file:

define dumptype  normal {  comment "gnutar backup" holdingdisk yes # (on by default) index yes program "GNUTAR" priority medium     } define dumptype  stable {  comment "ufsdump backup" holdingdisk yes # (on by default) index yes program "DUMP" priority medium     }

Many parameters in amanda.conf have default values, but the wide variety of parameters available for editing gives you full control over your backup environment.

A new Amanda user should plan on a learning curve of about two to four weeks before having a full production backup. It does not mean that a novice user will spend the whole month studying the Amanda wiki and reading the source code. As a matter of fact, it takes less than 15 minutes to configure an Amanda server with two Linux clients and one Windows client and to start a test backup. A white paper available at http://amanda.zmanda.com/quick-backup-setup.html provides detailed information about the "Start Amanda backup in 15 minutes" benchmark. However, you should plan to allocate some time to get comfortable with Amanda functionality and to test your restores several times before going into production. For large sites, it is a good idea to add one or two clients every day until all clients are protected by Amanda.

So far, we have described the most typical situation: an Amanda client configured on the system to be protected. However, a system administrator may decide to mount a filesystem via NFS or Samba on the Amanda server and have the Amanda client running on the server back up these networked filesystems.

We All Make Mistakes

I had just started using Amanda to back up the main server at a small web shop. I was feeling overconfident and wanted to listen to CDs on the server, so I tried to connect the audio cable of the CD player to the sound card of the machinewithout shutting down. I got the CD connected but happened to bump the SCSI cable between the three RAID5 disks and the RAID controller. This was the backup server, so when the RAID card refused to play, and the server wouldn't boot, I was looking at a bare-metal recovery of the backup server. Doh!

Fortunately, the folks who built the server, VALinux, were able to put me in touch with an engineer of theirs who knew the voodoo to tell the RAID card to ignore the fact that the disks were in an unknown state and to just bring them back online.

I've since had similar situations with a different RAID card that refused to play due to power loss during boot. That time I had to drive a very long way just to get the floppy with the RAID software and docs on it.

Moral 1: Yes, even you can make mistakes.

Moral 2: Keep your RAID docs and media with your RAID card.

Jason in California