Configuring Amanda for Network Backups
Using Amanda (the Advanced Maryland Automatic Network Disk Archiver), you can use a single large-capacity tape drive on a server to back up files from multiple computers over a network. The Amanda package includes a variety of commands. The online man page for Amanda describes the commands as shown in Table 13-7.
| Command | Description |
|---|---|
| amdump | Do automatic Amanda backups. This command is normally run by cron on a computer called the tape server host and requests backups of file systems located on backup clients. amdump backs up all disks in the disklist file to tape or, if there is a problem, to a special holding disk. After all backups are done, amdump sends mail reporting failures and successes. |
| amflush | Flush backups from the holding disk to tape. amflush is used after amdump has reported it could not write backups to tape. When this happens, backups stay in the holding disk. After the tape problem is corrected, run amflush to write backups from the holding disk to the tape. |
| amcleanup | Clean up after an interrupted amdump. This command is only needed if amdump was unable to complete for some reason, usually because the tape server host crashed while amdump was running. |
| amrecover | Provide an interactive interface to browse the Amanda index files and select which tapes to recover files from. amrecover can also run amrestore and the system restore program (such as tar) sometimes. |
| amrestore | Read an Amanda tape, searching for requested backups. amrestore is suitable for everything from interactive restores of single files to a full restore of all partitions on a failed disk. |
| amlabel | Write an Amanda format label onto a tape. All Amanda tapes must be labeled with amlabel. amdump and amflush will not write to an unlabeled tape. |
| amcheck | Verify the correct tape is in the tape drive and that all file systems on all backup client systems are ready to be backed up. Can optionally be run by cron before amdump, so someone will get mail warning that backups will fail unless corrective action is taken. |
| amadmin | Take care of administrative tasks, such as finding out which tapes are needed to restore a file system, forcing hosts to do full backups of selected disks, and looking at schedule balance information. |
| amtape | Take care of tape changer control operations, such as loading particular tapes, ejecting tapes, and scanning the tape rack. |
| amverify | Check Amanda backup tapes for errors (GNU tar format backups only). |
| amrmtape | Delete a tape from the tape list and from the Amanda database. |
| amstatus | Give the status of a running amdump. |
The amdump command is the one that you will use the most, but before you can get started, you need to configure a few things on both the backup server (the system with the tape drive) and the backup clients (the systems being backed up).
Creating Amanda directories
You need to create some directories to hold the Amanda configuration files and to provide a location to write Amanda log files. The configuration files go in the /etc/amanda directory, and the log files go in /var/lib/amanda. In both cases, you should log in as the amanda user and create subdirectories within those directories, one subdirectory for each backup schedule that you intend to run and an index file, as shown in the following example.
| Note | For security reasons, you should do all amanda administration as the amanda user. To do this, the root user can create a password for amanda by typing passwd amanda and entering the new password. A better alternative, however, might be to leave amanda without a password, then simply type su - amanda (as in the following example) to do amanda tasks as root user without an extra password. The rest of thisprocedure assumes that you are logged in as the amanda user. |
# su - amanda $ mkdir –p /var/lib/amanda/normal/index $ mkdir -p /etc/amanda/normal
For the purpose of this example, I have created only a normal backup configuration that backs up the data drives on several machines. You may also decide to create an upgradebackup configuration that backs up the operating system partitions. You could then run that backup before you perform any operating system upgrades.
You also need to specify a holding disk that Amanda can use to temporarily spool backups before it writes them to disk. This directory should have a lot of free space. I have a large /home partition on my server, so I created an Amanda directory there to use as a holding disk:
# mkdir /home/amanda # chmod 700 /home/amanda # chown amanda /home/amanda # chgrp disk /home/amanda
Creating the amanda.conf file
Next, as the amanda user, you must create two configuration files for Amanda and store them in the /etc/amanda/normal directory: amanda.conf and disklist. You can start by copying samples of these files from the /etc/amanda/DailySet1 directory as follows:
$ cd /etc/amanda/DailySet1 $ cp amanda.conf disklist /etc/amanda/normal
The amanda.conf file sets a variety of general configuration values, and the disklist file defines which machines and partitions to back up. The amanda.conf file can be rather complicated, but, fortunately, most of its values can be left at their default values. Here is a simplified amanda.conf file with some comments embedded in it to help explain things:
# # amanda.conf - sample Amanda configuration file. This started life as # the actual config file in use at CS.UMD.EDU. org "GLACI" # your organization name for reports mailto "amanda" # space separated list of operators at your site dumpuser "amanda" # the user to run dumps under # Specify tape device and/or tape changer. If you don't have a tape # changer, and you don't want to use more than one tape per run of # amdump, just comment out the definition of tpchanger. runtapes 1 # number of tapes to be used in a single # run of amdump tapedev "/dev/nrft0" # the no-rewind tape device to be used rawtapedev "/dev/rft0" # the raw device to be used (ftape only) tapetype HP-DAT # what kind of tape it is # (see tapetypes below) labelstr "^normal[0-9][0-9]*$" # label constraint all # tapes must match # Specify holding disks. These are used as a temporary # staging area for dumps before they are written to tape and # are recommended for most sites. holdingdisk hd1 { comment "main holding disk" directory "/home/amanda" # where the holding disk is use 290 Mb # how much space can we use on it chunksize -1 # size of chunk } # Note that, although the keyword below is infofile, it is # only so for historic reasons, since now it is supposed to # be a directory (unless you have selected some database # format other than the 'text' default) infofile "/usr/adm/amanda/normal/curinfo" # database DIRECTORY logdir "/usr/sdm/amanda/normal" # log directory indexdir "/usr/adm/amanda/normal/index" # index directory # tapetypes # Define the type of tape you use here, and use it in "tapetype" # above. Some typical types of tapes are included here. The # tapetype tells amanda how many MB will fit on the tape, how # big the filemarks are, and how fast the tape device is. define tapetype HP-DAT { comment "DAT tape drives" # data provided by Rob Browning <rlb@cs.utexas.edu> length 1930 mbytes filemark 111 kbytes speed 468 kbytes } # dumptypes # # These are referred to by the disklist file. define dumptype global { comment "Global definitions" # This is quite useful for setting global parameters, so you # don't have to type them everywhere. } define dumptype always-full { global comment "Full dump of this filesystem always" compress none priority high dumpcycle 0 } This example amanda.conf file was trimmed down from a larger example I copied from the /etc/amanda/DailySet1 directory. The example amanda.conf file provides additional information on the available configuration options. Also, the online man page for Amanda should be helpful (type man amanda to read it). You can find more instructions in the /usr/share/doc/amanda-server* directory. Generally, you have to do the following:
-
Modify the org name for reports.
-
Change the device names set for tapedev and rawtapedev to match your tape device.
-
Select a tape type entry that is appropriate for your tape drive.
-
Change the name of the directory specified in the holding disk section to match the directory you created earlier.
Creating a disklist file
You also must create a disklist file in the /etc/amanda/normal directory. This simply contains a list of the systems and disk partitions to back up. The qualifier always-full is included on each entry to tell Amanda what type of backup to perform. It means to use full, rather than incremental, backups.
# sample Amanda2 disklist file # # File format is: # # hostname diskdev dumptype [spindle [interface]] # # where the dumptypes are defined by you in amanda.conf. dexter hda5 always-full dexter hda6 always-full dexter hda7 always-full dexter hda8 always-full daffy hda5 always-full daffy hda6 always-full daffy hda7 always-full daffy hdb1 always-full daffy hdb2 always-full
This example file backs up two systems, dexter and daffy. The order of the systems and the partitions is selected so that the most important data is backed up first. This way, if a tape drive becomes full, you have still managed to back up the most important data.
Adding Amanda network services
Amanda is designed to perform backups over a network. The following amanda services are defined in the /etc/services file:
amanda 10080/udp amanda 10080/tcp amandaidx 10082/tcp amidxtape 10083/tcp
On the amanda server
To offer these services to the network in Fedora, you need to configure the xinetd daemon to listen for those services. You do this by enabling the amandaidx and amidxtape services by typing the following (as root user):
# chkconfig amidxtape on # chkconfig amandaidx on
This enables Amanda to accept requests from the client system and to start the backup process without any user intervention. You need to tell the xinetd daemon to reload the /etc/xinetd.d files before this change takes effect. You can do this by typing the following as root user:
# /etc/init.d/xinetd reload
On each amanda client
Next you need to configure the .amandahosts file in the /var/lib/amanda directory on each computer (client) that the amanda server will back up from. This file should contain the fully qualified host and domain name of any backup servers that will connect to this client. When you begin, only your localhost is defined in this file as your backup server. To add another computer as a backup server, type the following (replacing amandahost with the name of the backup server, while you are logged in as the amanda user):
$ echo amandahost >> /var/lib/amanda/.amandahosts
You also need to make sure that the amanda client daemon is configured to run on the client. You do this by enabling the amanda service by typing the following (as root user) :
# chkconfig amanda on
This enables the amanda client to communicate with the amanda server. You need to tell the xinetd daemon to reload the /etc/xinetd.d files before this change takes place. Do this by typing the following as root user:
# /etc/init.d/xinetd reload
Performing an Amanda backup
Now that everything is configured, you are ready to perform an Amanda backup. While logged in as root, type the following command:
# /usr/sbin/amdump normal
This runs the amdump command and tells it to read the configuration files it finds in the /etc/amanda/normal directory created earlier. It then works its way down the list of systems and partitions in the disklist file, backing up each partition in the order it occurs. The results of the amdump are written to the /var/lib/amanda/normal directory. Read the files you find there to check on the results of the backup. (See the previous section on how to create a disklist file to understand the process that amdump goes through.)
You can, of course, automate this process with cron. To create an amdump schedule similar to the regular dump schedule discussed in an earlier section, do the following. While logged in as root, enter the crontab command with the -e option:
# crontab -e
This opens the root crontab file in an editor. Add the following lines to the end of the file:
0 22 * * 0 /usr/sbin/amdump normal 0 22 * * 1 /usr/sbin/amdump incremental 0 22 * * 2 /usr/sbin/amdump incremental 0 22 * * 3 /usr/sbin/amdump incremental 0 22 * * 4 /usr/sbin/amdump incremental 0 22 * * 5 /usr/sbin/amdump incremental 0 22 * * 6 /usr/sbin/amdump incremental
Save and exit the file. The cron daemon will now run amdump at 10:00 p.m. (22:00 in military time) every day of the week. This example assumes that a second incremental configuration has been created. You can do this by creating a subdirectory named incremental under /etc/amanda and populating it with appropriately modified amanda.conf and disklist files. You must also create a subdirectory named incremental under /var/lib/amanda so that amanda has somewhere to write the logfiles for this configuration.
It may be a bit of work to get it all in place, but when you do, Amanda can make your network backups much easier to manage. It may be overkill for a small office, but in a large enterprise network situation, it enables Fedora Core to act as a powerful backup server.
EAN: 2147483647
Pages: 286