The preceding sections have described fairly basic backup options and configurations. If your network hosts just a handful of computers, you may be satisfied to perform backups manually using these methods , or to write scripts to be run from cron jobs that perform backups on an automatic basis. For larger networks, though, more sophisticated tools are in order. That's the function of the Advanced Maryland Automatic Network Disk Archiver (AMANDA). This package glues together other network backup tools to help automate backups across small, mid- sized , or even large networks. The AMANDA Web page is http://www.amanda.org. You can obtain the software from there, or from the distributions that ship with it, such as Debian, Red Hat, Mandrake, and SuSE. WARNING
The Function of AMANDAAMANDA includes both backup server and backup client software. You install the server software on the backup server, and backup client soft ware on the backup clients . These programs communicate with each other using their own protocols; NFS, rshd , and the like are not used by AMANDA. (When AMANDA backs up Windows systems, though, it uses smbclient and the standard Windows SMB/CIFS server package, as described earlier.) In addition to functioning as a conduit for network connections, AMANDA serves as a scheduling tool. It's often helpful, or even necessary, to carefully schedule different types of backups, particularly in large networks. Specifically, you probably don't need to back up every file on every computer with every backup. Such a policy would consume an inordinate amount of network bandwidth, even if the backups were scheduled to start in off hours ”the backup might not complete for days, depending on the network size . When using simple tools like tar run from cron jobs, it's common to use the --listed-incremental option, or its equivalent in other packages, to minimize the impact of backups. AMANDA can help manage network backup bandwidth by keeping track of which computers have been backed up at any given time, and whether they've received full or incremental backups. AMANDA can then schedule computers for appropriate backup types on specific days of a multiday backup rotation. Like a Samba backup server that uses processed backups, AMANDA normally functions by first copying data from the backup clients to the backup server's hard disk, and then copying those files to tape. (You can configure AMANDA to send data directly to tape, but such a configuration is likely to be slower than the normal configuration.) Therefore, an AMANDA server works best when it has a large hard disk ”large enough for at least one day's backups plus the normal system software. Having double the normal day's backup capacity allows you to dump one backup to tape while retrieving another backup set from the network. AMANDA can function with less than this amount of free disk space, but it will then have to perform a single backup in chunks . For instance, with 1GB of free space, AMANDA might grab 1GB of data from backup clients, write that data to tape, then fetch another 1GB of data, and so on. Configuring Clients for AMANDAAMANDA uses a server-initiated backup strategy, so the AMANDA clients need to run server software. For Linux and UNIX clients, this software ships with AMANDA, and is known as amandad . It's normally run from a super server. An appropriate /etc/inetd.conf file entry to launch this server resembles the following: amanda dgram udp wait amanda amandad amandad You may need to add an explicit path to the amandad executable for your system. If your distribution uses xinetd rather than inetd , you'll need to adjust this entry for xinetd , as discussed in Chapter 4. This entry runs the amandad server as the user amanda , which must exist on the computer; you can change this to suit your own needs. NOTE
For the super server configuration to work, your /etc/services file must contain an entry for the amanda service. A suitable entry looks like this: amanda 10080/udp After creating appropriate super server and /etc/services entries, you should restart your super server to make the AMANDA backup client software available to the backup server. The rest of the configuration for your client occurs on the backup server computer. NOTE
The backup client requires an authorization file, called .amandahosts , to be stored in the home directory of the AMANDA user's home directory. This file should contain the fully qualified domain name of the backup server and the name of the backup user on that system, separated by a space or tab. For instance, the following file allows amanda on the buserver.threeroomco.com backup server to perform backups: buserver.threeroomco.com amanda As noted earlier, AMANDA uses the SMB/CIFS server on Windows systems to back up those computers. You can configure Windows computers as AMANDA backup clients as described earlier in "Sharing Files to Back Up." Configuring the AMANDA Backup ServerBecause the AMANDA backup server functions as a network client for normal backup operations, it doesn't need to run actual server software for these functions. AMANDA does support client-initiated restores , though, so the AMANDA package includes two server programs that run on the backup server. These allow clients to view packages available for restoration, and to initiate a restore operation. As with the server software run on backup clients, these programs are typically run from a super server. Appropriate /etc/inetd.conf entries look like this: amandaidx stream tcp nowait amanda amindexd amindexd amidxtape stream tcp nowait amanda amidxtaped amidxtaped As with the backup client software, you may need to add an explicit path to the executables, and of course if your system uses xinetd , you'll need to create appropriate configurations for that package, as discussed in Chapter 4. The matching /etc/services entries for these lines are as follows : amandaidx 10082/tcp amidxtape 10083/tcp The user who runs AMANDA, which is normally the same user specified in the super server configuration file for running the AMANDA servers, should have read-write access to the nonrewinding tape device file. Without this permission, AMANDA won't be able to access the tape to perform backups. Creating an AMANDA ConfigurationThe AMANDA package is controlled through the amanda.conf file, which may be located in a subdirectory of /etc , /usr/local/etc , or a similar location. Typically, AMANDA uses its own two-tiered subdirectory for its configuration file. This subdirectory should be readable only by the AMANDA user ( amanda in this example). The first tier of AMANDA's subdirectory is called amanda , and the second tier is named after the backup configuration. For instance, there might be a /usr/local/etc/amanda/Daily for routine daily backups and a /usr/local/etc/amanda/Archive for archival backups, each with its own configuration file. If you installed AMANDA from source code, you'll find a sample configuration file in the example subdirectory of the source package. Setting Basic OptionsThe amanda.conf file format consists of lines that contain keywords followed by one or more values. For instance, a line that tells AMANDA how long it can take to process an entire network backup might be: dumpcycle 4 weeks A few configuration options span multiple lines. These are surrounded by curly braces ( {} ), and define a set of related options. You can leave many configuration options at their default values. Some that you may want to adjust include the following:
In addition to setting these basic values, you must also configure a holding area for data. This is achieved with the holdingdisk option, which takes a multi-line value consisting of several suboptions. These include directory (where the files are to be stored) and use (how much space you can use on the disk). If your backup server is short on disk space, you can set a negative value for chunksize . This will cause files larger than the absolute value of the chunksize to be sent directly to tape, bypassing the holding area. (Positive values of chunksize cause AMANDA to temporarily break up large files for storage in the holding area. This can be very useful if your holding disk filesystem or kernel doesn't support large files. For instance, 2.2. x kernels on x 86 CPUs only support 2GB files.) Preparing TapesAMANDA needs to see tapes that have been prelabeled as ones it may use. To do this, use the amlabel utility as the user who will run backups: $ amlabel Daily DailySet123 The Daily option to amlabel sets the subdirectory in which the matching amanda.conf file resides, so that amlabel can read the appropriate configuration options. The DailySet123 option is the label to give to the backup tape. This value should match the regular expression set with the labelstr option in amanda.conf , or AMANDA won't be able to use the tape. In most cases, AMANDA will back up a network to a set of tapes, so you'll need to label several tapes. You may want to develop some naming scheme for these tapes to help you differentiate among them. Defining Dump TypesNear the end of the sample amanda.conf file are a number of dumptype definitions. These specify how a given client, or a single filesystem on the client, is to be backed up. Features you can set in these definitions include:
There are other options you can set in a dump type definition. Some of these are the same as those set in earlier sections of the file, such as dumpcycle . Others are described in the amanda man page. Most dump type definitions begin with the name of another definition. This sets a series of values based on that earlier definition. You can use this to set default values. For instance, the default amanda.conf file uses a definition called global that's included in other definitions. Keep in mind that a single backup may use multiple dump types. For instance, you might back up critical system files without using compression, but compress data in less important directories. Similarly, you might use dump to back up ext2fs partitions, but tar to back up ReiserFS partitions. Defining a Backup SetThe amanda.conf file includes many important backup options, but it doesn't specify the names of backup client systems or the directories to be backed up on those clients. This is the job of the disklist file, which resides in the same directory as amanda.conf . The AMANDA source ships with a sample disklist file, but of course yours will be very different from this sample. The disklist file consists of a series of lines, each of which contains three fields: The hostname of the backup client, the area to be backed up, and the dump type to be used in backing up that area. The area to be backed up may be specified as a device filename (such as /dev/hda2 or simply hda2 ) or as a mount point (such as /home ). This file may also include comments, which are preceded by pound signs ( # ). Listing 17.2 shows a simple disklist file. Listing 17.2 A sample disklist file# Back up the backup server itself buserver.threeroomco.com / root-tar buserver.threeroomco.com /var user-tar buserver.threeroomco.com /hold holding-disk # Back up a Linux or UNIX client buclient.threeroomco.com / root-tar buclient.threeroomco.com /home user-tar # Back up a Windows client buserver.threeroomco.com //WINPC/DRIVEC user-tar Most of these entries should be self-explanatory. You might or might not use the default dump types, but if you do they're likely to include the ones shown in Listing 17.2. The /hold partition on buserver.threeroomco.com is the AMANDA holding area. This dump type includes the holdingdisk no option to prevent an attempt to use this area to back itself up. If this partition held nothing but holding area files, you might skip it entirely. The Windows client is backed up by specifying a Linux or UNIX system on which Samba is installed and working, and listing the NetBIOS name ( WINPC ) and share name ( DRIVEC ) of the Windows client to be backed up. Listing 17.2 uses the backup server itself as the Samba system, but you can use another system if you prefer. (Using the backup server reduces unnecessary network traffic, though.) The Windows system's drive need not be mounted to be backed up; AMANDA calls on the Samba system to use smbclient to do the job. Essentially, the Samba system uses smbclient much like a regular backup client uses tar or dump . To work, you must create a file called /etc/amandapass on the Samba system. Place the Windows share name followed by the password in this file. AMANDA sends SAMBA as the username, so if you back up Windows NT, 2000, or XP systems, those systems must have such a user defined. You can change the default username by using the --with-samba-user option to configure when building AMANDA. Running an AMANDA BackupTo run an AMANDA backup, you use the amdump program on the backup server computer. Type the program name, followed by the backup set name (that is, the name of the directory in which the configuration files are stored). For instance, you might type amdump Daily . Of course, you must first insert an appropriate backup tape that you've already prepared with amlabel , as described earlier, in the section "Preparing Tapes." AMANDA will review the areas that need to be backed up and perform an appropriate backup. This backup might not process every computer on the network, or even all of a single computer. Depending upon settings for configuration options like dumpcycle and the capacity settings in your tape type definition, AMANDA may back up just some computers, or perform partial backups rather than full backups. Assuming you haven't created a dump cycle that's too short, though, AMANDA will back up your entire network over the course of that cycle. Of course, you probably don't want to run amdump manually. It's best to run it in a cron job, probably at some time when your network isn't being heavily used, such as late at night. You should try to ensure that the backup clients will be available at these times, though. Many users are used to shutting off their computers when they leave work, so you may need to break them of such habits. When AMANDA finishes its backup, it sends an e-mail report of its activities to the addresses specified using the mailto option in amanda.conf . You can examine this report to spot any problems, such as computers that weren't accessible or a tape that filled up unexpectedly. |