Provided by: amanda-server_2.4.5p1-2_i386 bug

NAME

       amanda - Advanced Maryland Automatic Network Disk Archiver

SYNOPSIS

       amadmin config command [options]

       amcheck [options] config

       amcheckdb config

       amcleanup config

       amdd [options]

       amdump config

       amflush [-f] config

       amgetconf [config] parameter

       amlabel config label [slot slot]

       ammt [options]

       amoverview config [options]

       amplot [options] amdump-files

       amrecover [config] [options]

       amreport [config] [options]

       amrestore [options] tapedevice [hostname [diskname]]

       amrmtape [options] config label

       amstatus config [options]

       amtape config command [options]

       amtapetype [options]

       amtoc [options] logfile

       amverify config

       amverifyrun config

DESCRIPTION

       AMANDA is the "Advanced Maryland Automatic Network Disk Archiver". This
       manual page gives an overview of the AMANDA commands and  configuration
       files for quick reference.

       Here are all the AMANDA commands. Each one has its own manual page. See
       them for all the gory details.

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

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

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

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

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

       amlabel
              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).

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

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

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

       amverify
              Check AMANDA backup tapes for errors.

       amrmtape
              Delete a tape from the AMANDA databases.

       amstatus
              Report the status of a running or completed amdump.

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

       amplot Generate  utilization  plots  of  AMANDA  runs  for  performance
              tuning.

       amreport
              Generate an AMANDA summary E-mail report.

       amtoc  Generate table of content files for AMANDA tapes.

       amcheckdb
              Verify every tape  AMANDA  knows  about  is  consistent  in  the
              database.

       amgetconf
              Look up parameters in the AMANDA configuration file.

       amtapetype
              Generate a tapetype definition.

CONFIGURATION

       There  are  three  user-editable  files  that  control  the behavior of
       AMANDA.

       The first is amanda.conf, the  main  configuration  file.  It  contains
       parameters   to   customize   AMANDA   for   the  site.  Refer  to  the
       amanda.conf(5), manpage for details on AMANDA configuration parameters.

       Second  is  the disklist file, which lists hosts and disk partitions to
       back up.

       Third is the tapelist  file,  which  lists  tapes  that  are  currently
       active.  These  files  are  described  in  more detail in the following
       sections.

       All files are stored  in  individual  configuration  directories  under
       /usr/local/etc/amanda/.   A   site   will  often  have  more  than  one
       configuration. For example, it might have a  normal  configuration  for
       everyday  backups  and  an  archive  configuration  for infrequent full
       archival  backups.  The  configuration  files  would  be  stored  under
       directories              /usr/local/etc/amanda/normal/              and
       /usr/local/etc/amanda/archive/, respectively. Part of  the  job  of  an
       AMANDA   administrator  is  to  create,  populate  and  maintain  these
       directories.

       All log and database files generated  by  AMANDA  go  in  corresponding
       directories  somewhere.  The exact location is controlled by entries in
       amanda.conf. A typical location would be under /var/adm/amanda. For the
       above  example,  the  files  might  go  in  /var/adm/amanda/normal/ and
       /var/adm/amanda/archive/.

       As  log  files  are  no  longer  needed  (no  longer  contain  relevant
       information),  AMANDA cycles them out in various ways, depending on the
       type of file.

       Detailed information about  amdump  runs  are  stored  in  files  named
       amdump.NN  where  NN is a sequence number, with 1 being the most recent
       file. Amdump rotates these files each run,  keeping  roughly  the  last
       tapecycle (see below) worth of them.

       The  file  used  by  amreport  to  generate  the  mail summary is named
       log.YYYYMMDD.NN where YYYYMMDD is the datestamp of  the  start  of  the
       amdump run and NN is a sequence number started at 0. At the end of each
       amdump run, log files for runs whose tapes have been reused are renamed
       into a subdirectory of the main log directory (see the logdir parameter
       below) named oldlog. It is up to the  AMANDA  administrator  to  remove
       them from this directory when desired.

       Index  (backup image catalogue) files older than the full dump matching
       the oldest backup image for a given client  and  disk  are  removed  by
       amdump at the end of each run.

DISKLIST FILE

       The  disklist  file determines which disks will be backed up by AMANDA.
       The file usually contains one line per disk:

       hostname diskname [diskdevice] dumptype [spindle [interface] ]

       All pairs [ hostname diskname ] must be unique.

       Lines starting with # are ignored, as are blank lines. The fields  have
       the following meanings:

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

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

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

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

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

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

       Instead  of  naming  a  dumptype, it is possible to define one in-line,
       enclosing dumptype options within curly braces, one per line, just like
       a  dumptype definition in amanda.conf. Since pre-existing dumptypes are
       valid option names, this syntax may be used to customize dumptypes  for
       particular disks.

       A line break must follow the left curly bracket.

       For  instance,  if  a dumptype named normal is used for most disks, but
       use of the holding disk needs to be disabled for the file  system  that
       holds it, this would work instead of defining a new dumptype:

       hostname diskname [ diskdevice ] {
         normal
         holdingdisk no
       } [ spindle [ interface ] ]

TAPE MANAGEMENT

       The  tapelist  file contains the list of tapes in active use. This file
       is maintained entirely by AMANDA and should not be  created  or  edited
       during normal operation. It contains lines of the form:

       YYYYMMDD label flags

       Where  YYYYMMDD  is the date the tape was written, label is a label for
       the tape as written by amlabel and flags tell AMANDA whether  the  tape
       may be reused, etc (see the reuse options of amadmin).

       Amdump  and  amflush will refuse to write to an unlabeled tape, or to a
       labeled tape that is considered active. There must  be  more  tapes  in
       active  rotation  (see the tapecycle option) than there are runs in the
       backup cycle (see the dumpcycle option) to prevent overwriting a backup
       image that would be needed to do a full recovery.

OUTPUT DRIVERS

       The  normal value for the tapedev parameter, or for what a tape changer
       returns, is a full path name to a non-rewinding tape  device,  such  as
       /dev/nst0  or  /dev/rmt/0mn  or /dev/nst0.1 or whatever conventions the
       operating system uses. AMANDA  provides  additional  application  level
       drivers  that  support non-traditional tape-simulations or features. To
       access a specific output driver, set tapedev (or configure your changer
       to  return) a string of the form driver:driver-info where driver is one
       of  the  supported  drivers  and  driver-info  is  optional  additional
       information needed by the driver.

       The supported drivers are:

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

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

              Note

              This driver should only be used for debugging and  testing,  and
              probably only with the record option set to no.

       rait   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

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

AUTHORIZATION

       AMANDA processes on the tape server  host  run  as  the  dumpuser  user
       listed in amanda.conf. When they connect to a backup client, they do so
       with an AMANDA-specific protocol. They do not, for instance, use rsh or
       ssh directly.

       On  the  client side, the amandad daemon validates the connection using
       one of several methods, depending on how it was compiled and on options
       it is passed:

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

       .amandahosts
              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 ]

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

       Kerberos
              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.fi
              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.

HOST & DISK EXPRESSION

       All  host  and  disk arguments to programs are special expressions. The
       command applies to all disks that match your  arguments.  This  section
       describes the matcher.

       The  matcher matches by word, each word is a glob expression, words are
       separated by the separator ’.’ for host  and  ’/’  for  disk.  You  can
       anchor the expression at left with a ’^’. You can anchor the expression
       at right with a ’$’. The matcher is case insensitive for  host  but  is
       case  sensitive  for  disk.  A  match  succeeds  if  all  words in your
       expression match  contiguous  words  in  the  host  or  disk.   .  word
       separator for a host/ word separator for a disk^ anchor at left$ anchor
       at right? match exactly one character except the separator* match  zero
       or  more characters except the separator**match zero or more characters
       including the separator

DATESTAMP EXPRESSION

       A datestamp expression is a range expression where we  only  match  the
       prefix.  Leading  ^  is  removed.  Trailing  $  forces  an exact match.
       20001212-14match  all  dates  beginning  with  20001212,  20001213   or
       2000121420001212-4same  as  previous20001212-24match  all dates between
       20001212 and 200012242000121match all dates  that  start  with  2000121
       (20001210-20001219)2match    all    dates    that    start    with    2
       (20000101-29991231)2000-10match        all        dates         between
       20000101-20101231200010$match only 200010

AUTHOR

       James da Silva, <jds@amanda.org> : Original text

       Stefan    G.    Weichinger,   <sgw@amanda.org>,   maintainer   of   the
       AMANDA-documentation: XML-conversion, major update

SEE ALSO

        amadmin(8), amanda.conf(5),  amcheck(8),  amcheckdb(8),  amcleanup(8),
       amdd(8),  amdump(8),  amflush(8),  amgetconf(8),  amlabel(8),  ammt(8),
       amoverview(8),  amplot(8),  amrecover(8),  amreport(8),   amrestore(8),
       amrmtape(8),    amstatus(8),    amtape(8),   amtapetype(8),   amtoc(8),
       amverify(8), amverifyrun(8)

                                                                     AMANDA(8)