This is an excerpt from the book Unix Backup & Recovery.  This page is only part of the AMANDA chapter that is available here for free.

AMANDA Features

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.

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.
 

Last Section

Table of Contents

Next section

Copyright (c) 2000, O'Reilly and Associates.  All Rights Reserved.