Take care of automatic Amanda backups. This is normally executed by cron on a computer called the tape server host and requests backups of file systems located on backup clients. Amdump backs up all disks in the disklist file (discussed below) to tape or, if there is a problem, to a special holding disk. After all backups are done, amdump sends mail reporting failures and successes.

Flush backups from the holding disk to tape. Amflush is used after amdump has reported it could not write backups to tape for some reason. When this happens, backups stay in the holding disk. Run amflush after the tape problem is corrected to write backups from the holding disk to tape.

Clean up after an interrupted amdump. This command is only needed if amdump was unable to complete for some reason, usually because the tape server host crashed while amdump was running.

Provides an interactive interface to browse the Amanda index files (backup image catalogues) and select which tapes to recover files from. It can also run amrestore and a restore program (e.g. tar) to actually recover the files.

Read an Amanda tape, searching for requested backups. Amrestore is suitable for everything from interactive restores of single files to a full restore of all partitions on a failed disk.

Performs Amanda tape restoration, similar to amrestore. Additional capabilities include "hands-off" searching of multiple tapes, automatic retrieval of specific dump files based on dump logs, and assembly of tape-spanning split dump files.

Write an Amanda format label onto a tape. All Amanda tapes must be labeled with amlabel. Amdump and amflush will not write to an unlabeled tape (see TAPE MANAGEMENT below).

Verify the correct tape is mounted and all file systems on all backup client systems are ready to be backed up. Often run by cron before amdump to generate a mail warning that backups might fail unless corrective action is taken.

Take care of administrative tasks like finding out which tapes are needed to restore a filesystem, forcing hosts to do full backups of selected disks and looking at schedule balance information.

Take care of tape changer control operations like loading particular tapes, ejecting tapes and scanning the tape storage slots.

Check Amanda backup tapes for errors.

Delete a tape from the Amanda databases.

Report the status of a running or completed amdump.

Display a chart of hosts and file systems backed up every run.

Generate utilization plots of Amanda runs for performance tuning.

Generate an Amanda summary E-mail report.

Generate table of content files for Amanda tapes.

Verify every tape Amanda knows about is consistent in the database.

Look up parameters in the Amanda configuration file.

Generate a tapetype definition.

Wrapper program from aespipe (data encryption utility)

Reference encryption program for Amanda symmetric data encryption

The name of the host to be backed up. If diskdevice refers to a PC share, this is the host Amanda will run the Samba smbclient program on to back up the share.

The name of the disk (a label). In most case, you set your diskname to the diskdevice and you don't set the diskdevice. If you want multiple entries with the same diskdevice, you must set a different diskname for each entry. It's the diskname that you use on the commandline for any Amanda command. Look at the example/disklist file for example.

Default: same as diskname. The name of the disk device to be backed up. It may be a full device name, a device name without the /dev/ prefix, e.g. sd0a, or a mount point such as /usr.

It may also refer to a PC share by starting the name with two (forward) slashes, e.g. //some-pc/home. In this case, the program option in the associated dumptype must be entered as GNUTAR. It is the combination of the double slash disk name and program GNUTAR in the dumptype that triggers the use of Samba.

Refers to a dumptype defined in the amanda.conf file. Dumptypes specify backup related parameters, such as whether to compress the backups, whether to record backup results in /etc/dumpdates, the disk's relative priority, etc.

Default: -1. A number used to balance backup load on a host. Amanda will not run multiple backups at the same time on the same spindle, unless the spindle number is -1, which means there is no spindle restriction.

Default: local. The name of a network interface definition in the amanda.conf file, used to balance network load.

This is the default driver. The driver-info is the tape device name. Entering

tapedev /dev/rmt/0mn

is really a short hand for

tapedev tape:/dev/rmt/0mn

This driver throws away anything written to it and returns EOF for any reads except a special case is made for reading a label, in which case a "fake" value is returned that Amanda checks for and allows through regardless of what you have set in labelstr. The driver-info field is not used and may be left blank:

tapedev null:

The length value from the associated tapetype is used to limit the amount of data written. When the limit is reached, the driver will simulate end of tape.

Redundant Array of Inexpensive (?) Tapes. Reads and writes tapes mounted on multiple drives by spreading the data across N-1 drives and using the last drive for a checksum. See docs/RAIT for more information.

The driver-info field describes the devices to use. Curly braces indicate multiple replacements in the string. For instance:

tapedev rait:/dev/rmt/tps0d{4,5,6}n

would use the following devices:

/dev/rmt/tps0d4n /dev/rmt/tps0d5n /dev/rmt/tps0d6n

This driver emulates a tape device with a set of files in a directory. The driver-info field must be the name of an existing directory. The driver will test for a subdirectory of that named data and return offline until it is present. When present, the driver uses two files in the data subdirectory for each tape file. One contains the actual data. The other contains record length information.

The driver uses a file named status in the file device directory to hold driver status information, such as tape position. If not present, the driver will create it as though the device is rewound.

The length value from the associated tapetype is used to limit the amount of data written. When the limit is reached, the driver will simulate end of tape.

One way to use this driver with a real device such as a CD-writer is to create a directory for the file device and one or more other directories for the actual data. Create a symlink named data in the file directory to one of the data directories. Set the tapetype length to whatever the medium will hold.

When Amanda fills the file device, remove the symlink and (optionally) create a new symlink to another data area. Use a CD writer software package to burn the image from the first data area.

To read the CD, mount it and create the data symlink in the file device directory.

Even though Amanda does not use rsh, it can use .rhosts-style authentication and a .rhosts file.

This is essentially the same as .rhosts authentication except a different file, with almost the same format, is used. This is the default mechanism built into Amanda.

The format of the .amandahosts file is:

hostname [ username [ service ]*]

If username is ommitted, it defaults to the user running amandad, i.e. the user listed in the inetd or xinetd configuration file.

The service is a list of the service the client is authorized to execute: amdump, noop, selfcheck, sendsize, sendbackup, amindexd, amidxtaped. amdump is a shortcut for "noop selfcheck sendsize sendbackup"

Amanda may use the Kerberos authentication system. Further information is in the docs/KERBEROS file that comes with an Amanda distribution.

For Samba access, Amanda needs a file on the Samba server (which may or may not also be the tape server) named /etc/amandapass with share names, (clear text) passwords and (optional) domain names, in that order, one per line, whitespace separated. By default, the user used to connect to the PC is the same for all PC's and is compiled into Amanda. It may be changed on a host by host basis by listing it first in the password field followed by a percent sign and then the password. For instance:

  //some-pc/home normalpw
  //another-pc/disk otheruser%otherpw

With clear text passwords, this file should obviously be tightly protected. It only needs to be readable by the Amanda-user on the Samba server.

You can find further information in the docs/SAMBA file that comes with an Amanda distribution.