--- /dev/null
+
+ Chapter 15. Using AMANDA
+Prev Part IV. Various Information Next
+
+-------------------------------------------------------------------------------
+
+Chapter 15. Using AMANDA
+
+
+John R. Jackson
+
+Original text
+AMANDA Core Team
+<jrj@purdue.edu>
+
+Gavin Henry
+
+XML-conversion
+Suretec Systems Ltd.
+<ghenry@suretecsystems.com>
+
+Stefan G. Weichinger
+
+XML-conversion, Updates
+AMANDA Core Team
+<sgw@amanda.org>
+Table of Contents
+
+
+ An_Introduction
+
+ AMANDA_Features
+
+ Future_Capabilities_of_AMANDA
+
+ AMANDA_Resources
+
+ Installing_AMANDA
+
+
+ Install_Related_Packages
+
+ Perform_Preliminary_Setup
+
+ Configure_the_AMANDA_Build
+
+ Build_and_Install_AMANDA
+
+ Configuring_AMANDA
+
+ Decide_on_a_Tape_Server
+
+ Decide_Which_Tape_Devices_to_Use
+
+ Decide_Whether_to_Use_Compression
+
+ Decide_Where_the_Holding_Space_Will_Be
+
+ Compute_Your_Dump_Cycle
+
+ Copy_and_Edit_the_Default_Configuration_File
+
+ Configure_the_Holding_Disk
+
+ Configure_Tape_Devices_and_Label_Tapes
+
+ Configure_Backup_Clients
+
+ Test_and_Debug_Setup
+
+
+ Operating_Amanda
+
+
+ Run_amdump
+
+ Read_AMANDA's_Reports
+
+ Monitor_Tape_and_Holding_Disk_Status
+
+ Adding_Tapes_at_a_Particular_Position_in_the_Cycle
+
+ Miscellanous_Operational_Notes
+
+
+ Advanced_AMANDA_Configuration
+
+
+ Adjust_the_Backup_Cycle
+
+ Adjust_Parallelism
+
+ Monitor_for_Possible_Improvements
+
+ Excluding_Files
+
+
+ Restoring_with_AMANDA
+
+
+ Configuring_and_Using_amrecover
+
+ Using_amrestore
+
+ Restoring_Without_AMANDA
+
+
+
+Note
+
+Refer to http://www.amanda.org/docs/using.html for the current version of this
+document.
+
+An Introduction
+
+
+Note
+
+This chapter was written by John R. Jackson with input from Alexandre Oliva. It
+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
+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
+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
+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 can also use SAMBA to back
+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
+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 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
+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.
+
+Note
+
+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
+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
+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
+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 Features
+
+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,
+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 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
+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 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
+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/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 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
+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
+ 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
+ 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 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
+(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
+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 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
+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
+catalogues easier when recovering individual files.
+
+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
+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
+ 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
+ and post-dump 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 non-
+ tape media such as CD-ROM, local files, remote files via tools like rcp and
+ ftp, remote tapes, etc. It will also 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-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
+ 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
+ the time file-n is written.
+
+
+AMANDA Resources
+
+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 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
+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
+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 e-mail
+ reports, debugging and log files
+* Anything unusual or recent changes to the environment
+* A valid return e-mail address
+
+Finally, the docs directory in the release contains several files with helpful
+information, such as a FAQ.
+
+Installing AMANDA
+
+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.
+
+Install Related Packages
+
+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.
+
+ 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.
+
+ 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
+ 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
+ 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.
+
+ 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.
+
+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.
+
+Perform Preliminary Setup
+
+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.
+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.
+
+Configure the AMANDA Build
+
+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 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
+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.
+
+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
+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 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.
+The others are utility routines optionally used on the clients, depending on
+the dump program used and operating system type.
+
+
+ sbin/amcheck
+ AMANDA sanity checker program
+
+ libexec/dumper
+ Client communication program
+
+ libexec/planner
+ Estimate gathering program
+
+ libexec/killpgrp
+ Used to kill vendor dump programs that run as root
+
+ libexec/rundump
+ Setuid wrapper for systems that need to run the vendor dump program as
+ root
+
+ libexec/runtar
+ 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
+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 can sometimes 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 re-installing it after
+the underlying operating system version changes. Gcc is particularly sensitive
+to system header files and must be re-installed 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 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 /
+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 nowait Amanda /PATH/libexec/amindexd amindexd
+amidxtape stream tcp nowait Amanda /PATH/libexec/amidxtaped amidxtaped
+The amandaidx service provides access to the catalogues, 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.
+
+Configuring AMANDA
+
+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
+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
+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.
+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 GBytes / 7 = 14.3 GB
+ 100 GBytes / 7 * 5% = 0.7 GB
+ 100 GBytes / 7 * 5% * 2 = 1.4 GB
+ 100 GBytes / 7 * 5% * 3 = 2.1 GB
+ 100 GBytes / 7 * 5% * 4 = 2.9 GB
+ 100 GBytes / 7 * 5% * 5 = 3.6 GB
+ 100 GBytes / 7 * 5% * 6 = 4.3 GB
+ = 29.3 GB
+
+
+If 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.
+
+Decide Which Tape Devices to Use
+
+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
+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.
+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
+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
+how hardware compression is controlled; on many systems it is done via the
+device file name just like the non-rewinding flag. AIX uses the chdev command.
+
+Decide Where the Holding Space Will Be
+
+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
+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 tune the
+space allocated.
+
+Compute Your Dump Cycle
+
+ 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 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
+"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-
+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 * one tape/run). Using two tapes per
+run needs 30 tapes (14+1 runs * two tapes/run). Doing backups just on weekdays
+with a dump cycle of two weeks, runs per cycle of 10, and two tapes per run
+needs 22 tapes (10+1 runs * two 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.
+
+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.
+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
+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 man page. 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 e-mail reports.
+
+ mailto
+ Target address for AMANDA e-mail 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:
+
+
+ infofile
+ 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.
+
+ indexdir
+ 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
+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 2GB
+need a chunk size slightly smaller, such as 2000 MB, so the holding disk can
+still 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 GBytes.
+
+Configure Tape Devices and Label Tapes
+
+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 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
+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 backwards, 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, gravity must also 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, needeject must 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 slot is 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 may also 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.conf
+ file 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 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"
+
+
+
+
+Configure Backup Clients
+
+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 are usually 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 may also deal with active filesystems better than vendor dump programs, 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 GNU-zip 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 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
+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 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
+name, (/dev/rsd0)a, 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 host name 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 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.
+
+Test and Debug Setup
+
+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 man
+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
+ entries:
+
+Example 15.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 udp
+ amanda/udp: 10080
+ $ a.out amandaidx
+ amandaidx/tcp: 10082
+ $ a.out amidxtape
+ amidxtape/tcp: 10083
+
+
+
+
+* Is there a line in the inetd configuration file on the client to start
+ 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.
+* 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
+ 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.
+
+Operating 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
+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
+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.
+* 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.
+ 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
+ inparallel amanda.conf parameter) 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 who
+ writes it, possibly via the server compression program, into the holding disk
+ or directly to a taper connection. If enabled, dumper also collects catalogue
+ information generated on the client and compresses it into the indexdir area.
+ 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 e-mail report. It
+ also renames the log file for the run to a unique log.YYYYMMDD.N name.
+* Old amdump.NN debug log files are rolled so only enough to match the tape
+ cycle are retained.
+* 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
+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.
+
+Read AMANDA's Reports
+
+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.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
+ 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 3.5 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 one 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% of the length of the tape as defined in the tapetype was
+used (remember that two tapes were written), 120% for full dumps and 17% for
+partials. The Rate lines give the dump speed from client to tape server and
+tape writing speed, all in KBytes 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 disklist entries for j.cc.purdue.edu and mace.cc.purdue.edu.
+* Tape Daily-012 is due to be overwritten in two more runs and contains the
+ most recent full dump of /src from mace.cc.purdue.edu, so the tape cycle may
+ not be large enough.
+* The next scheduled full dump of /var on loader.cc.purdue.edu was moved up two
+ days to improve the load balance.
+* The partial dump of /var on 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 KBytes 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 6201216 KBytes 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 425 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 character. 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), 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
+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
+run once a day, the following command would do the job:
+
+
+ #find log.????????.* -mtime +40 -print | xargs rm
+
+
+
+If --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.
+
+Monitor Tape and Holding Disk Status
+
+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 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
+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-
+mail 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.
+
+Adding Tapes at a Particular Position in the Cycle
+
+
+* Run amlabel on the new tapes.
+* Edit the tapelist file by hand and move the new tapes before the tape to be
+ used just ahead of them. For instance, move Daily-100 before Daily-099.
+* Set the date stamp on the new tapes to the same as the previous tape, e.g.
+ 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
+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.
+
+Miscellanous Operational Notes
+
+Multiple amdump runs may be made in the same day, although catalogues are
+currently 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 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
+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 \14 that must be done by hand.
+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.
+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 catalogue 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.
+
+Advanced AMANDA Configuration
+
+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:
+
+
+ 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 e-mail server or a database
+area), create a dumptype based on another dumptype with attributes changed as
+desired (client dump program, compression, etc) 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 non-full 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 "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
+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 one. 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 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
+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.
+
+Monitor for Possible Improvements
+
+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 2/3 of the total run time.
+* All dumpers were idle less than 1% of the total runtime.
+* One dumper was busy 67.78% of the total run time and the reason two dumpers
+ were not started when one was busy was not enough holding disk space (no-
+ diskspace) 90.77% of that time, the next image to dump was too large to fit
+ in the holding disk at all (file-too-large) 8.72% of that time and network
+ bandwidth was exhausted (no-bandwidth) 0.50% 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.
+
+Excluding Files
+
+GNU-tar can exclude items from the dump image based on file name 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 usr directory 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,
+ or corexx/somefile (probably not a good idea).
+
+ */test*.c
+ Omit all items starting with test and ending with .c, e.g. test.c,
+ testing.c or testdir/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 the OLD directory entry itself.
+
+
+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
+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 catalogues 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 said they want the
+versions last modified on the 13th of January. Become root on the client, cd to
+the area and start amrecover:
+
+
+ $ su
+ Password:
+ # cd ~jj
+ # amrecover Daily
+ AMRECOVER 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 catalogues.
+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 ---14
+ 200 Working date set to 1999-01-14.
+ amrecover> cd work/sample-21
+ /home/pete/u66/jj/work/sample-21
+ amrecover> add molecule.dat
+ Added /jj/work/sample-21/molecule.dat
+ amrecover> cd ../sample-22
+ /home/pete/u66/jj/work/sample-22
+ amrecover> add molecule.dat
+ Added /jj/work/sample-22/molecule.dat
+ amrecover> extract
+ Extracting 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]: y
+
+ Load tape Daily-034 now
+ Continue? [Y/n]: y
+ Warning: ./jj: File exists
+ Warning: ./work: File exists
+ Warning: ./work/sample-21: File exists
+ Warning: ./work/sample-22: File exists
+ set owner/mode for '.'? [yn] n
+ amrecover> 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.
+
+Using amrestore
+
+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
+ OK
+
+
+
+The Scanning /amanda... message says 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 37
+
+
+
+Old 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 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 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:
+
+
+ # 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 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.
+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
+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 above info amadmin output:
+
+
+ # cd /usr/local/etc/amanda/Daily/curinfo
+ # cat pete.cc.purdue.edu/_home_pete_u66/info
+ version: 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 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
+ use warnings;
+ use strict;
+ require 'ctime.pl';
+ foreach (@ARGV) {
+ s/,//;
+ if (m/[a-fA-FxX]/) {
+ unless (m/^0[xX]/) {
+ $_ = '0x' . $_;
+ }
+ $_ = oct;
+ }
+ print &ctime ($_);
+ }
+ exit (0);
+ $ epoch.pl 916549924
+ Sun 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 contain an index for very fast file
+searching compared to the one file at a time scanning done by amrestore. Each
+tape location method listed above 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 date stamp 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 is also 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
+
+
+
+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 -
+
+
+
+
+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
+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
+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 fsf NN
+ # 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 fsf NN
+ # 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.
+-------------------------------------------------------------------------------
+
+Prev Up Next
+Part IV. Various Information Home Chapter 16. AMANDA FAQ
+
projects / debian / amanda / blobdiff