Adding tapes to the cycle
Adding tapes to the cycle is an example of an administrative
issue, you can add tapes anywhere in the tape-cycle but that is
guaranteed to confuse people.
- Edit amanda.conf -- Edit the
configuration file in the appropriate configuration directory,
/var/amanda/etc/amanda/daily.
- label the tapes -- Use amlabel to
label the tapes so that amanda will recognize them. This makes
the backups safer and you won't overwrite wrong tapes.
Quit some dump
You usually don't want to interfere with amdump once you got it going,
but if it's necessary you can kill a particular dumper process
without harming the other dumps.
Changing tapes
The tapes are located in the backup safe and labeled VOLXX
where XX are digits. Tapes are normally switched Monday.
These are loaded into the DLT changer on
pacman, and the tapes will be automatically switched after
the nightly backups are done. So if fully loaded it will keep
itself busy for a week. You have to load the first tape into the
tape-writer manually.
If wrong or no tape is loaded amcheck will send a mail warning to
the amanda mail address. This is typically the case when that
week is over. Somebody has better switch the tapes then.
When the last tape in the cycle is used, the first one is loaded
again. There are currently 21 tapes used, soon to be extended to 28.
You can use the amcheck command manually
to verify that the correct tape is loaded.
If you have to replace tapes with new ones or add tapes to the
tape-cycle, you should label them appropriately with
amlabel.
Notification
Amanda sends mail reports with the results of the backup to the
mail address amanda (option set in amanda.conf
on the server). This is also where reports on any problems discovered
by amcheck are sent.
This address is then expanded in /etc/aliases.
Problems
Wrong tape/no tape
If this happens amanda will try to backup as much as possible to
holding disk using only incremental backups. You can then use the
command amflush to flush the backups to the
appropriate tape or a new tape.
Some backups failed
It sometimes happens that a particular backup fails. Most often
because the client is to heavily loaded so the dumper stops on timeout.
There is not much to do about this, but it's abnormal and if it
happens several times on the same host you'll have to look at it.
"mutual-authentication failed"
As reported by amcheck. This means that kerberos authentication
was unsuccessful. This is usually caused by either
amanda.pacman@NADA.KTH.SE missing in the /.klogin
file, or that the system clock is not in sync.
"selfcheck request timed out. Host down?"
This may either be just a heavily loaded client, the timeout on the
check is pretty short. If it persists, it's usually hinting that
the binaries are missing entirely, or that
kamanda (or amanda) is missing from /etc/inetd.conf.
"... -> NULL, mutual authentication failed
(I can't quite remeber what it said.) Nowadays pacman is multi homed.
This happens when the client doesn't have a /etc/krb.equiv with
the servers interfaces.
Installation
The installation of amanda follows the pkg system and has it's
own NADAINSTALL script. To install amanda on a new client simply
login as root and issue the command:
/afs/nada.kth.se/pkg/amanda/default/pkgINSTALL
This will add the files locally in /pkg and add amanda to /etc/pkg.conf
if it's not there. If this script is run on the host pacman, the
intire package will be installed locally, otherwise only the client
binaries, and symlinks will be set up to the rest.
In /etc/services are the default amanda ports defined with:
amanda 10080/udp
kamanda 10081/udp
In /etc/inetd.config is the setup for the launching of amandad:
kamanda dgram udp wait root /pkg/amanda/default/libexec/amandad amandad -krb4
Finally you need to allow the backup server access as root on the
client by adding
amanda.pacman@NADA.KTH.SE
to /.klogin.
Nada specific matters, names of devices and such
- Backup server -- pacman.nada.kth.se
- Amanda service key -- amanda.pacman@NADA.KTH.SE
- Tape device on pacman -- /dev/rst4
- Amanda package -- /pkg/amanda. The present release
is 2.4.1p1 with kerberos additions.
- Man pages --
/pkg/amanda/default/man
- Server binaries, commands -- /pkg/amanda/default/bin
- Server scripts -- /pkg/amanda/default/sbin
- Client (server) binaries -- /pkg/amanda/default/libexec
- Names for disk partitions -- Amanda can use either
mount-points or disk device to dump volumes. Presently most partitions
are listed by device, which is stupid. I'm changing this, and in
the meantime there will be a mixture.
Scripts
Some utility scripts are available in /pkg/amanda/default/sh.
Diskwatcher
Diskwatcher is run from cron and looks for filesystems not currently
backed up by Amanda. It is dependant on information in /misc/adm/diskinfo.
The script compares the contents of the Amanda disklist with the
information in diskinfo and siteinfo. Output is a mail to
amanda@nada.kth.se with a list of such filesystems.
A file /var/amanda/etc/amanda/ignored-disks is used to exclude filesystems
from checking. It is a list of two tab-separated regular expressions,
defining file systems that should be ignored during checking.
Files, and what goes in them
The software package is located in /pkg/amanda. The configuration
files, log files and backup database is located in /var/amanda.
Server configuration files are located in the
/var/amanda/etc/amanda/ directories. The different
subdirectories are the different configuration names, so
the daily backup configuration is located in
/var/amanda/etc/amanda/daily. The files are:
- amanda.conf -- The configuration file which contains
information on where holding disks are, dump-types, tape-types
and so on. The options in the dump-type are specified in
the comments. This file is under RCS version control.
- disklist -- Contain a list of disks to be dumped and
by which dump-type. This file is also under RCS version control.
- tapelist/tapelist.yesterday -- These files are maintained by
amanda itself and contains lists of the tapes used and when.
The server log files are located in subdirectories to
/var/amanda/var/amanda/ in the same manner. There are three
categories of files there:
- log.* -- Brief info from the planner and final report of the
success of the dumps.
- amdump.* -- Detailed report of virtually everything. These
files get pretty big.
- curindex.* -- The little database keeping track of where which
dump is, and when it was made.
You really don't want to loose these files.
You don't usually look at these files by themselves. Instead you use
the amplot command to give a graphical
view. This is very helpful when trying to balance the backup process
and identifying bottlenecks.
There are also some system files that are affected. These are:
- /etc/inetd.conf
- /etc/services
- /.klogin
Refer to the section Installation for
details on what goes in these files.
Finally there are the entries in the crontab. They are listed here
as well:
#
# amanda
#
10 23 * * */pkg/amanda/default/sh/backup.sh dump daily
10 13 * * */pkg/amanda/default/sh/backup.sh check daily
10 10 * * */pkg/amanda/default/sh/diskwatcher -m
How it works -- short description
Amanda is basically organized as client-server, where amandad is the
client that is run from inetd on the client machines. When running
amdump the planner connects to the clients,
gather information of estimated dump-sizes and generates a schedule.
The process which controls the entire dump-cycle (including the planner)
is called the driver.
The driver forks out a dumper per dump which connects to amandad on
the clients to perform the dump. It runs the appropriate dump-command
and pipes the output across the network in 68KB blocks, forking out
gzip and encryption in the pipe as specified in the disklist.
On the server side the dump is written to the holding disk if possible,
otherwise directly to tape, encrypting if needed (but not unpacked
if you use gzip).
When all the dumps are made a report is written and mailed.
Other sources of documentation
Man pages are available for all commands:
More information is available at these sites:
