Section 4.2. Configuring Amanda

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.