-
- 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