- Chapter 16. Using AMANDA
+ Chapter 18. Using Amanda
Prev Part IV. Various Information Next
-------------------------------------------------------------------------------
-Chapter 16. Using AMANDA
+Chapter 18. Using Amanda
John R. Jackson
An_Introduction
- AMANDA_Features
+ Amanda_Features
- Future_Capabilities_of_AMANDA
+ Future_Capabilities_of_Amanda
- AMANDA_Resources
+ Amanda_Resources
- Installing_AMANDA
+ Installing_Amanda
Install_Related_Packages
Perform_Preliminary_Setup
- Configure_the_AMANDA_Build
+ Configure_the_Amanda_Build
- Build_and_Install_AMANDA
+ Build_and_Install_Amanda
- Configuring_AMANDA
+ Configuring_Amanda
Decide_on_a_Tape_Server
Run_amdump
- Read_AMANDA's_Reports
+ Read_Amanda's_Reports
Monitor_Tape_and_Holding_Disk_Status
Miscellanous_Operational_Notes
- Advanced_AMANDA_Configuration
+ Advanced_Amanda_Configuration
Adjust_the_Backup_Cycle
Excluding_Files
- Restoring_with_AMANDA
+ Restoring_with_Amanda
Configuring_and_Using_amrecover
Using_amrestore
- Restoring_Without_AMANDA
+ Restoring_Without_Amanda
is part of the O'Reilly book "Unix Backup & Recovery" by W. Curtis Preston and
has been provided online at http://www.backupcentral.com/amanda.html since the
first edition of this book.
-During the Docbook-conversion of the AMANDA-docs we asked for permission to
-include this chapter in the Official AMANDA documentation and W. Curtis Preston
+During the Docbook-conversion of the Amanda-docs we asked for permission to
+include this chapter in the Official Amanda documentation and W. Curtis Preston
allowed to us to include the now converted version. There will be some updates
to this chapter in the next few months to reflect various changes and
enhancements.
You can find online versions of this chapter at http://www.amanda.org/docs/
using.html and at http://www.backupcentral.com/amanda.html.
-AMANDA, the Advanced Maryland Automated Network Disk Archiver, is a public
+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. AMANDA allows
+free backup utility gets, and has quite a large user community. 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
+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 can also use SAMBA to back
-up Microsoft Windows (95/98/NT/2000)-based hosts. More information about AMANDA
+up Microsoft Windows (95/98/NT/2000)-based hosts. More information about Amanda
can be found at http://www.amanda.org
-AMANDA was written primarily by James da Silva at the Department of Computer
+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
+Amanda was driven by the introduction of large capacity tape drives, such as
ExaByte 8mm and DAT 4mm. 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
Note
-Since AMANDA is optimized to take advantage of tape drives, we will use the
+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\19t
use it with an optical or CD-R drive.
-The AMANDA approach is to use a "holding disk" on the tape server machine, do
+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
+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
takes that information, statistics about past dump performance, and estimates
on 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 run time
+client A" approach and frees Amanda to balance the dumps so the total run time
is roughly constant from day to day.
-AMANDA is freely-available software maintained by the AMANDA Users Group. Based
-on membership of AMANDA-related mailing lists, there are probably well over
-1500 sites using it. This chapter is based on AMANDA version 2.4.2. Updated
-versions of this section will be available with the AMANDA source code.
+Amanda is freely-available software maintained by the Amanda Users Group. Based
+on membership of Amanda-related mailing lists, there are probably well over
+1500 sites using it. This chapter is based on Amanda version 2.4.2. Updated
+versions of this section will be available with the Amanda source code.
-AMANDA Features
+Amanda Features
-AMANDA is designed to handle large numbers of clients and data, yet is
+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 is
also 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,
+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
+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 catalogue 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
+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
+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
+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
+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 are usually 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
+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
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/rexec
-are not themselves used). AMANDA works well with security tools like TCP
+is used, or Amanda may be configured to use .rhosts (although rsh/rlogin/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
+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
+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 where 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
+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, such as taking full dumps to a vault away from the
primary site.
-* Incremental-only backups where full dumps are done outside of AMANDA, such as
+* Incremental-only backups where full dumps are done outside of Amanda, such as
very active areas that must be taken offline, or no full dumps at all for
areas that can easily be recovered from vendor media.
* Always doing full dumps, such as database areas that change completely
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 of full dumps is typically left up to AMANDA. They are scattered
+Scheduling of 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
+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 is also left to AMANDA. History information about
+The partial backup level is also 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
+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 can also be told to not reuse
+Amanda has issued several warnings. Amanda can also 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 e-mail after each run. AMANDA can also send a report to a printer
+is sent via e-mail after each run. Amanda can also 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
+reasons, Amanda does not support user controlled file recovery. There is an
ftp-like restore utility for administrators to make searching online dump
catalogues easier when recovering individual files.
-Future Capabilities of AMANDA
+Future Capabilities of Amanda
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
+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 (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
+* 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 will also add optional pre-dump
* In addition, the output format will be enhanced to include a file-1 and a
file-n. The idea is to put site-defined emergency recovery tools in file-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
+ non-Amanda programs like tar, then use those tools to retrieve the rest of
the data. The file-n area 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
+ items such as the Amanda database, which would be complete and up to date by
the time file-n is written.
-AMANDA Resources
+Amanda Resources
-AMANDA may be obtained via the web page http://www.amanda.org or with anonymous
+Amanda may be obtained via the web page http://www.amanda.org 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 pre-
releases have a names like amanda-2.5.0b3.tar.gz (third beta test pre-release
of 2.5.0).
-Some operating system distributions provide pre-compiled versions of AMANDA,
-but because AMANDA hardcodes some values into the programs, they may not match
+Some operating system distributions provide pre-compiled 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 run-time
-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
+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
+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
+* Amanda version
* OS version on the server and client(s)
* Exact symptoms seen, such as error messages, relevant sections of e-mail
reports, debugging and log files
Finally, the docs directory in the release contains several files with helpful
information, such as a FAQ.
-Installing AMANDA
+Installing Amanda
-After downloading and unpacking the AMANDA release, read the README, docs/
+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.
+information about how to set up Amanda.
Install Related Packages
-Several other packages may be required to complete an AMANDA install. Before
+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 \14 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.
+ programs Amanda knows how to use.
Samba 1.9.18p10 or later \14 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.
+ smbclient, that Amanda can use to back them up.
Perl 5.004 or later \14 www.perl.org
Perl is a scripting programming language oriented toward systems
- programming and text manipulation. It is used for a few optional AMANDA
+ 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 \14 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
+ provide command-line history and editing. It is built into the Amanda
amrecover restoration tool, if available.
GNU awk 3.0.3 or later \14 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.
+ optional Amanda amplot statistics tool.
Gnuplot 3.5 or later \14 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.
+ optional Amanda amplot statistics tool.
-Be sure to look in the AMANDA patches directory and the patches section on the
+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
+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.
Perform Preliminary Setup
-A typical AMANDA configuration runs as a user other than root, such as backup
+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.
+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)
+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.
-To use GNU-tar, AMANDA runs it under a setuid-root program that grants the
-needed permissions. The GNU version of tar must be used with AMANDA. Vendor
+To use GNU-tar, Amanda runs it 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.
+1.12) do not work because Amanda depends on additional features.
-Configure the AMANDA Build
+Configure the Amanda Build
-Use the AMANDA user and group for the --with-user and --with-group options to
+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
+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 are often necessary for tracking
down problems.
The normal build creates both tape server and client software. The tape server
-host is often backed up by AMANDA and needs the client parts. However, the
+host is often 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
+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: ./
+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.
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.
-Build and Install AMANDA
+Build and Install Amanda
-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
+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:
Libraries.
/usr/local/libexec
- Private programs only AMANDA uses.
+ Private programs only Amanda uses.
/usr/local/man
Documentation.
-Now is a good time to read the main AMANDA man page. It provides an overview of
-AMANDA, a description of each program, and detailed configuration information.
+Now is a good time to read the main Amanda man page. 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.
sbin/amcheck
- AMANDA sanity checker program
+ Amanda sanity checker program
libexec/dumper
Client communication program
Setuid wrapper to run GNU-tar as root
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
+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
+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
+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 can sometimes be diagnosed
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
+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 does not currently 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 wait Amanda /
+inetd.conf) like this, substituting the Amanda user for Amanda and the full
+path to the Amanda libexec directory for PATH: amanda dgram udp wait Amanda /
PATH/libexec/amandad amandad
-The amanda service is used by all AMANDA controlling programs to perform
+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 nowait Amanda /PATH/libexec/amindexd amindexd
change, send a HUP signal to the inetd process and check the system logs for
errors.
-Configuring AMANDA
+Configuring Amanda
-Once installed, AMANDA must be configured to your environment.
+Once installed, Amanda must be configured to your environment.
Decide on a Tape Server
-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
+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 does not typically 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 often full dumps will be done, Runs. Pick an
-estimated run-to-run change rate, Change. Each AMANDA run, on average, does a
+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* is done of areas that got a full
dump two runs ago, and so on.
Unix operating systems typically incorporate device characteristics into the
file name used to access a tape device. The two to be concerned with are
-"rewind" and "compression." AMANDA must be configured with the non-rewinding
+"rewind" and "compression." Amanda must be configured with the non-rewinding
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 or /dev/nst0. 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.
+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.
Decide Whether to Use Compression
Dump images may optionally be compressed on the client, the tape server, or the
-tape device hardware. Software compression allows AMANDA to track usage and
+tape device hardware. Software compression allows Amanda to track usage and
make better estimates of image sizes, but hardware compression is more
efficient of CPU resources. Turn off hardware compression when using software
compression on the client or server. See the operating system documentation for
Decide Where the Holding Space Will Be
-If at all possible, allocate some holding disk space for AMANDA on the tape
+If at all possible, allocate some holding disk space for Amanda on the tape
server. Holding disk space can significantly reduce backup time by 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
+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.
+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
+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 tune the
space allocated.
Compute Your Dump Cycle
- Decide how often AMANDA should do full dumps. This is the "dump cycle." Short
+ 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
+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
+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
+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 e-mail report if that is about to happen.
-By default, AMANDA assumes it is run every day. If that is not the case, set
+By default, Amanda assumes it is run every day. If that is not the case, set
"runs per cycle" (described below) 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-
+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
+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.
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
+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.
Copy and Edit the Default Configuration File
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 just the AMANDA user.
+directory (or perhaps its parent) should be restricted to the Amanda group or
+even just 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
non-printable 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
+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
+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 man page. There are many
org
- This string will be in the Subject line of AMANDA e-mail reports.
+ This string will be in the Subject line of Amanda e-mail reports.
mailto
- Target address for AMANDA e-mail reports.
+ Target address for Amanda e-mail reports.
dumpuser
Same as --with-user from ./configure.
Type of tape media.
netusage
- Network bandwidth allocated to AMANDA.
+ 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]
+ 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:
+values to know where Amanda expects to find things:
infofile
- Location of AMANDA history database. Older versions of AMANDA used this
+ Location of Amanda history database. Older versions of Amanda used this
as the base name of a database file. Newer versions use this as a
directory name.
logdir
- Directory where AMANDA logs are stored.
+ Directory where Amanda logs are stored.
indexdir
- Location of optional AMANDA catalogue database.
+ Location of optional Amanda catalogue database.
Configure the Holding Disk
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
+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
+Set a chunksize value for each holding disk. Positive numbers split dumps in
+the holding disk into chunks no larger than the chunksize value. Negative
+numbers are no longer supported. 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 2GB
Configure Tape Devices and Label Tapes
-AMANDA needs to know some characteristics of the tape media. This is set in a
+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
+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
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
+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.
+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-
+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
+The prompts normally go to the terminal of the person running Amanda, but the
changer may be configured to send requests via e-mail 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
+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
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.
+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
+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
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 pre-labeled with amlabel so AMANDA can verify the tape is one it
-should use. Run amlabel as the AMANDA user, not root. For instance:
+Tapes must be pre-labeled with amlabel so Amanda can verify the tape is one it
+should use. Run amlabel as the Amanda user, not root. For instance:
# su amanda -c "amlabel Daily Daily-123 slot 123"
The indexing facility generates a compressed catalogue 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
-catalogues to use a lot of disk space. AMANDA automatically removes catalogues
+catalogues to use a lot of disk space. Amanda automatically removes catalogues
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
+readable by the Amanda user. Each line in disklist defines an area to be backed
up. The first field is the client host name (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
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
+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 host name and AMANDA user,
-separated by a blank or tab. Make sure the file is owned by the AMANDA user and
+depending on what was set with ./configure) in the Amanda user home directory
+on the client. Enter the fully qualified tape server host name 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 only allow user access. By default, AMANDA uses SAMBA user backup.
-This can be changed with --with-samba-user to ./configure.
+password and the optional third field is the domain.
+
+Note
+
+This info isn't correct anymore. Please refer to Backup_PC_hosts_using_Samba
+for details on this file.
+Because this file contains clear text passwords, it should be carefully
+protected, owned by the Amanda user and only allow user access. By default,
+Amanda uses SAMBA user backup. This can be changed with --with-samba-user to ./
+configure.
Test and Debug Setup
-Test the setup with amcheck. As with all AMANDA commands, run it as the AMANDA
+Test the setup with amcheck. As with all Amanda commands, run it as the Amanda
user, not root:
Many errors reported by amcheck are described in docs/FAQ or the amcheck man
-page. The most common error reported to the AMANDA mailing lists is selfcheck
+page. The most common error reported to the Amanda mailing lists is selfcheck
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/services or a YP/NIS map? The
- C program in Figure 4-1 uses the same system call as AMANDA to look up
+* Are the Amanda services listed properly in /etc/services or a YP/NIS map? The
+ C program in Figure 4-1 uses the same system call as Amanda to look up
entries:
-Example 16.1. A C Program to Check the AMANDA Service Numbers
+Example 18.1. A C Program to Check the Amanda Service Numbers
#include <stdio.h>
amandad?
* Was inetd sent a HUP signal after the configuration file was changed?
* Are there system log messages from inetd about amanda or amandad? For
- instance, inetd complains if it cannot look up the AMANDA services.
+ instance, inetd complains if it cannot look up the Amanda services.
* Is /tmp/amanda/amandad/debug being 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
+* 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
+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
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
+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.
+should be protected when Amanda goes into production.
Operating Amanda
-Once configured, you will need to setup the automated use of AMANDA.
+Once configured, you will need to setup the automated use of Amanda.
Run amdump
-The amdump script controls a normal AMANDA backup run. However, it's common to
+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 the AMANDA
+documentation for how to set up a cron task. Be sure it runs as the Amanda
user, not root or the installer.
The amdump script does the following:
* If a file named hold is 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.
+ Amanda runs without having to change the cron task.
* If it looks like 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.
+* 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
* The amtrmidx program is run to remove old catalogues 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 e-mail report from the previous run. The tapes used
+There are several ways to determine which tapes Amanda will need for a run. One
+is to look at the Amanda e-mail 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
+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.
-Read AMANDA's Reports
+Read Amanda's Reports
-An AMANDA report has several sections:
+An Amanda report has several sections:
* gurgi.cc.purdue.edu was down, so all its backups failed.
* The /var/mail problem on pete.cc.purdue.edu and F$ problem on nt-
test.cc.purdue.edu are detailed later.
-* The /master area on mace.cc.purdue.edu is new to AMANDA so a full dump is
+* The /master area on mace.cc.purdue.edu is new to Amanda so a full dump is
required, but it would not fit in the available tape space for this run.
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
+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.
+will not be busy at the time Amanda runs.
NOTES:
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 character. This typically leaves the unique portions of both.
-Two log files are created during an AMANDA run. One is named amdump.NN, where
+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), and 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
+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 e-mail 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 automatically removed 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
+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:
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
+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 value of the
parameter reserve in amanda.conf below 100%.
A tape server crash may also leave images in the holding disks. Run amflush, as
-the AMANDA user, to flush images in the holding disk to the next tape after
+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 e-
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
+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
+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
+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.
make them the same for Daily-099 and Daily-100.
* Update the tapecycle amanda.conf parameter if new tapes are being added.
-These steps let AMANDA know about all tapes, including those that do not have
+These steps let Amanda know about all tapes, including those that do not have
data yet. 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.
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 the AMANDA user, not root. AMANDA automatically detects
+next run. Run this as the Amanda 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
+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
+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 \14 that must be done by hand.
-Non\14AMANDA backups may still be done with AMANDA installed, but do not let the
+Non\14Amanda 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.
+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
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
+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
+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.
-Advanced AMANDA Configuration
+Advanced Amanda Configuration
-Once you have AMANDA running for a while, you may choose to do some additional
+Once you have Amanda running for a while, you may choose to do some additional
advanced configuration.
Adjust the Backup Cycle
-Several dumptype parameters control the backup level AMANDA picks for a run:
+Several dumptype parameters control the backup level Amanda picks for a run:
dumpcycle
-To run full dumps by hand outside of AMANDA (perhaps they are too large for the
+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:
-Tell AMANDA when a full dump of the area has been done with the force suboption
+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 non-full backups.
To never do full dumps (such as an area easily regenerated from vendor media),
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
+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 "Operating AMANDA", so AMANDA
+Amanda run, or set the hold file as described in "Operating Amanda", so Amanda
does not try to process the same client from two configurations at the same
time.
Adjust Parallelism
-AMANDA starts several dumper processes and keeps as many as possible running at
+Amanda starts several dumper processes and keeps as many as possible running at
once. The following options control their activity:
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 above
-in "Configuring AMANDA": the limit is imposed when deciding whether to start a
-dump, but once a dump starts, AMANDA lets underlying network components do any
+in "Configuring Amanda": 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
+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
+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
+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.
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
+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
+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
+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
their contents, but dump the OLD directory entry itself.
-Restoring with AMANDA
+Restoring with Amanda
Remember that no one cares if you can back up ?only if you can restore.
Configuring and Using amrecover
-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
+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
+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
+must list root as the remote user, not the Amanda user. amrecover should not be
made setuid-root because it would open up catalogues of the entire system to
everyone.
For this example, user jj has requested two files, both named molecule.dat, in
# amrecover Daily
AMRECOVER Version 2.4.1p1.
Contacting server on amanda.cc.purdue.edu ...
- 220 amanda AMANDA index server (2.4.1p1) ready.
+ 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.
configuration uses hardware compression so no software compression data are
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:
+contents with amtoc after each Amanda run:
# partition lvl size[Kb] method
A printed report similar to the amtoc output may be automatically generated 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.
+The find and info suboptions to amadmin need the Amanda log files and database.
These are not usually large amounts of information and a copy should be pushed
-after each amdump run to an alternate machine that also has the AMANDA tape
+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
+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 above info amadmin output:
-Restoring Without AMANDA
+Restoring Without Amanda
-The AMANDA tape format is deliberately simple and restoring data can be done
-without any AMANDA tools if necessary. The first tape file is a volume label
+The Amanda tape format is deliberately simple and restoring data can be done
+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 KByte blocks.
-The first block is an AMANDA header with client, area and options used to
+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.
-The skip=1 option tells dd to skip over the AMANDA file header. Without the of=
+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:
- AMANDA: FILE 19981206 pete.cc.purdue.edu / lev 1
+ Amanda: FILE 19981206 pete.cc.purdue.edu / lev 1
comp N program /usr/sbin/ufsdump
-------------------------------------------------------------------------------
Prev Up Next
-Part IV. Various Information Home Chapter 17. AMANDA FAQ
+Part IV. Various Information Home Chapter 19. Amanda FAQ
projects / debian / amanda / blobdiff