لطفا منتظر باشید ...
Using AMANDA
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
software from there, or from the distributions that ship with it, such as
Debian, Red Hat, Mandrake, and SuSE.WARNING
align=left border=0> AMANDA hard-codes some critical values in
its executables, so mixing binaries acquired from different distributions may
not work. If your environment includes multiple distributions, it may be best
to build the package from source yourself. Be sure to specify the same user
and group with the --with-user and --with-group options to configure on all your systems. You may want to create a special user and
group for AMANDA operations.
The Function of
AMANDA
AMANDA 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
hoursthe 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 disklarge 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 AMANDA
AMANDA 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
runs the amandad server as the user amanda , which must exist on the computer;
you can change this to suit your own needs.NOTE
align=left border=0> The AMANDA documentation describes
launching the package using a special username and group dedicated to
backups, such as amanda , but this approach often doesn't work. You may need to launch amandad as root to get
it to work.
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
align=left border=0> The AMANDA backup server must be backed up
along with other systems on the network. For this reason, the backup server
itself is usually configured as a backup client, as well as being configured
as the backup server.
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 "
Configuring the AMANDA Backup Server
Because 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
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 Configuration
The 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 Options
The 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: org This sets the name of your organization, as used in reports that
AMANDA generates. It's largely cosmetic, but you might as well set it to
something reasonable. mailto
AMANDA e-mails reports on its activities to the addresses listed in this
option. You may specify multiple addresses, separated by spaces. dumpuser
This is the username that runs the backup. This defaults to the value specified
with the --with-user option to configure when you built AMANDA. dumpcycle
This is the number of days in a dump cycle (a complete network backup). runspercycle
AMANDA can run every day, multiple times per day, or once every several days,
as you wish, by setting this parameter. For instance, if dumpcycle is set to four weeks, setting runspercycle to 20 causes AMANDA to compute what to back
up based on one run per weekday. Setting this value to 4 causes AMANDA to assume it will be run
just once a week. (Note that AMANDA is actually run from cron jobs; these
settings just tell AMANDA what to expect, and
therefore how to plan its backups.) tapecycle
This sets the number of tapes used in a dump cycle. It's normally slightly
larger than runspercycle to
allow for tapes with errors. tapetype
You tell AMANDA what type of tape device you have so that the package can
compute how quickly it can back up data and other information. The middle of
the example amanda.conf file
defines several tape types, and you should set the tapetype option to one of these. If you don't see a
suitable tape type, you'll have to create one. The most reliable way to do this
is to use the tapetype utility,
which is included with AMANDA but isn't built by default. Go to the tape-src subdirectory of the source
package and type make tapetype .
Then mount a scratch tape in the tape drive and
type ./tapetype -f /dev/tapedevice
(where tapedevice is your
device filename) to get a list of values for your drive. This operation will
probably take several hours, and will erase all the data on the tape. If your
tape drive supports hardware compression, you can probably multiply the length
value by 1.5 or 2, but if you back up data that's not easily compressed, such
multiplication may cause failures if the tape runs out of space. tapedev
This is the Linux device file for the nonrewinding
interface for your tape device. In most cases, it will be /dev/nst0 or /dev/nht0 . netusage
This is the maximum network bandwidth AMANDA can expect to achive. labelstr
This is a regular expression that AMANDA uses to assign names to backup tapes.
You'll have to prepare tapes with names based on this value, as described
shortly, in the section "
If your tape drive is a changer model, you must define its operation by
providing a changer file definition and a pointer to the changer device file.
Some example files are included in the example
directory of the source distribution. Log files AMANDA sets log file
locations with the infofile and logdir options. Similarly, index files
containing lists of files that have been backed up are set with the indexdir option. You might or might not
want to change these values, but you should definitely check them.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
Tapes
AMANDA 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 Types
Near 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: compress [client | server]
[best | fast | none] You can specify that compression be
performed on the backup client or the backup server, depending upon available
CPU and network resources. You can also set compression to be more efficient
but use more CPU time ( best ) or
be faster but less efficient ( fast ).
The none option explicitly
disables compression. exclude [list] "string"
AMANDA passes string to
the exclude or --exclude-from options to tar , depending on whether list is included as well. holdingdisk
boolean Set boolean to yes or no to
tell AMANDA to use a holding disk area or not. index boolean Set boolean to yes or no to
tell AMANDA whether to create an index of the files in the backup set. Without
an index, restores are much more tedious, but an index consumes disk space you
might prefer to devote to other purposes. kencrypt boolean You can tell AMANDA to
encrypt data sent across the network with Kerberos protocols with this option.
Setting boolean to yes requires that your network be
configured to use Kerberos, as described in
AMANDA may use either GNU tar or
the OS- and filesystem-specific dump
program to perform backups, and this is the option that sets which to use. The
default is usually dump (set by
a string of DUMP ), but tar may be selected by setting string to GNUTAR . (When backing up via Samba, the default is to use tar .) skip-incr boolean If boolean is true, filesystems that use
this dump type will be skipped during incremental backups.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 Set
The 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 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
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.
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 Backup
To 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 "
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.
