AMANDA, the Advanced Maryland Automated Network Disk Archiver, is a public domain utility developed at the University of Maryland. It is as advanced as a free backup utility gets and has quite a large user community. With an installed base of at least 1500 sites, AMANDA is easily the most popular free backup utility of its type; therefore I am covering AMANDA in detail.
AMANDA allows you to set up a single master backup server to back up multiple hosts to a single backup drive. (It also works with a number of stackers.) AMANDA uses native dump and/or GNU tar, and can back up a large number of workstations running multiple versions of Unix. Recent versions also can use SAMBA, described later in this chapter, to back up Microsoft Windows (95/98/NT/2000)-based hosts. AMANDA is freely available software maintained by the AMANDA Users Group. More information about AMANDA can be found at http://www.amanda.org.
Tip
This section was written by John R. Jackson with input from Alexandre Oliva. John has done system administration and operating systems and application development for more than 20 years on everything from peripheral processors to supercomputers. He currently works for the Purdue University Computing Center. Alexandre is a PhD student in computer science at the Institute of Computing of the State University of Campinas, Brazil, where he used to work as a system administrator and started to use and develop Amanda. John and Alexandre are members of the Amanda Core Development Team and may be reached at jrj@purdue.edu and oliva@dcc.unicamp.br.
AMANDA was written primarily by James da Silva at the Department of Computer Science of the University of Maryland around 1992. The goal was to be able to back up large numbers of client workstations to a single backup server machine.
AMANDA was driven by the introduction of large capacity tape drives, such as ExaByte 8 mm and DAT 4 mm. With these drives and the increased number of personal workstations, it no longer made sense to back up individual machines to separate media. Coordinating access and providing tape hardware was prohibitive in effort and cost. A typical solution to this problem reaches out to each client from the tape host and dumps areas one by one across the network. But this usually cannot feed the tape drive fast enough to keep it in streaming mode, causing a severe performance penalty.
Tip
Since AMANDA is optimized to take advantage of tape drives, we will use the word tape throughout this section. However, that doesn’t mean that you couldn’t use it with an optical or CD-ROM drive.
The AMANDA approach is to use a "holding disk” on the tape server machine, do several dumps in parallel into files in the holding disk, and have an independent process take data out of the holding disk. Because most dumps are small partials, even a modest amount of holding disk space can provide an almost optimal flow of dump images onto tape.
AMANDA also has a unique approach to scheduling
dumps. A "dump cycle” is defined for each
area to control the maximum time between full dumps.
AMANDA looks at that information, and at
statistics about past dump performance, and estimates the size of
dumps for this run to decide which backup level to do. This gets away
from the traditional, static “It’s Friday so do a full
dump of /usr on client A” approach and
frees AMANDA to balance the dumps so the total
runtime is roughly constant from day to day.
Tip
This section is based on AMANDA Version 2.4.2. Updated versions of this section will be available with the AMANDA source code.
AMANDA is designed to handle large numbers of clients and data, yet is reasonably simple to install and maintain. It scales well, so small configurations, even a single host, are possible. The code is portable to a large number of Unix platforms. It calls standard backup software, such as vendor-provided dump or GNU tar, to perform actual client dumping. There also is support for backing up Windows-based hosts via SAMBA. There is no Macintosh support yet.
AMANDA provides its own network protocols on top of TCP and UDP. It does not, for instance, use rsh or rdump/rmt. Each client backup program is instructed to write to standard output, which AMANDA collects and transmits to the tape server host. This allows AMANDA to insert compression and encryption and also gather a catalog of the image for recovery. Multiple clients are typically backed up in parallel to files in one or more holding disk areas. A separate tape-writing process strives to keep the tape device streaming at maximum throughput. AMANDA can run direct to tape without holding disks, but with reduced performance.
AMANDA supports using more than one tape in a single run but does not yet split a dump image across tapes. This also means it does not support dump images larger than a single tape. AMANDA currently starts a new tape for each run and does not provide a mechanism to append a new run to the same tape as a previous run, which might be an issue for small configurations.
AMANDA supports a wide range of tape storage devices. It uses basic operations through the normal operating system I/O subsystem and a simple definition of characteristics. New devices usually are trivial to add. Several tape changers, stackers, and robots are supported to provide truly hands-off operation. The changer interface is external to AMANDA and well documented, so unsupported changers can be added without a lot of effort.
Either the client or tape server may
do software compression, or hardware compression may be used. On the
client side, software compression reduces network traffic. On the
server side, it reduces client CPU load. Software compression may be
selected on an image-by-image basis.
If
Kerberos is available, clients may use
it for authentication, and dump images may be encrypted. Without
Kerberos, amandahosts authentication (similar to
.rhosts) is used, or AMANDA
may be configured to use
.rhosts
(although
rsh, rlogin, and
rexec are not themselves used).
AMANDA works well with security tools like TCP
wrappers ( ftp://info.cert.org/pub/network_tools) and
firewalls.
Since standard software is used for generating dump images and software compression, only normal Unix tools such as mt, dd, and gunzip/uncompress are needed to recover a dump image from tape if AMANDA is not available. When AMANDA software is available, it locates which tapes are needed and finds images on the tapes.
AMANDA is meant to run unattended, such as from a nightly cron job. Client hosts that are down or hung are noted and bypassed. Tape errors cause AMANDA to fall back to “degraded” mode in which backups are still performed but only to the holding disks. They may be flushed to tape by hand after the problem is resolved.
AMANDA has configuration options for controlling almost all aspects of the backup operation and provides several scheduling methods. A typical configuration does periodic full dumps with partial dumps in between. There is also support for:
Periodic archival backup, for purposes such as taking full dumps to a vault away from the primary site
Incremental-only backups in which full dumps are done outside of AMANDA, such as for very active areas that must be taken offline, or no full dumps at all for areas that can easily be recovered from vendor media
Full dumps, such as of database areas that change completely between each run or critical areas that are easier to deal with during an emergency if they are a single-restore operation
It’s easy to support multiple configurations on the same tape server machine, such as a periodic archival configuration along side a normal daily configuration. Multiple configurations can run simultaneously on the same tape server if there are multiple tape drives.
Scheduling full dumps is typically left up to
AMANDA. They are scattered throughout the dump
cycle to balance the amount of data backed up each run. It’s
important to keep logs of where backup images are for each area
(which AMANDA does for you), since they are not on
a specific, predictable, tape (e.g., the Friday tape will not always
have a full dump of /usr for client A). The
partial backup level also is left to AMANDA.
History information about previous levels is kept and the backup
level automatically increases when sufficient dump size savings will
be realized.
AMANDA uses a simple tape management system and protects itself from overwriting tapes that still have valid dump images and from tapes not allocated to the configuration. Images may be overwritten when a client is down for an extended period or if not enough tapes are allocated, but only after AMANDA has issued several warnings. AMANDA also can be told to not reuse specific tapes.
A validation program may be used before each run to note potential problems during normal working hours when they are easier to correct. An activity report is sent via email after each run. AMANDA also can send a report to a printer and even generate sticky tape labels.
There is no graphical interface. For administration, there is usually only a single simple text file to edit, so this is not much of an issue. For security reasons, AMANDA does not support user-controlled file recovery. There is an ftp-like restore utility for administrators to make searching online dump catalogs easier when recovering individual files .
In addition to the usual enhancements and fixes constantly being added by the AMANDA Core Development Team, three main changes are in various stages of development.
A new internal security framework will make it easier for developers to add other security methods, such as SSH (Secure Shell) ( ftp://ftp.cs.hut.fi/pub/ssh/) and SSL (Secure Socket Layer).
Another major project is a redesign of how AMANDA runs the client dump program. This is currently hardcoded for a vendor dump program, GNU tar or SAMBA tar. The new mechanism will allow arbitrary programs such as cpio, star, and possibly other backup systems. It also will add optional predump and postdump steps that can be used for locking and unlocking and snapshots of rapidly changing data such as databases or the Windows Registry.
The third major project is a redesign of the output subsystem to support nontape media such as CD-ROM, local files, remote files via tools like rcp and ftp, remote tapes, and so on. It also will be able to split dump images across media, handle multiple simultaneous media of different types such as writing to multiple tapes or a tape and a CD-ROM, and handle writing copies of images to multiple media such as a tape to keep on site and a CD-ROM or duplicate tape for archiving.
In addition, the output format will be enhanced to include a
file-1and afile-n. The idea is to put site-defined emergency recovery tools infile-1(the first file on the output) that can be retrieved easily with standard non-AMANDA programs like tar, then use those tools to retrieve the rest of the data. Thefile-narea is the last file on the output and can contain items such as the AMANDA database, which would be complete and up-to-date by the timefile-nis written.
AMANDA may be obtained via the http://www.amanda.org web page or with anonymous FTP at ftp://ftp.amanda.org/pub/amanda/.
A typical release is a
gzip-compressed tar file with a
name like amanda-2.4.1.tar.gz, which means it is
major Version 2.4 and minor Version 1. There are occasional patch
releases that have a name like
amanda-2.4.1p1.tar.gz (release 2.4.1 plus patch
set 1). Beta test prereleases have names like
amanda-2.5.0b3.tar.gz (third beta test
prerelease of 2.5.0).
Some operating system distributions provide precompiled versions of AMANDA, but because AMANDA hardcodes some values into the programs, they may not match the configuration. Work is being done to move these values to runtime configuration files, but for now AMANDA should be built from source.
The AMANDA web page contains useful information about patches not yet part of a release, how to subscribe to related mailing lists, and pointers to mailing list archives. Subscribe to at least amanda-announce to get new release announcements or amanda-users to get announcements plus see problems and resolutions from other AMANDA users. The amanda-users mailing list is a particularly good resource for help with initial setup as well as problems. When posting to it, be sure to include the following information:
AMANDA version
OS version on the server and client(s)
Exact symptoms seen, such as error messages, relevant sections of email reports, debugging and log files
Anything unusual or recent changes to the environment
A valid return email address
Finally, the docs
directory in the release contains several files with helpful
information, such as a FAQ.
After downloading and unpacking the
AMANDA release, read the
README, docs/INSTALL, and
docs/SYSTEM.NOTES files. They contain important
and up-to-date information about how to set up
AMANDA.
Several other packages may be required to complete an AMANDA install. Before continuing, you should locate and install packages your environment will need. In particular, consider the following:
- GNU tar 1.12 or later, http://www.gnu.org
The GNU version of the standard tar program with enhancements to do partial backups and omit selected files. It is one of the client backup programs AMANDA knows how to use.
- SAMBA 1.9.18p10 or later , http://www.samba.org
SAMBA is an implementation of the System Message Block (SMB) protocol used by Windows-based systems for file access. It contains a tool, smbclient , that AMANDA can use to back them up.
-
Perl5.004 or later , http://www.perl.org Perlis a scripting programming language oriented toward systems programming and text manipulation. It is used for a few optional AMANDA reporting tools and by some tape changers.- GNU readline 2.2.1 or later, http://www.gnu.org
The GNU readline library may be incorporated into interactive programs to provide command-line history and editing. It is built into the AMANDA amrecover restoration tool, if available.
- GNU awk 3.0.3 or later, http://www.gnu.org
The GNU version of the awk programming language contains a common version across platforms and some additional features. It is used for the optional AMANDA amplot statistics tool.
- gnuplot 3.5 or later, ftp://ftp.dartmouth.edu/pub/gnuplot/
This gnuplot library (which has nothing to do with the GNU tools; see the accompanying
README) is a graph-plotting package. It is used for the optional AMANDA amplot statistics tool.
Be sure to look in the
AMANDA
patches directory and the patches section on the
web page for updates to these packages. SAMBA
versions before 2.0.3, in particular, must have patches applied to
make them work properly with Amanda. Without the patches, backups
appear to work, but the resulting images are corrupt.
When AMANDA is configured, locations of additional software used on the clients, such as GNU tar and SAMBA, get built into the AMANDA programs, so additional software must be installed in the same place on the AMANDA build machine and all the clients.
A typical AMANDA configuration runs as a user other than root, such as backup or amanda, given just enough permissions to do backups. Often, direct login as the user is disallowed. To use the vendor dump program instead of GNU tar, the AMANDA user must be in a group with read access to the raw disk devices. Membership in this group should be tightly controlled since it opens up every file on the client for viewing.
There are two ways to link AMANDA and the raw device group membership. Either put the AMANDA user in the group that currently owns the raw devices, as the primary group or as a secondary, or pick a new group for AMANDA and change the group ownership of the devices. AMANDA (actually, the vendor dump program) needs only read access, so turn off group write permission. Turn off all “world” access.
AMANDA runs GNU tar under a setuid-root program that grants the needed permissions. The GNU version of tar must be used with AMANDA. Vendor-supplied versions (unless they originated from GNU and are at least Version 1.12) do not work because AMANDA depends on additional features.
Use the AMANDA user
and group for the —with-user and
—with-group options to .
/configure. For instance, to use amanda
for the user and backup as the group:
# ./configure --with-user=amanda --with-group=backup ...No other options are required for . /configure, but all the possibilities may be seen with . /configure —help. Don’t get carried away changing options. The defaults are usually suitable and some require experience with AMANDA to fully understand. Leave —with-debugging enabled so debug log files are created on the clients. They take very little space but often are necessary for tracking down problems.
The normal build creates both tape server and client software. The tape server host often is backed up by AMANDA and needs the client parts. However, the clients usually do not need the tape server parts. A little disk space and build time may be saved by adding —without-server to the . /configure arguments when building for them.
The default security mechanism uses a file formatted just like
.rhosts but called
amandahosts. This keeps
AMANDA operations separate from normal
rsh/rcp work that might use the
same user. It is not recommended, but .rhosts
and hosts.equiv may be used by adding
—without-amandahosts to the .
/configure arguments.
The TCP ports used for data transfer may be restricted with —with-portrange to use AMANDA between hosts separated by a firewall. A typical entry would be:
# ./configure --with-portrange=50000,50100 ...This does not affect the initial UDP requests made from the tape
server to the clients. The amanda UDP port
(typically 10080) must be allowed through the firewall.
If more than just a few . /configure options are
used, they may be put in
/usr/local/share/config.site or
/usr/local/etc/config.site to keep them the same
from build to build. An example is in
example/config.site.
After . /configure is done, run make to build AMANDA, then make install to install it. The make install step must be done as root because some AMANDA programs require system privileges.
Unless the base location is changed, AMANDA installs into these areas:
-
/usr/local/sbin Programs administrators run
-
/usr/local/lib Libraries
-
/usr/local/libexec Private programs only AMANDA uses
-
/usr/local/man Documentation
Now is a good time to read the main amanda manpage. It provides an overview of AMANDA, a description of each program, and detailed configuration information.
The following programs must be setuid -root (which make install as root does). The first group (amcheck, dumper, and planner) run on the tape server machine and need a privileged network port for secure communication with the clients. The others are utility routines optionally used on the clients, depending on the dump program used and operating system type.
-
sbin/amcheck -
libexec/dumper -
libexec/planner Estimate gathering program
-
libexec/killpgrp -
libexec/rundump Setuid wrapper for systems that need to run the vendor dump program as root
-
libexec/runtar
All these programs are installed with world access disabled and group access set to the AMANDA group from —with-group. Be sure all members of that group are trustworthy since rundump and runtar in particular give access to every file on the system.
If AMANDA software is made available via NFS, be
sure the mount options allow setuid programs. Also, if GNU
tar is used, root needs write access to
/usr/local/var/amanda/gnutar-lists (or the
—with-gnutar-list value to .
/configure) to store information about each partial level.
If the build has trouble or AMANDA needs to be rebuilt, especially with different . /configure options, the following sequence makes sure everything is cleaned up from the previous build:
#make distclean#./configure ...#make#make install(as root)
Problems with the . /configure step sometimes can
be diagnosed by looking at the config.log file.
It contains detailed output of tests . /configure
runs. Note that it is normal for many of the tests to
“fail” as part of . /configure
determining how to access various features on the system.
A common problem when using the GNU C compiler is not reinstalling it after the underlying operating system version changes. gcc is particularly sensitive to system header files and must be reinstalled or have its fixincludes step rerun (see the gcc release installation notes) if the operating system is upgraded. Running gcc —verbose shows where gcc gets its information and contains an indication of the operating system version expected.
AMANDA needs changes to the network services and
inetd configuration files. The
client-src/patch-system script should be able to
set up systems in most cases. It currently does not handle systems
that deliver service entries via YP/NIS. If the script does not work,
add the following entries to the
services file (e.g.,
/etc/services) or YP/NIS map:
Amanda 10080/udp Amandaidx 10082/tcp Amidxtape 10083/tcp
Each client needs an entry
in the inetd
configuration file (e.g.,
/etc/inetd.conf ) like this, substituting the
AMANDA user for Amanda and
the full path to the AMANDA
libexec directory for PATH
:
amanda dgram udp waitAmanda/PATH/libexec/amandad amandad
The amanda service is used by all
AMANDA controlling programs to perform functions
on the clients.
The tape server host needs entries like these if the amrecover tool is to be used:
amandaidx stream tcp nowaitAmanda/PATH/libexec/amindexd amindexd amidxtape stream tcp nowaitAmanda/PATH/libexec/amidxtaped amidxtaped
The amandaidx service provides
access to the catalogs, while
amidxtape provides remote access to a tape device.
After every inetd configuration file change,
send a HUP signal to the inetd
process and check the system logs for
errors.
Once installed, AMANDA must be configured to your environment.
The first thing to decide is what machine will be the AMANDA tape server. AMANDA can be CPU-intensive if configured to do server compression, and almost certainly network and I/O-intensive. It typically does not use much real memory. It needs direct access to a tape device that supports media with enough capacity to handle the expected load.
To get a rough idea of the backup sizes, take total disk usage (not capacity), Usage, and divide it by how frequently full dumps will be done, Runs. Pick an estimated run-to-run change rate, Change. Each AMANDA run, on average, does a full dump of Usage/Runs. Another Usage/Runs*Change is done of areas that got a full dump the previous run, Usage/Runs*Change*2 is done of areas that got a full dump two runs ago, and so on.
For example, with 100 GB of space in use, a full dump every seven runs (e.g., days), and estimated run-to-run changes (new or altered files) of 5 percent:
100 GB / 7 = 14.3 GB
100 GB / 7 * 5% = 0.7 GB
100 GB / 7 * 5% * 2 = 1.4 GB
100 GB / 7 * 5% * 3 = 2.1 GB
100 GB / 7 * 5% * 4 = 2.9 GB
100 GB / 7 * 5% * 5 = 3.6 GB
100 GB / 7 * 5% * 6 = 4.3 GB
= 29.3 GBIf 50 percent compression is expected, the actual amount of tape capacity needed for each run, which might be on more than one tape, would be 14.7 GB. This is very simplistic and could be improved with greater knowledge of actual usage but should be close enough to start with. It also gives an estimate of how long each run will take by dividing expected capacity by drive speed.
Unix operating systems typically
incorporate device characteristics into the filename used to access a
tape device. The two to be concerned with are “rewind”
and “compression.” AMANDA must be
configured with the nonrewinding tape device, so called
because when the device is opened and closed it stays at the same
position and does not automatically rewind. This is typically a name
with an n in it, such as
/dev/rmt/0n. On AIX, it is a name with a
.1 or .5 suffix.
Put the AMANDA user in the group that currently owns the tape device, either as the primary group or as a secondary, or pick a new group for AMANDA and change the group ownership of the device. AMANDA needs both read and write access. Turn off all “world” access.
Optionally, dump images may be compressed on the client, the tape server, or the tape device hardware. Software compression allows AMANDA to track usage and make better estimates of image sizes, but hardware compression is more efficient with CPU resources. Turn off hardware compression when using software compression on the client or server. See the operating system documentation for how hardware compression is controlled; on many systems it is done via the device filename just like the nonrewinding flag. AIX uses the chdev command.
If at all possible, allocate some holding disk space for AMANDA on the tape server. Holding disk space can reduce backup time by significantly allowing several dumps to be done at once while the tape is being written. Also, for streaming tape devices, AMANDA keeps the device going at speed, and that may increase capacity. AMANDA may be configured to limit disk use to a specific value so it can share with other applications, but a better approach is to allocate one or more inexpensive disks entirely to AMANDA.
Ideally, there should be enough holding disk space for the two largest backup images simultaneously, so one image can be coming into the holding disk while the other is being written to tape. If that is not practical, any amount that holds at least a few of the smaller images helps. The AMANDA report for each run shows the size of the dump image after software compression (if enabled). That, in addition to the amplot and amstatus tools, may be used to fine-tune the space allocated.
Decide how often AMANDA should do full dumps. This is the “dump cycle.” Short periods make restores easier because there are fewer partials but use more tape and time. Longer periods let AMANDA spread the load better but may require more steps during a restore.
Large amounts of data to back up or small capacity tape devices also affect the dump cycle. Choose a period long enough that AMANDA can do a full dump of every area during the dump cycle and still have room in each run for the partials. Typical dump cycles are one or two weeks. Remember that the dump cycle is an upper limit on how often full dumps are done, not a strict value. AMANDA runs them more often and at various times during the cycle as it balances the backup load. It violates the limit only if a dump fails repeatedly and issues warnings in the email report if that is about to happen.
By default, AMANDA assumes it is run every day. If that is not the case, set "runs per cycle” (described later) to a different value. For instance, a dump cycle of seven days and runs per cycle of five would be used if runs are done only on weekdays.
Normally, AMANDA uses one tape per run. With a tape changer (even the chg-manual one), the number of tapes per run may be set higher for extra capacity. This is an upper limit on the number of tapes. AMANDA uses only as much tape as it needs. AMANDA does not yet do overflow from one tape to another. If it hits end of tape (or any other error) while writing an image, that tape is unmounted, the next one is loaded, and the image starts over from the beginning. This sequence continues if the image cannot fit on a tape.
Runs per cycle and tapes per run determine the minimum number of tapes needed, called the "tape cycle.” To ensure the current run is not overwriting the last full dump, one more run should be included. For instance, a dump cycle of two weeks, with default runs per cycle of 14 (every day) and default tapes per run of one, needs at least 15 tapes (14+1 runs times 1 tape/run). Using two tapes per run 30 tapes (14+1 runs times 2 tapes/run). Doing backups just on weekdays with a dump cycle of two weeks, runs per cycle of 10, and two tapes per run 22 tapes (10+1 runs times 2 tapes/run).
More tapes than the minimum should be allocated to handle error situations. Allocating at least two times the minimum allows the previous full dump to be used if the most recent full dump cannot be read. Allocating more tapes than needed also goes back further in time to recover lost files. AMANDA does not have a limit on the number of tapes in the tape cycle.
Pick a name for the
configuration (the name Daily will be used for
the rest of this section). Create a
directory on the tape server machine
to hold the configuration files, typically
/usr/local/etc/amanda/Daily. Access to this
directory (or perhaps its parent) should be restricted to the
AMANDA group or even to the
AMANDA user.
Each tape assigned to a configuration needs a unique label. For this
example, we’ll use the configuration name, a dash, and a
three-digit suffix, Daily-000 through
Daily-999. Do not use blanks, tabs, slashes
(/), shell wildcards, or nonprintable characters.
AMANDA limits network usage so backups do not take all the capacity. This limit is imposed when AMANDA is deciding whether to perform a dump by estimating the throughput and adding that to dumps that are already running. If the value exceeds the bandwidth allocated to AMANDA, the dump is deferred until enough others complete. Once a dump starts, AMANDA lets underlying network components do any throttling.
Copy the template example/amanda.conf file to
the configuration directory and edit it. Full documentation is in the
amanda manpage. There are many parameters, but
probably only a few need to be changed. Start with the following
(some of which are described later):
-
org This string will be in the subject line of AMANDA email reports.
-
mailto Target address for AMANDA email reports.
-
dumpuser Same as —with-user from . /configure.
-
dumpcycle The dump cycle.
-
runspercycle The runs per cycle.
-
tapecycle The tape cycle.
-
runtapes Number of tapes to use per run.
-
tapedev The no-rewind tape device if a changer is not being used or if the manual changer is being used.
-
tapetype Type of tape media.
-
netusage Network bandwidth allocated to AMANDA.
-
labelstr A regular expression ( grep pattern) used to make sure each tape is allocated to this AMANDA configuration. Our example might use
Daily-[0-9][0-9] [0-9].
The following parameters probably do not need to be changed, but look at their values to know where AMANDA expects to find things:
Define each holding disk in an
amanda.conf
holdingdisk
section. If partitions are dedicated to AMANDA,
set the use value to a small negative number,
such as -10
MB. This tells
AMANDA to use all but that amount of space. If
space is shared with other applications, set the value to the amount
AMANDA may use, create the directory, and set the
permissions so only the
AMANDA user can access it.
Set a
chunksize
value for each
holding disk. Negative numbers cause AMANDA to
write dumps larger than the absolute value directly to tape,
bypassing the holding disk. Positive numbers split dumps in the
holding disk into chunks no larger than the
chunksize value. Even though the images are split
in the holding disk, they are written to tape as a single image. At
the moment, all chunks for a given image go to the same holding disk.
Older operating systems that do not support individual files larger than 2 GB need a chunk size slightly smaller, such as 2000 MB, so the holding disk still can be used for very large dump images. Systems that support individual files larger than 2 GB should have a very large value, such as 2000 GB.
AMANDA
needs to know some characteristics of the
tape media. This is set in a tapetype
section
. The example
amanda.conf, web page, and
amanda-users
mailing list archives have entries for
most common media. Currently, all tapes should have the same
characteristics. For instance, do not use both 60-meter and 90-meter
DAT tapes since AMANDA must be told the smaller
value, and larger tapes may be underutilized.
If the media type is not listed and there are no references to it in
the mailing list archives, go to the tape-src
directory, make tapetype, mount a scratch tape in
the drive, and run . /tapetype
NAME DEV where NAME is a text
name for the media and DEV is the
no-rewind tape device with hardware compression disabled. This
program rewinds the tape, writes random data until it fills the tape,
rewinds, and then writes random data and tape marks until it fills
the tape again. This can take a very long time (hours or days). When
finished, it generates a new tapetype section to
standard output suitable for adding to the
amanda.conf file. Post the results to the
amanda-users mailing list so others may benefit from
your effort.
When using
hardware compression, change
the length value based on the estimated
compression rate. This typically means multiplying by something
between 1.5 and 2.0.
The length
and filemark
values are used by AMANDA only to plan the backup
schedule. Once dumps start, AMANDA ignores the
values and writes until it gets an error. It does not stop writing
just because it reaches the tapetype
length. AMANDA does not
currently use the tapetype
speed parameter.
Once the tapetype definition is in
amanda.conf, set the
tapetype parameter to reference it.
Without special hardware to mount
tapes, such as a robot or stacker, either set the
tapedev parameter to the no-rewind device name
or set up the AMANDA chg-manual
changer. The manual changer script prompts for tape mounts as needed.
The prompts normally go to the terminal of the person running
AMANDA, but the changer may be configured to send
requests via email or to some other system logging mechanism.
To configure the manual changer, set tapedev to
the no-rewind tape device and set tpchanger to
chg-manual. To send tape mount prompts someplace
other than the terminal, which is necessary if
AMANDA is run from a cron job,
see the request shell function comments in
changer-src/chg-manual.sh.in.
Another common tape changer is chg-multi. This
script can drive stackers that advance to the next tape when the
drive is unloaded, or it can use multiple tape drives on the tape
sever machine to emulate a changer. The chg-multi
script has a configuration file and a state file. Put the path to the
configuration file in the amanda.conf
changerfile parameter. There is a sample in
example/chg-multi.conf. It has the following
keyword/value pairs separated by whitespace:
-
firstslot Number of the first slot in the device.
-
lastslot Number of the last slot in the device.
-
gravity Set to 1 if the device is gravity fed and cannot go backward, otherwise set to 0.
- needeject
Set to 1 if the tape needs to be ejected to advance to a new tape, otherwise set to 0.
- multieject
Set to 1 if sending multiple ejects causes the changer to advance through the tapes, otherwise set to 0. If set to 1,
gravityalso must be set to 1, because the script currently does not handle carousels that wrap back around to the first tape after the last one. Also,needejectmust be set to 0.-
ejectdelay Set to a number of seconds of extra delay after ejecting a tape if it takes a while before the next tape is ready.
-
statefile Set to the path to a file chg-multi builds and maintains with the current state of the changer.
-
slot Repeat as needed to define all the slots and corresponding tape devices. The first field after
slotis the slot number. The next field is the no-rewind tape device name. For changers that have a single tape device, repeat the device name for each slot. To emulate a changer by using multiple tape devices, list a different no-rewind tape device for each slot.
chg-multi
also may be used as a framework to
write a new changer. Look for XXX comments in the
script and insert calls to commands appropriate for the device. Make
any source changes to the
changer-src/chg-multi.sh.in file. That file is
processed by . /configure to generate
chg-multi.sh, which turns into
chg-multi with make. If
chg-multi.sh or chg-multi
is altered, the changes will be lost the next time
AMANDA is rebuilt.
A third popular changer is
chg-scsi
. It can drive devices that
have their own SCSI interface. An operating system kernel module may
need to be installed to control such devices, like
sst for Solaris, which is released with
AMANDA, or chio, available for
various systems. As with chg-multi, set the
amanda.conf
changerfile
parameter to the changer configuration file path. There is a sample
in example/chg-scsi.conf. The initial section
has parameters common to the entire changer:
-
number_configs Set to the number of tape drives connected to this changer. The default is 1.
- eject
Set to 1 if tape drives need an explicit eject command before advancing to the next tape, otherwise set to 0.
-
sleep Set to the number of seconds to wait for a tape drive to become ready.
-
changerdev Set to the device path of the changer. This may be set in the
amanda.conffile instead of here if preferred.
Following the common parameters is a section for each tape device:
-
config Set to the configuration number, starting with 0.
-
drivenum Set to the tape drive number, usually the same as the configuration number.
-
dev Set to the no-rewind device name of the tape drive.
-
startuse Set to the number of the first slot served by this drive.
-
enduse Set to the number of the last slot served by this drive.
-
statfile Set to the path to a file chg-scsi will build and maintain with the current state of this drive.
Test any changer setup with the
amtape command. Make sure it can load a specific
tape with the slot
NNN
suboption, eject the current tape with eject, and
advance to the next slot with slot next.
Tapes must be prelabeled with amlabel so AMANDA can verify the tape is one it should use. Run amlabel as the AMANDA user, not root. For i nstance:
# su amanda -c "amlabel Daily Daily-123 slot 123"After tapes are labeled, pick the first client, often the tape server host itself, and the filesystems or directories to back up. For each area to back up, choose either the vendor dump program or GNU tar. Vendor dump programs tend to be more efficient and do not disturb files being dumped but usually are not portable between different operating systems. GNU tar is portable and has some additional features, like the ability to exclude patterns of files, but alters the last access time for every file backed up and may not be as efficient. GNU tar also may deal with active filesystems better than vendor dump program, and is able to handle very large filesystems by breaking them up by subdirectories.
Choose the type of
compression for each area, if
any. Consider turning off compression of critical areas needed to
bring a machine back from the dead in case the decompression program
is not available.
Client
compression spreads the load to multiple machines and reduces network
traffic but may not be appropriate for slow or busy clients.
Server
compression increases the load on the tape server machine, possibly
by several times since multiple dumps are done at once. For either,
if GNU
gzip is used, compression may be set to
fast for faster but less aggressive compression or
best for slower but more aggressive compression.
Set compression to none to
disable software compression or use hardware compression.
Pick or alter an existing
dumptype
that
matches the desired options, or create a new one. Each
dumptype should reference the
global
dumptype. It is used
to set options for all other dumptypes. For
instance, to use the indexing facility, enable it in the
global
dumptype and all other
dumptypes will inherit that value.
The indexing facility generates a compressed catalog of each dump image. These are useful for finding lost files and are the basis of the amrecover program. Long dump cycles or areas with many or very active files can cause the catalogs to use a lot of disk space. AMANDA automatically removes catalogs for images that are no longer on tape.
Create a file named
disklist
in the same directory as
amanda.conf and either copy the file from
example/disklist or start a new one. Make sure
it is readable by the AMANDA user. Each line in
disklist defines an area to be backed up. The
first field is the client hostname (fully qualified names are
recommended), the second is the area to be backed up on the client,
and the third is the dumptype. The area may be
entered as a disk name (sd0a) a device name (
/dev/rsd0a) or a
logical name, (
/usr). Logical names make it easier to
remember what is being backed up and to deal with disk
reconfiguration.
To set up a
Windows client, set the hostname to
the name of the
Unix machine running
SAMBA and the area to the Windows share name, such
as //some-pc/C$. Note that Unix-style forward
slashes are used instead of Windows-style backward slashes.
Enable AMANDA access to the
client from the tape server host (even if the client is the tape
server host itself) by editing .amandahosts (or
.rhosts, depending on what was set with
. /configure) in the AMANDA
user home directory on the client. Enter the fully qualified tape
server hostname and AMANDA user, separated by a
blank or tab. Make sure the file is owned by the
AMANDA user and does not allow access to anyone
other than the owner (e.g., mode 0600 or 0400).
For Windows clients, put the share password in
/etc/amandapass on the SAMBA
host. The first field is the Windows share name, the second is the
clear
text password, and the optional third field is the domain. Because
this file contains clear text passwords, it should be carefully
protected, owned by the AMANDA user, and allow
only user access. By default,
AMANDA
uses
SAMBA
user
backup. This can be changed with
—with-samba-user to .
/configure.
Test the setup with amcheck. As with all AMANDA commands, run it as the AMANDA user, not root:
# su amanda -c "amcheck Daily"Many errors reported by amcheck are described in
docs/FAQ or the amcheck
manpage. The most common error reported to the
AMANDA mailing lists is self-check request timed
out, meaning amcheck was not able to talk to
amandad on the client. In addition to the ideas in
docs/FAQ, here are some other things to try:
Are the AMANDA services listed properly in
/etc/servicesor a YP/NIS map? The C program in Example 4-1 uses the same system call as AMANDA to look up entries.Example 4-1. A C Program to Check the AMANDA Service Numbers
# include <stdio.h># include <string.h># include <netdb.h>main (int argc,char **argv){char *pn;char *service;char *protocol = "tcp";struct servent *s;if ((pn = strrchr (*argv, '/')) == NULL) {pn = *argv;} else {pn++;}if (argc < 2) {fprintf (stderr, "usage: %s service [protocol]\n", pn);return 1;}service = *++argv;if (argc > 2) {protocol = *++argv;}if ((s = getservbyname (service, protocol)) == NULL) {fprintf (stderr, "%s: %s/%s lookup failed\n", pn,service, protocol);return 1;}printf ("%s/%s: %d\n", service, protocol,(int) ntohs (s->s_port));return 0;}Run it on both the tape server and client and make sure the port numbers match:
$
cc check-service.c -lnsl -lsocket(Solaris) $a.out amanda udpamanda/udp: 10080 $a.out amandaidxamandaidx/tcp: 10082 $a.out amidxtapeamidxtape/tcp: 10083Is there a line in the inetd configuration file on the client to start amandad ?
Was inetd sent a
HUPsignal after the configuration file was changed?Are there system log messages from inetd about
amandaor amandad ? For instance, inetd complains if it cannot look up the AMANDA services.Is
/tmp/amanda/amandad/debugbeing updated?Is the access time on the amandad executable (ls -lu) being updated? If not, inetd is probably not able to run it, possibly because of an error in the inetd configuration file or a permission problem.
Run the amandad program by hand as the AMANDA user on the client. It should sit for about 30 seconds, then terminate. Enter the full path exactly as it was given to inetd, perhaps by using copy/paste.
Do not proceed until amcheck is happy with the configuration.
For initial testing, set the
record
option to
no in the
global
dumptype, but
remember to set it back to yes when
AMANDA goes into normal production. This parameter
controls whether the dump program on the client
updates its own database, such as /etc/dumpdates
for vendor dump.
To forget about an
individual test run, use amrmtape to remove
references to the tapes used, then use
amlabel
to relabel them. To completely
start over, remove the files or directories named in the
infofile and indexdir
parameters, the tapelist file named in the
tapelist parameter, all
amdump.* files in the configuration directory
and all log.* files in the directory named by
the logdir parameter. These files contain
history information AMANDA needs between runs and
also what is needed to find particular dump images for restores and
should be protected when AMANDA goes into
production.
Once configured, you will need to set up the automated use of AMANDA.
The amdump script controls a normal AMANDA backup run. However, it’s common to do site-specific things as well with a wrapper shell script around amdump. amdump is meant to run unattended from cron. See the operating system documentation for how to set up a cron task. Be sure it runs as theAMANDA user, not root or the installer.
The amdump script does the following:
If a file named
holdis in the configuration directory, amdump pauses until it goes away. This may be created and removed by hand to temporarily delay AMANDA runs without having to change the cron task.If it looks as if another copy of amdump is running or a previous run aborted, amdump logs an error and terminates. If an earlier run aborted, amcleanup must be run. An amcleanup step should be added to the tape server system boot sequence to handle crashes. No backups can be performed after an abort or crash until amcleanup is run.
The AMANDA planner program decides what areas to back up and at what level. It does this by connecting to each client and getting estimated sizes of a full dump, the same partial level that was done on the previous run and possibly the next partial level. All clients are done in parallel, but it can take a while to gather all this information.
The schedule is then passed to the driver program that controls actual dumping. It, in turn, starts up several dumper processes (based on the
inparallelamanda.confparameter) and a single taper process. The taper process splits into two parts, a reader and a writer, to keep streaming tape drives busy.driver commands dumpers to start backups, telling each its client, area, options such as compression, and whether the result should go to the holding disk or direct to tape. Each dumper connects to amandad on the client and sends a request describing the dump program to run and options such as whether to do compression or indexing. The image comes back to the dumper, which writes it, possibly via the server compression program, into the holding disk or directly to a taper connection. If enabled, dumper also collects catalog information generated on the client and compresses it into the
indexdirarea. The driver also commands taper to write files from the holding disk to tape or to prepare to receive an image directly from a dumper.After backups are done, amreport is run to generate the email report. It also renames the log file for the run to a unique
log.YYYYMMDD.Nname.Old
amdump.NNdebug log files are rolled so only enough to match the tape cycle are retained.The amtrmidx program is run to remove old catalogs if indexing has been used.
There are several ways to determine which tapes AMANDA will need for a run. One is to look at the AMANDA email report from the previous run. The tapes used during that run and those expected for the next run are listed. Another is to run amcheck during normal working hours. In addition to showing which tapes are needed, it makes sure things are set up properly so problems can be fixed before the real AMANDA run. A third is to use the tape suboption of amadmin. Without a tape changer, AMANDA expects the first tape to be mounted in the drive when it starts. Automated tape changers should be able to locate the tapes. The chg-manual changer prompts for the tapes.
An AMANDA report has several sections:
These dumps were to tape Daily-009, Daily-010. Tonight's dumps should go onto 2 tapes: Daily-011, Daily-012.
This shows which tapes were used during the run and which tapes are needed next.
FAILURE AND STRANGE DUMP SUMMARY: gurgi.cc.p /var lev 0 FAILED [Request to gurgi.cc.purdue.edu timed out.] gurgi.cc.p / lev 0 FAILED [Request to gurgi.cc.purdue.edu timed out.] pete.cc.pu /var/mail lev 0 FAILED ["data write: Broken pipe"] samba.cc.p //nt-test.cc.purdue.edu/F$ lev 1 STRANGE mace.cc.pu /master lev 0 FAILED [dumps too big, but cannot incremental dump new disk]
Problems found during the run are summarized in this section. In this example:
gurgi.cc.purdue.eduwas down, so all its backups failed.The
/var/mailproblem onpete.cc.purdue.eduandF$problem onnt-test.cc.purdue.eduare detailed later.The
/masterarea onmace.cc.purdue.eduis new to AMANDA, so a full dump is required, but it would not fit in the available tape space for this run.STATISTICS: Total Full Daily -------- -------- -------- Dump Time (hrs:min) 5:03 3:23 0:33 (0:14 start, 0:53 idle) Output Size (meg) 20434.4 17960.0 2474.4 Original Size (meg) 20434.4 17960.0 2474.4 Avg Compressed Size (%) -- -- -- Tape Used (%) 137.4 120.0 17.4 (level:#disks ...) Filesystems Dumped 90 21 69 (1:64 2:2 3:3) Avg Dump Rate (k/s) 1036.5 1304.3 416.2 Avg Tp Write Rate (k/s) 1477.6 1511.2 1271.9
This summarizes the entire run. It took just over five hours, almost three and a half hours writing full dumps and about half an hour for partials. It took 14 minutes to get started, mostly in the planner step getting the estimates, and taper was idle almost an hour waiting on dumps to come into the holding disk.
In this example,
hardware compression was
used so Avg Compressed Size is not applicable and Output Size written
to tape matches Original Size from the clients. About 137 percent of
the length of the tape as defined in the
tapetype
was used (remember that two tapes were written), 120 percent for full
dumps and 17 percent for partials. The Rate lines give the dump speed
from client to tape server and tape writing speed, all in KB per
second. The Filesystems Dumped line says 90 areas were processed, 21
full dumps and 69 partials. Of the partials, 64 were level 1, two
were level 2, and three were level 3.
FAILED AND STRANGE DUMP DETAILS: /-- pete.cc.pu /var/mail lev 0 FAILED ["data write: Broken pipe"] sendbackup: start [pete.cc.purdue.edu:/var/mail level 0] sendbackup: info BACKUP=/usr/sbin/ufsdump sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... - sendbackup: info end | DUMP: Writing 32 Kilobyte records | DUMP: Date of this level 0 dump: Sat Jan 02 02:03:22 1999 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/md/rdsk/d5 (pete.cc.purdue.edu:/var/mail) to standard output. | DUMP: Mapping (Pass I) [regular files] | DUMP: Mapping (Pass II) [directories] | DUMP: Estimated 13057170 blocks (6375.57MB) on 0.09 tapes. | DUMP: Dumping (Pass III) [directories] | DUMP: Dumping (Pass IV) [regular files] | DUMP: 13.99% done, finished in 1:02 | DUMP: 27.82% done, finished in 0:52 | DUMP: 41.22% done, finished in 0:42 /-- samba.cc.p //nt-test.cc.purdue.edu/F$ lev 1 STRANGE sendbackup: start [samba.cc.purdue.edu://nt-test/F$ level 1] sendbackup: info BACKUP=/usr/local/bin/smbclient sendbackup: info RECOVER_CMD=/usr/local/bin/smbclient -f... - sendbackup: info end ? Can't load /usr/local/samba-2.0.2/lib/smb.conf - run testparm to debug it | session request to NT-TEST.CC.PURD failed | directory \top\ | directory \top\Division\ | 238 ( 2.7 kb/s) \top\Division\contract.txt | 19456 ( 169.6 kb/s) \top\Division\stuff.doc ...
Failures and unexpected results are detailed here. The dump of
/var/mail would not fit on the first tape so was
aborted and rerun on the next tape, as described further in the next
section.
The dump of F$ on nt-test.cc.purdue.edu failed due to a problem
with the SAMBA configuration file. It’s
marked STRANGE because the line with a question mark does not match
any of the regular expressions built into AMANDA.
When dumping
Windows clients via
SAMBA, it’s normal to get errors about busy
files, such as PAGEFILE.SYS and the Registry.
Other arrangements should be made to get these safely backed up, such
as a periodic task on the PC that creates a copy that will not be
busy at the time AMANDA runs.
NOTES:
planner: Adding new disk j.cc.purdue.edu:/var.
planner: Adding new disk mace.cc.purdue.edu:/master.
planner: Last full dump of mace.cc.purdue.edu:/src on tape Daily-012 overwritten
in 2 runs.
planner: Full dump of loader.cc.purdue.edu:/var promoted from 2 days ahead.
planner: Incremental of sage.cc.purdue.edu:/var bumped to level 2.
taper: tape Daily-009 kb 19567680 fm 90 writing file: short write
taper: retrying pete.cc.purdue.edu:/var/mail.0 on new tape: [writing file: short
write]
driver: pete.cc.purdue.edu /var/mail 0 [dump to tape failed, will try again]
taper: tape Daily-010 kb 6201216 fm 1 [OK]Informational notes about the run are listed here. The messages from planner say:
There are new
disklistentries for j.cc.purdue.edu and mace.cc.purdue.edu.Tape
Daily-012is due to be overwritten in two more runs and contains the most recent full dump of/srcfrom mace.cc.purdue.edu, so the tape cycle may not be large enough.The next scheduled full dump of
/varon loader.cc.purdue.edu was moved up two days to improve the load balance.The partial dump of
/varon sage.cc.purdue.edu was bumped from level 1 to level 2 because the higher level was estimated to save enough space to make it worthwhile.
The rest of the notes say taper was not able to
write as much data as it wanted, probably because of hitting end of
tape. Up to that point, it had written 19567680 KB in 90 files on
tape Daily-009. Another attempt at the full dump
of /var/mail from pete.cc.purdue.edu was made on the next tape
(Daily-010) and it succeeded, writing 6,201,216 KB
in one file.
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-------------------------- -------------------------------------- --------------
boiler.cc / 1 2624 2624 -- 0:13 200.1 0:02 1076.0
boiler.cc /home/boiler/a 1 192 192 -- 0:07 26.7 0:02 118.5
boiler.cc /usr 1 992 992 -- 0:41 24.2 0:02 514.7
boiler.cc /usr/local 1 288 288 -- 0:09 31.2 0:04 86.3
boiler.cc /var 1 4256 4256 -- 0:21 205.9 0:04 1104.3
egbert.cc / 1 41952 41952 -- 1:26 487.3 0:37 1149.4
egbert.cc /opt 1 224 224 -- 0:06 37.5 0:02 136.0
egbert.cc -laris/install 1 64 64 -- 0:11 5.8 0:02 49.5
gurgi.cc. / 0 FAILED --------------------------------------------
gurgi.cc. /var 0 FAILED --------------------------------------------
pete.cc.p / 1 13408 13408 -- 0:41 328.2 0:08 1600.5
pete.cc.p /opt 1 3936 3936 -- 1:04 61.2 0:03 1382.6
pete.cc.p /usr 1 1952 1952 -- 0:29 67.0 0:03 584.3
pete.cc.p /var 1 300768 300768 -- 2:33 1963.8 2:50 1768.8
pete.cc.p /var/mail 0 6201184 6201184 -- 73:45 1401.3 73:47 1400.8
...
(brought to you by Amanda version 2.4.1p1) This section (which has been abbreviated) reports each area dumped showing client, area, backup level, sizes, time to dump, and time to write to tape. Entries are in alphabetic order by client and then by area. This is not the same as the tape order. Tape order can be determined with the find or info suboption of the amadmin command, amtoc can generate a tape table of contents after a run, or amreport can generate a printed listing. By default, client names are truncated on the right, area names on the left, to keep the report width under 80 characters. This typically leaves the unique portions of both.
Two log files are created during an
AMANDA run. One is named
amdump.
NN, where
NN is a sequence number (1 is most recent,
2 is next most recent, etc.); it is in the same directory as
amanda.conf. The file contains detailed
step-by-step information about the run and is used for statistics by
amplot and amstatus, and for
debugging. The other file is named
log
.YYYYMMDD.N where
YYYYMMDD is the date of the
AMANDA run and N is a
sequence number in case more than one run is made on the same day (0
for the first run, 1 for the second, etc). This file is in the
directory specified by the logdir
amanda.conf parameter. It contains a summary of
the run and is the basis for the email report. In fact,
amreport may be run by hand and given an old file
to regenerate a report.
Old amdump
.NN files
are removed by the amdump script. Old
log
.YYYYMMDD
.
N
files are not removed automatically and should be cleared out
periodically by hand. Keeping a full tape cycle is a good idea. If
the tape cycle is 40 and AMANDA is run once a day,
the following command would do the job:
#
find log.????????.* -mtime +40 -print | xargs rmIf —with-pid-debug-files was used on
. /configure, clients accumulate
debug files in
/tmp/amanda (or whatever
—with-debug was set to) and should be
cleaned out periodically. Without this option, client debug files
have fixed names and are reused from run to run.
While amdump is running, amstatus can track how far along it is. amstatus may also be used afterward to generate statistics on how many dumpers were used, what held things up, and so on.
When a tape
error happens
on the last tape allowed in a run (as set by
runtapes), AMANDA continues
to do backups into the holding disks. This is called
“degraded” mode. By default, full dumps are not done and
any that were scheduled have a partial done instead. A portion of the
holding disk area may be allocated to do full dumps during degraded
mode by reducing the reserved
amanda.conf value below 100 percent.
A tape server crash also may leave images in the holding disks. Run amflush, as the AMANDA user, to flush images in the holding disk to the next tape after correcting any problems. It goes through the same tape request mechanism as amdump. If more than one set of dumps are in the holding disk area, amflush prompts to choose one to write or to write them all. amflush generates an email report just like amdump.
Operating systems vary in how they report end of tape to programs. A no space or short write error probably means end of tape. For I/O error, look at the report to see how much was written. If it is close to the expected tape capacity, it probably means end of tape; otherwise, it means a real tape error happened and the tape may need to be replaced the next time through the tape cycle.
To swap out a partially bad tape, wait until it is about to be used again so any valid images can still be retrieved. Then swap the tapes, run amrmtape on the old tape and run amlabel on the replacement so it has a proper AMANDA label.
If a tape is marked to not be reused with the no-reuse suboption of amadmin, such as one that has been removed or is failing, AMANDA may want a freshly labeled tape on the next run to get the number of tapes back up to the full tape cycle.
If a tape goes completely bad, use amrmtape to make AMANDA forget about it. As with marking a tape no-reuse, this may reduce the number of tapes AMANDA has in use below the tape cycle, and it may request a newly labeled tape on the next run.
The following steps let AMANDA know about all tapes, including those that do not have data yet.
Run amlabel on the new tapes.
Edit the
tapelistfile by hand and move the new tapes before the tape to be used just ahead of them. For instance, moveDaily-100beforeDaily-099.Set the datestamp on the new tapes to the same as the previous tape, e.g., make them the same for
Daily-099andDaily-100.Update the
tapecycleamanda.confparameter if new tapes are being added.
When the cycle gets to the last old tape
(Daily-099), the next tape used will be the first
new one (Daily-100). A new option is planned for
amlabel to do these steps automatically.
Multiple amdump runs may be made in the same day,
although catalogs currently are stored without a timestamp so
amrecover may not show all restore possibilities.
To redo a few areas that failed during the normal run, edit the
disklist
file by hand to comment out all the
other entries, run amdump, then restore the
disklist file.
Use the force suboption of
amadmin to schedule a full dump of an area on the next
run. Run this as theAMANDA user, not
root. AMANDA automatically detects new
disklist entries and schedules an initial full
dump. But for areas that go through a major change, such as an
operating system upgrade or full restore, force
AMANDA to do a full dump to get things back into
sync.
AMANDA does not automatically notice
new client areas, so keep the disklist in sync
by hand. AMANDA usually notices areas that are
removed and reports an error as a reminder to remove the entry from
the disklist. Use the delete
suboption of amadmin (as the AMANDA user) to make
AMANDA completely forget about an area, but wait
until the information is not needed for restores. This does not
remove the entry from the disklist
file—that must be done by hand.
Non-AMANDA backups may still be done with
AMANDA installed, but do not let the
client dump
program update its database. For vendor dump
programs, this usually means not using the u flag
or saving and restoring /etc/dumpdates. For GNU
tar it means the
—listed-incremental flag (if used) should
not point to the same file AMANDA uses.
As with all backup systems, verify the resulting tapes, if not each one, then at least periodically or by random sample. The amverify script does a reasonably good job of making sure tapes are readable and images are valid. For GNU tar images, the test is very good. For vendor dump images of the same operating system type as the tape server machine, the test is OK but does not really check the whole image due to the limited way the catalog option works. For vendor dump images from other operating systems, amverify can tell if the image is readable from tape but not whether it is valid.
Tape drives are notorious for being able to read only what they wrote, so run amverify on another machine with a different drive, if possible, so an alternate is available if the primary drive fails. Make a copy of the AMANDA configuration directory on the other machine to be able to run amverify. This copy is also a good way to have a backup of the AMANDA configuration and database in case the tape server machine needs to be recovered.
Once you have AMANDA running for a while, you may choose to do some additional advanced configuration.
Several dumptype parameters control the backup
level AMANDA picks for a run:
- dumpcycle
Maximum days between full dumps
- strategy nofull
Never schedule (or run) a full dump
- strategy incronly
Only schedule non-full dumps
Note that dumpcycle is both a general amanda.conf parameter and a specific dumptype parameter. The value in a specific dumptype takes precedence. To handle areas that change significantly between each run and should get a full dump each time (such as the mail spool on a busy email server or a database area), create a dumptype based on another dumptype with attributes changed as desired (client dump program, compression) and set dumpcycle in the new dumptype to 0:
define mail-spool {
comp-user-tar
dumpcycle 0
}To run full dumps by hand outside
of AMANDA (perhaps they are too large for the
normal tape capacity or need special processing), create a new
dumptype and set strategy
to incronly :
define full-too-big {
comp-user-tar
strategy incronly
}Tell AMANDA when a full dump of the area has been done with the force suboption of amadmin. Take care to do full dumps often enough that the tape cycle does not wrap around and overwrite the last good nonfull backups.
To never do full dumps (such as an area easily regenerated from
vendor media), create a new
dumptype
and set
strategy to nofull:
define man-pages {
comp-user-tar
strategy nofull
}Only level-1 backups of such areas are done, so wrapping around the tape cycle is not a problem.
To do periodic archival
full dumps, create a new
AMANDA configuration with its own set of tapes but
the same disklist as the normal configuration
(e.g., symlink them together). Copy amanda.conf,
setting all dumpcycle values to
0 and record to
no, e.g., in the global
dumptype. If a changer is used, set
runtapes very high so tape capacity is not a
planning restriction. Disable the normal AMANDA
run, or set the hold file as described in Section 4.8.6, so AMANDA does not
try to process the same client from two configurations at the same
time.
AMANDA starts several dumper processes and keeps as many as possible running at once. The following options control their activity:
-
inparallel Total number of dumpers
-
maxdumps Maximum dumpers for a single client
The default maxdumps
is one, meaning only one dumper is assigned to a
client at a time. If a client can support the load, increase
maxdumps so more than one dump on that client is
running at once. Note that maxdumps is both a
general amanda.conf parameter and a specific
dumptype parameter. The value in a specific
dumptype takes precedence.
Field four of the disklist file is a
"
spindle number.” Areas with
the same non-negative spindle number are not backed up at the same
time if maxdumps is greater than 1. This
prevents thrashing on an individual physical disk. Set spindle number
to -1 (which is the default) for independent areas
that can be done in conjunction with any other area, such as a whole
physical disk.
If the tape
server has multiple network connections, an
amanda.conf
interface
section may be set up for each one and clients allocated to a
particular interface with field five of the
disklist. Individual interfaces take precedence
over the general netusage bandwidth limit and
follow the same guidelines described earlier in Section 4.8.5: the limit is imposed when deciding
whether to start a dump, but once a dump starts,
AMANDA lets underlying network components do any
throttling.
Individual AMANDA interface
definitions do not control which physical connection is used. That is
left up to the operating system network software. While it’s
common to give an AMANDA interface definition the
same name as a physical connection, e.g., le0, it
might be better to use logical names such as
back-door-atm to avoid confusion.
The starttime
dumptype
parameter
delays a backup some amount of time after
AMANDA is started. The value is entered as
HHMM, so 230, for
instance, would wait 2.5 hours. This may be used to delay backups of
some areas until they are known to be idle.
amstatus may be used to get a summary of dumper activity:
# su amanda -c "amstatus Daily --file amdump.1 --summary"
...
dumper0 busy : 5:52:01 ( 98.03%)
dumper1 busy : 0:23:09 ( 6.45%)
dumper2 busy : 0:13:27 ( 3.75%)
dumper3 busy : 0:16:13 ( 4.52%)
dumper4 busy : 0:06:40 ( 1.86%)
dumper5 busy : 0:03:39 ( 1.02%)
taper busy : 3:54:20 ( 65.26%)
0 dumpers busy : 0:03:21 ( 0.93%) file-too-large: 0:03:21 (100.00%)
1 dumper busy : 4:03:22 ( 67.78%) no-diskspace: 3:40:55 ( 90.77%)
file-too-large: 0:21:13 ( 8.72%)
no-bandwidth: 0:01:13 ( 0.50%)
2 dumpers busy : 0:17:33 ( 4.89%) no-bandwidth: 0:17:33 (100.00%)
3 dumpers busy : 0:07:42 ( 2.14%) no-bandwidth: 0:07:42 (100.00%)
4 dumpers busy : 0:02:05 ( 0.58%) no-bandwidth: 0:02:05 (100.00%)
5 dumpers busy : 0:00:40 ( 0.19%) no-bandwidth: 0:00:40 (100.00%)
6 dumpers busy : 0:03:33 ( 0.99%) not-idle: 0:01:53 ( 53.10%)
no-dumpers: 0:01:40 ( 46.90%)This says:
dumper 0 was busy almost all the time.
dumper 1 (and above) were not used very much.
taper was busy about two-thirds of the total runtime.
All dumpers were idle less than 1 percent of the total runtime.
One dumper was busy 67.78 percent of the total runtime, and the reason two dumpers were not started when one was busy was not enough holding disk space (
no-diskspace) 90.77 percent of that time, the next image to dump was too large to fit in the holding disk at all (file-too-large) 8.72 percent of that time, and network bandwidth was exhausted (no-bandwidth) 0.50 percent of that time.
This configuration would benefit from additional holding disk space, which would allow more dumpers to run at once and probably keep taper busy more of the time.
Other common status indicators are:
-
not-idle Everything is running that can be.
-
no-dumpers All dumpers are busy, and there are other dumps that could be started.
-
client-constrained The maximum number of dumpers for remaining clients are already running, or all spindles are already in use.
-
start-wait All remaining dumps are delayed until a specific time of day.
If the tape server machine has multiple tape drives, more than one AMANDA configuration may run at the same time. Clients and holding disks should be assigned to only one configuration, however.
AMANDA waits a fixed amount of time for a client
to respond with dump size estimates. The default is five minutes per
area on the client. For instance, if a client has four areas to back
up (entries in disklist),
AMANDA waits at most 20 minutes for the estimates.
During dumping,
AMANDA aborts a dump if the client stops sending
data for 30 minutes. Various conditions, such as slow clients, which
dump program is used and characteristics of the
area, may cause
timeouts. The values may
be changed with the amanda.conf
etimeout parameter for estimates and
dtimeout for data. Positive
etimeout values are multiplied by the number of
areas. The absolute value of a negative number is used for the whole
client regardless of the number of areas.
GNU tar can exclude
items from the dump image based on filename patterns controlled by
the dumptype
exclude
parameter. A single pattern may be put on the
exclude line itself, or multiple patterns may be
put in a file on the client. The
dumptype
exclude line in
that case includes a list keyword and the path to
the file.
Exclusion entries are shell-style wildcard expressions, except
* matches through any number of
/ characters. If a matched item is a directory, it
and all its contents are omitted. For instance:
-
./usr Omit the
usrdirectory at the top level of the area and everything under it.-
core Omit all items named
core.-
*/core* Omit all items starting with
core, e.g.,core,core19970114,corespondent, orcorexx/somefile(probably not a good idea).-
*/test*.c Omit all items starting with
testand ending with.c, e.g.,test.c,testing.c, ortestdir/pgm /main.c(probably not a good idea).-
*.o Omit all items ending with
.o.-
*/OLD/* Omit all items within directories named
OLD, including subdirectories and their contents, but dump theOLDdirectory entry itself.
Remember that no one cares if you can back up—only if you can restore.
One way to restore items with AMANDA is with
amrecover
on the client. Before
amrecover can work, AMANDA must
run with the
dumptype
index
parameter set to yes and the
amindexd and amidxtaped
services must be installed and enabled to inetd,
usually on the tape server machine (the default build sequence
installs them). Also, add the client to
.amandahosts (or .rhosts)
for the AMANDA user on the server machine. Since
amrecover must run as root on the client, the
entry must list root as the remote user, not the
AMANDA user. amrecover should
not be made
setuid-root because it would
open up catalogs of the entire system to everyone.
For this example, user jj has requested two files,
both named molecule.dat, in subdirectories named
work/sample-21 and
work/sample-22 and wants the versions last
modified on the 13th of January. Become root on the client,
cd to the area, and start
amrecover :
$suPassword: #cd ~jj#amrecover DailyAMRECOVER Version 2.4.1p1. Contacting server on amanda.cc.purdue.edu ... 220 amanda AMANDA index server (2.4.1p1) ready. 200 Access OK Setting restore date to today (1999-01-18) 200 Working date set to 1999-01-18. 200 Config set to Daily. 200 Dump host set to pete.cc.purdue.edu. $CWD '/home/pete/u66/jj' is on disk '/home/pete/u66' mounted at '/home/pete/u66'. 200 Disk set to /home/pete/u66. amrecover>
At this point, a command-line interface allows browsing the image catalogs. Move around with the cd command, see what is available with ls, change date with setdate, add files and directories to the extraction list with add, and so on. The extract command starts actual recovery:
amrecover>setdate ---14200 Working date set to 1999-01-14. amrecover>cd work/sample-21/home/pete/u66/jj/work/sample-21 amrecover>add molecule.datAdded /jj/work/sample-21/molecule.dat amrecover>cd ../sample-22/home/pete/u66/jj/work/sample-22 amrecover>add molecule.datAdded /jj/work/sample-22/molecule.dat amrecover>extractExtracting files using tape drive /dev/rmt/0mn on host amanda.cc.purdue.edu. The following tapes are needed: Daily-034 Restoring files into directory /home/pete/u66 Continue? [Y/n]:yLoad tape Daily-034 now Continue? [Y/n]:yWarning: ./jj: File exists Warning: ./work: File exists Warning: ./work/sample-21: File exists Warning: ./work/sample-22: File exists set owner/mode for '.'? [yn]namrecover>quit
amrecover finds which tapes contain the images, prompts through mounting them in the proper order, searches the tape for the image, optionally decompresses it, brings it across the network to the client, and pipes it into the appropriate restore program with the arguments needed to extract the requested items. amrecover does not know how to run every client restore program. See the amrecover manpage for current information. amrecover should not be used to do full filesystem recovery with vendor restore tools, but does work with GNU tar. Vendor tools should be run with the r flag for a full recovery, and amrecover is oriented toward extracting individual items with the x flag. Full filesystem recovery with vendor restore should be done with amrestore. amrecover (actually the amidxtaped server) does not know about tape changers, so mount the tapes by hand or use amtape if a changer is available.
The amrestore command retrieves whole images from tape. First, find which tapes have the desired images. The find suboption of amadmin generates output like this (abbreviated):
# su amanda -c "amadmin Daily find pete u66"
Scanning /amanda...
date host disk lv tape or file file status
...
1999-01-12 pete.cc.purdue.edu /home/pete/u66 1 Daily-032 14 OK
1999-01-13 pete.cc.purdue.edu /home/pete/u66 1 Daily-033 26 OK
1999-01-14 pete.cc.purdue.edu /home/pete/u66 1 Daily-034 40 OK
1999-01-15 pete.cc.purdue.edu /home/pete/u66 1 Daily-000 34 OK
1999-01-16 pete.cc.purdue.edu /home/pete/u66 1 Daily-001 31 OK
1999-01-17 pete.cc.purdue.edu /home/pete/u66 0 Daily-002 50 OK
1999-01-18 pete.cc.purdue.edu /home/pete/u66 1 Daily-003 20 OKThe Scanning
/amanda... message
says that amadmin looked in the holding disk (
/amanda) for any images left there. It then
lists all tapes or files in the holding disk that contain the
requested area.
The info suboption to amadmin shows tapes with the most recent images:
# su amanda -c "amadmin Daily info pete u66"
Current info for pete.cc.purdue.edu /home/pete/u66:
Stats: dump rates (kps), Full: 652.0, 648.0, 631.0
Incremental: 106.0, 258.0, 235.0
compressed size, Full: -100.0%,-100.0%,-100.0%
Incremental: -100.0%,-100.0%,-100.0%
Dumps: lev datestmp tape file origK compK secs
0 19990117 Daily-002 50 582239 582272 892
1 19990118 Daily-003 20 3263 3296 31
2 19981214 Daily-032 21 7039 7072 37Old information may appear, such as 19981214
(14-Dec-1998) in this example. While it’s true this was the
last level-2 dump of this area, it is of little interest because at
least one full and one level-1 dump have been done since then. The
compressed size values here may be ignored because this particular
configuration uses hardware compression so no software compression
data is available.
A third way to know what tape has an image is to generate a tape table of contents with amtoc after each AMANDA run:
# partition lvl size[Kb] method 0 Daily-002 - - 19990117 1 boiler.cc.purdue.edu:/usr/local 1 31 normal 2 egbert.cc.purdue.edu:/opt 1 127 normal 3 boiler.cc.purdue.edu:/usr 1 95 normal ... 50 pete.cc.purdue.edu:/home/pete/u66 0 582239 normal ...
A printed report similar to the amtoc output may
be generated automatically by amreport for each
run with the lbl-templ
tapetype parameter in
amanda.conf using the
example/3hole.ps template.
The find and info suboptions to
amadmin need the AMANDA
log files and database. These
usually are not large amounts of information and a copy should be
pushed after each amdump run to an alternate
machine that also has the AMANDA tape server
software installed so they are available if the primary tape server
machine dies. Tools like rdist (ftp://usc.edu/pub/rdist/)
or rsync (ftp://samba.anu.edu.au/pub/rsync/ ) are useful.
If AMANDA was built using
—with-db=text (the default), the database is
stored in a set of text files under the directory listed in the
infofile
amanda.conf
parameter. Here is the file that matches the info
amadmin output:
#cd /usr/local/etc/amanda/Daily/curinfo#cat pete.cc.purdue.edu/_home_pete_u66/infoversion: 0 command: 0 full-rate: 652.000000 648.000000 631.000000 full-comp: incr-rate: 106.000000 258.000000 235.000000 incr-comp: stats: 0 582239 582272 892 916549924 50 Daily-002 stats: 1 3263 3296 31 916637269 20 Daily-003 stats: 2 7039 7072 37 913614357 21 Daily-032 //
The first field of each stats line is the dump
level. The last field is the Volume Serial Number (VSN) and the field
just before it is the tape file number. The field with the large
number just before that is a Unix epoch time value, which may be
converted to text with this Perl script:
$cat epoch.pl#!/usr/local/bin/perl -w require 'ctime.pl'; foreach (@ARGV) { s/,//; if (m/[a-fA-FxX]/) { unless (m/^0[xX]/) { $_ = '0x' . $_; } $_ = oct; } print &ctime ($_); } exit (0); $epoch.pl 916549924Sun Jan 17 0:12:04 US/East-Indiana 1999
Prepositioning the tape to the image with mt fsf may significantly reduce the time needed to do a restore. Some media contains an index for very fast file searching compared to the one-file-at-a-time scanning done by amrestore. Each tape-location method listed previously also shows the tape file. Use that number with mt fsf after a rewind to position to a particular image.
amrestore takes client, area, and datestamp patterns as optional arguments to search for matching images. Each argument is a grep-style regular expression, so multiple images may match. This also means an image may need a specific pattern. For instance:
# amrestore $TAPE pete /finds not just the root area for the pete client
but images for any client with pete someplace in
the hostname and a slash anywhere in the area name. Assuming only one
client matches pete, the following gets just the
root area:
# amrestore $TAPE pete '^/$'The up arrow (caret) at the beginning says the pattern must start with this string. The dollar sign at the end says it must end there. The quote marks around the pattern protect the special characters from shell expansion.
Without flags, amrestore finds every matching image, uncompresses it if needed, and creates a disk file in the current working directory with a name made up of the client, area, and dump level. These images may be used directly by the client restore program.
amrestore may be used to generate a tape table of contents by giving it a host pattern that cannot match:
#mt rewind#amrestore $TAPE no.such.host
As it searches in vain for no.such.host, it reports images that are skipped:
amrestore: 0: skipping start of tape: date 19990117 label Daily-002 amrestore: 1: skipping boiler.cc.purdue.edu._.19990117.1 amrestore: 2: skipping egbert.cc.purdue.edu._opt.19990117.1 amrestore: 3: skipping boiler.cc.purdue.edu._.19990117.1 ...
For large images, the p flag writes the first match to standard output, which may then be piped into the client restore program. This flag also is useful for moving an image across the network. For instance, here is one way to restore a file directly from the tape server (amanda.cc.purdue.edu) while logged in to the client:
#rsh -n amanda.cc.purdue.edu amrestore -p $TAPE pete ''^/$' ' \| gtar xf - ./the-file
You may have to tell vendor restore programs to use a small blocking factor to handle the arbitrary size chunks of data available through a pipeline:
#rsh -n amanda.cc.purdue.edu amrestore -p $TAPE pete u66 \| ufsrestore -ivbf 2 -
The
AMANDA tape format is deliberately simple and data
can be restored without any AMANDA tools if
necessary. The first tape file is a volume label with the tape VSN
and date it was written. It is not in ANSI
VOL1 format but is plain text. Each file after
that contains one image using 32-KB blocks. The first block is an
AMANDA header with client, area, and options used
to create the image. As with the volume label, the header is not in
ANSI format but is plain text. The image follows, starting at the
next tape block, until end of file.
To retrieve an image with standard Unix utilities if amrestore is not available, position the tape to the image, then use dd to read it:
#mt rewind#mt fsfNN#dd if=$TAPE bs=32k skip=1 of=dump_image
The skip=1 option tells dd to skip over the AMANDA file header. Without the of= option, dd writes the image to standard output, which can be piped to the decompression program, if needed, and then to the client restore program.
Since the image header is text, it may be viewed with:
#mt rewind#mt fsfNN# dd if=$TAPE bs=32k count=1
In addition to describing the image, it contains text showing the
commands needed to do a restore. Here’s a typical entry for the
root filesystem on pete.cc.purdue.edu. It is a
level-1 dump done without compression using the vendor
ufsdump program:
AMANDA: FILE 19981206 pete.cc.purdue.edu / lev 1 comp N program /usr/sbin/ufsdump
To restore, position the tape at start of file and run:
dd if=$TAPE bs=32k skip=1 | /usr/sbin/ufsrestore -f... -As with any backup system, test these procedures while in normal production so the principles and techniques are familiar when disaster strikes .
Get Unix Backup and Recovery now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
