AMANDA(8)AMANDA(8)NAMEamanda - Advanced Maryland Automatic Network Disk Archiver
SYNOPSIS
amadmin config command [options]
amcheck [options] config
amcheckdb config
amcleanup config
amcrypt
amdd [options]
amdump config
amaespipe
amflush [-f] config
amgetconf [config] parameter
amlabel config label [slot�slot]
ammt [options]
amoverview config [options]
amplot [options] amdump-files
amrecover [config] [options]
amreport [config] [options]
amrestore [options] tapedevice [hostname�[diskname]]
amfetchdump [options] config [hostname�[diskname�[date�[level]]]]
amrmtape [options] config label
amstatus config [options]
amtape config command [options]
amtapetype [options]
amtoc [options] logfile
amverify config
amverifyrun config
DESCRIPTION
Amanda is the "Advanced Maryland Automatic Network Disk Archiver". This
manual page gives an overview of the Amanda commands and configuration
files for quick reference.
Here are all the Amanda commands. Each one has its own manual page. See
them for all the gory details.
amdump Take care of automatic Amanda backups. This is normally executed
by cron on a computer called the tape server host and requests
backups of file systems located on backupclients. Amdump backs
up all disks in the disklist file (discussed below) to tape or,
if there is a problem, to a special holdingdisk. After all back‐
ups are done, amdump sends mail reporting failures and suc‐
cesses.
amflush
Flush backups from the holding disk to tape. Amflush is used
after amdump has reported it could not write backups to tape for
some reason. When this happens, backups stay in the holding
disk. Run amflush after the tape problem is corrected to write
backups from the holding disk to 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
Provides an interactive interface to browse the Amanda index
files (backup image catalogues) and select which tapes to
recover files from. It can also run amrestore and a restore pro‐
gram (e.g. tar) to actually recover the files.
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.
amfetchdump
Performs Amanda tape restoration, similar to amrestore. Addi‐
tional capabilities include "hands-off" searching of multiple
tapes, automatic retrieval of specific dump files based on dump
logs, and assembly of tape-spanning split dump files.
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 (see TAPE MANAGEMENT below).
amcheck
Verify the correct tape is mounted and all file systems on all
backup client systems are ready to be backed up. Often run by
cron before amdump to generate a mail warning that backups might
fail unless corrective action is taken.
amadmin
Take care of administrative tasks like finding out which tapes
are needed to restore a filesystem, forcing hosts to do full
backups of selected disks and looking at schedule balance infor‐
mation.
amtape Take care of tape changer control operations like loading par‐
ticular tapes, ejecting tapes and scanning the tape storage
slots.
amverify
Check Amanda backup tapes for errors.
amrmtape
Delete a tape from the Amanda databases.
amstatus
Report the status of a running or completed amdump.
amoverview
Display a chart of hosts and file systems backed up every run.
amplot Generate utilization plots of Amanda runs for performance tun‐
ing.
amreport
Generate an Amanda summary E-mail report.
amtoc Generate table of content files for Amanda tapes.
amcheckdb
Verify every tape Amanda knows about is consistent in the data‐
base.
amgetconf
Look up parameters in the Amanda configuration file.
amtapetype
Generate a tapetype definition.
amaespipe
Wrapper program from aespipe (data encryption utility)
amcrypt
Reference encryption program for Amanda symmetric data encryp‐
tion
CONFIGURATION
There are three user-editable files that control the behavior of
Amanda.
The first is amanda.conf, the main configuration file. It contains
parameters to customize Amanda for the site. Refer to the
amanda.conf(5), manpage for details on Amanda configuration parameters.
Second is the disklist file, which lists hosts and disk partitions to
back up.
Third is the tapelist file, which lists tapes that are currently
active. These files are described in more detail in the following sec‐
tions.
All files are stored in individual configuration directories under
/usr/local/etc/amanda/. A site will often have more than one configura‐
tion. For example, it might have a normal configuration for everyday
backups and an archive configuration for infrequent full archival back‐
ups. The configuration files would be stored under directories
/usr/local/etc/amanda/normal/ and /usr/local/etc/amanda/archive/,
respectively. Part of the job of an Amanda administrator is to create,
populate and maintain these directories.
All log and database files generated by Amanda go in corresponding
directories somewhere. The exact location is controlled by entries in
amanda.conf. A typical location would be under /var/adm/amanda. For the
above example, the files might go in /var/adm/amanda/normal/ and
/var/adm/amanda/archive/.
As log files are no longer needed (no longer contain relevant informa‐
tion), Amanda cycles them out in various ways, depending on the type of
file.
Detailed information about amdump runs are stored in files named
amdump.NN where NN is a sequence number, with 1 being the most recent
file. Amdump rotates these files each run, keeping roughly the last
tapecycle (see below) worth of them.
The file used by amreport to generate the mail summary is named
log.YYYYMMDD.NN where YYYYMMDD is the datestamp of the start of the
amdump run and NN is a sequence number started at 0. At the end of each
amdump run, log files for runs whose tapes have been reused are renamed
into a subdirectory of the main log directory (see the logdir parameter
below) named oldlog. It is up to the Amanda administrator to remove
them from this directory when desired.
Index (backup image catalogue) files older than the full dump matching
the oldest backup image for a given client and disk are removed by
amdump at the end of each run.
DISKLIST FILE
The disklist file determines which disks will be backed up by Amanda.
The file usually contains one line per disk:
hostname diskname [diskdevice] dumptype [spindle [interface] ]
All pairs [ hostname diskname ] must be unique.
Lines starting with # are ignored, as are blank lines. The fields have
the following meanings:
hostname
The name of the host to be backed up. If diskdevice refers to a
PC share, this is the host Amanda will run the Samba smbclient
program on to back up the share.
diskname
The name of the disk (a label). In most case, you set your
diskname to the diskdevice and you don't set the diskdevice. If
you want multiple entries with the same diskdevice, you must set
a different diskname for each entry. It's the diskname that you
use on the commandline for any Amanda command. Look at the exam‐
ple/disklist file for example.
diskdevice
Default: same as diskname. The name of the disk device to be
backed up. It may be a full device name, a device name without
the /dev/ prefix, e.g. sd0a, or a mount point such as /usr.
It may also refer to a PC share by starting the name with two
(forward) slashes, e.g. //some-pc/home. In this case, the pro‐
gram option in the associated dumptype must be entered as GNU‐
TAR. It is the combination of the double slash disk name and
program GNUTAR in the dumptype that triggers the use of Samba.
dumptype
Refers to a dumptype defined in the amanda.conf file. Dumptypes
specify backup related parameters, such as whether to compress
the backups, whether to record backup results in /etc/dumpdates,
the disk's relative priority, etc.
spindle
Default: -1. A number used to balance backup load on a host.
Amanda will not run multiple backups at the same time on the
same spindle, unless the spindle number is -1, which means there
is no spindle restriction.
interface
Default: local. The name of a network interface definition in
the amanda.conf file, used to balance network load.
Instead of naming a dumptype, it is possible to define one in-line,
enclosing dumptype options within curly braces, one per line, just like
a dumptype definition in amanda.conf. Since pre-existing dumptypes are
valid option names, this syntax may be used to customize dumptypes for
particular disks.
A line break must follow the left curly bracket.
For instance, if a dumptype named normal is used for most disks, but
use of the holding disk needs to be disabled for the file system that
holds it, this would work instead of defining a new dumptype:
hostname diskname [ diskdevice ] {
normal
holdingdisk no
} [ spindle [ interface ] ]
TAPE MANAGEMENT
The tapelist file contains the list of tapes in active use. This file
is maintained entirely by Amanda and should not be created or edited
during normal operation. It contains lines of the form:
YYYYMMDD label flags
Where YYYYMMDD is the date the tape was written, label is a label for
the tape as written by amlabel and flags tell Amanda whether the tape
may be reused, etc (see the reuse options of amadmin).
Amdump and amflush will refuse to write to an unlabeled tape, or to a
labeled tape that is considered active. There must be more tapes in
active rotation (see the tapecycle option) than there are runs in the
backup cycle (see the dumpcycle option) to prevent overwriting a backup
image that would be needed to do a full recovery.
OUTPUT DRIVERS
The normal value for the tapedev parameter, or for what a tape changer
returns, is a full path name to a non-rewinding tape device, such as
/dev/nst0 or /dev/rmt/0mn or /dev/nst0.1 or whatever conventions the
operating system uses. Amanda provides additional application level
drivers that support non-traditional tape-simulations or features. To
access a specific output driver, set tapedev (or configure your changer
to return) a string of the form driver:driver-info where driver is one
of the supported drivers and driver-info is optional additional infor‐
mation needed by the driver.
The supported drivers are:
tape This is the default driver. The driver-info is the tape device
name. Entering
tapedev /dev/rmt/0mn
is really a short hand for
tapedev tape:/dev/rmt/0mn
null This driver throws away anything written to it and returns EOF
for any reads except a special case is made for reading a label,
in which case a "fake" value is returned that Amanda checks for
and allows through regardless of what you have set in labelstr.
The driver-info field is not used and may be left blank:
tapedev null:
The length value from the associated tapetype is used to limit
the amount of data written. When the limit is reached, the
driver will simulate end of tape.
Note
This driver should only be used for debugging and testing, and
probably only with the record option set to no..TP rait Redun‐
dant Array of Inexpensive (?) Tapes. Reads and writes tapes
mounted on multiple drives by spreading the data across N-1
drives and using the last drive for a checksum. See docs/RAIT
for more information.
The driver-info field describes the devices to use. Curly braces
indicate multiple replacements in the string. For instance:
tapedev rait:/dev/rmt/tps0d{4,5,6}n
would use the following devices:
/dev/rmt/tps0d4n/dev/rmt/tps0d5n/dev/rmt/tps0d6n
file This driver emulates a tape device with a set of files in a
directory. The driver-info field must be the name of an existing
directory. The driver will test for a subdirectory of that named
data and return offline until it is present. When present, the
driver uses two files in the data subdirectory for each tape
file. One contains the actual data. The other contains record
length information.
The driver uses a file named status in the file device directory
to hold driver status information, such as tape position. If not
present, the driver will create it as though the device is
rewound.
The length value from the associated tapetype is used to limit
the amount of data written. When the limit is reached, the
driver will simulate end of tape.
One way to use this driver with a real device such as a CD-
writer is to create a directory for the file device and one or
more other directories for the actual data. Create a symlink
named data in the file directory to one of the data directories.
Set the tapetype length to whatever the medium will hold.
When Amanda fills the file device, remove the symlink and
(optionally) create a new symlink to another data area. Use a CD
writer software package to burn the image from the first data
area.
To read the CD, mount it and create the data symlink in the file
device directory.
AUTHORIZATION
Amanda processes on the tape server host run as the dumpuser user
listed in amanda.conf. When they connect to a backup client, they do so
with an Amanda-specific protocol. They do not, for instance, use rsh or
ssh directly.
On the client side, the amandad daemon validates the connection using
one of several methods, depending on how it was compiled and on options
it is passed:
Even though
Amanda does not use rsh, it can use file.
This is essentially the same as
authentication except a different file, with almost the same
format, is used. This is the default mechanism built into
Amanda.
The format of the .amandahosts file is:
hostname [ username ]
If username is ommitted, it defaults to the user running aman‐
dad, i.e. the user listed in the inetd or xinetd configuration
file.
Kerberos
Amanda may use the Kerberos authentication system. Further
information is in the docs/KERBEROSfile that comes with an
Amanda distribution.
For Samba access, Amanda needs a file on the Samba server (which
may or may not also be the tape server) named /etc/amandapass
with share names, (clear text) passwords and (optional) domain
names, in that order, one per line, whitespace separated. By
default, the user used to connect to the PC is the same for all
PC's and is compiled into Amanda. It may be changed on a host by
host basis by listing it first in the password field followed by
a percent sign and then the password. For instance:
//some-pc/home normalpw
//another-pc/disk otheruser%otherpw.fi
With clear text passwords, this file should obviously be tightly protected. It only needs to be readable by the
Amanda-user on the Samba server.
You can find further information in the
docs/SAMBAfile that comes with an
Amanda
distribution.
HOST & DISK EXPRESSION
All host and disk arguments to programs are special expressions. The
command applies to all disks that match your arguments. This section
describes the matcher.
The matcher matches by word, each word is a glob expression, words are
separated by the separator '.' for host and '/' for disk. You can
anchor the expression at left with a '^'. You can anchor the expression
at right with a '$'. The matcher is case insensitive for host but is
case sensitive for disk. A match succeeds if all words in your expres‐
sion match contiguous words in the host or disk.
/ word separator for a disk
^ anchor at left
$ anchor at right
? match exactly one character except the separator
* match zero or more characters except the separator
** match zero or more characters including the separator
Some examples:
EXPRESSION WILL MATCH WILL NOT MATCH
hosta hosta hostb
hoSTA.dOMAIna.ORG
foo.hosta.org
host host hosta
host? hosta host
hostb
ho*na hoina ho.aina.org
ho**na hoina
ho.aina.org
^hosta hosta foo.hosta.org
sda* /dev/sda1
/dev/sda12
/opt/ opt (disk) opt (host)
/ / any other disk
/usr /usr
/usr/opt
/usr$ /usr /usr/opt
DATESTAMP EXPRESSION
A datestamp expression is a range expression where we only match the
prefix. Leading ^ is removed. Trailing $ forces an exact match.
20001212-14match all dates beginning with 20001212, 20001213 or
2000121420001212-4same as previous20001212-24match all dates between
20001212 and 200012242000121match all dates that start with 2000121
(20001210-20001219)2match all dates that start with 2
(20000101-29991231)2000-10match all dates between
20000101-20101231200010$match only 200010.PP
AUTHOR
James da Silva, <jds@amanda.org> : Original text
Stefan G. Weichinger, <sgw@amanda.org>, maintainer of the Amanda-docu‐
mentation: XML-conversion, major update
SEE ALSOamadmin(8), amanda.conf(5), amcheck(8), amcheckdb(8), amcleanup(8),
amdd(8), amdump(8), amfetchdump(8)amflush(8), amgetconf(8), amlabel(8),
ammt(8), amoverview(8), amplot(8), amrecover(8), amreport(8), amre‐
store(8), amrmtape(8), amstatus(8), amtape(8), amtapetype(8), amtoc(8),
amverify(8), amverifyrun(8)AMANDA(8)