Enterprise Edition Documentation

Version as of 14:50, 4 Jun 2026

to this version.

Return to Version archive.

View current version

Amanda Enterprise edition is a certified Amanda network backup software supported on various platforms. This document has been prepared in conjunction with Amanda enterprise edition 2.5 release.

Amanda Enterprise edition packages are available for the following platforms in the Zmanda network:

  • Redhat Enterprise Linux 4.0
  • Suse Enterprise Linux 9.0
  • Fedora Core 3
  • Fedora Core 4
  • Open Suse 10

Source package and tar ball is also available for downloads in Zmanda network. Amanda enterprise edition supports Windows platforms using Samba software.

This document discuss the Amanda enterprise installation and configuration procedures. The feature differences between Amanda enterprise and Amanda community edition and how to use these features are also discussed in the documentation. This document refers to Amanda community edition documentation available in the Zmanda wiki for general Amanda configuration, administration tools and processes.

Installation

Amanda enterprise edition 2.5 release RPMs are available under Zmanda Network Downloads page. There are two binary packages available for each platform.

Amanda server RPM (amanda_enterprise-backup_server)
This RPM package should be installed on the Amanda server. Amanda server is the host that has the backup media attached to it. Amanda server package contains binaries for Amanda server and binaries for a host protected by Amanda (Amanda client).
Amanda client RPM (amanda_enterprise-backup_client)
This RPM should be installed on all systems that is protected by Amanda (Amanda client)

All packages that Amanda RPMs depends on are also available from Zmanda Network downloads. The host may already contain a different or the same version of these packages. It is recommended that the RPM packages for Amanda dependencies are installed from Zmanda network. Amanda RPMs have been extensively tested with these dependency RPM versions.

Amanda dependency RPMs are available for the following dependencies:

GNU tar 
This RPM is required for all Amanda enterprise installations. This RPM must be installed on all Amanda clients and Amanda servers.
Schily tar 
Installation of Schily tar package is optional. It should be installed on Amanda clients and server that use Schily tar for backups and recovery. This package is required for backing up filesystem extended attributes and Access control lists (ACLs).

Amanda enterprise edition has other dependencies such as xinetd package. All the platforms supported by Amanda enterprise edition provide xinetd package. The package version that is shipped with the platform is sufficient for Amanda enterprise edition.

Pre-installation procedure

  • Identify the list of hosts and the filesystems that have to be protected using Amanda software. The list of hosts that have to be protected are the Amanda clients. The list of filesystems or directories that have to be backed up in each Amanda client have to be identified. This information is needed during Amanda configuration.
  • Identify the Amanda server. Amanda server should have access to the media (tape, disk, changers) where the Amanda client backups will be stored. Any Amanda client can act as Amanda server. Amanda server might use significant amount of memory during backup run and must have good network connectivity to all Amanda clients.
  • Amanda server and client should have all latest service packs or updates to the distribution installed on them.

Steps to install Amanda enterprise edition

  • Installation steps have to be performed as super-user (root user). If you are not super-user, please switch user on the installation target host.
  • Click to download necessary Amanda RPMs for appropriate operating system and Amanda dependency RPMs (Choose "Save to disk" option on the pop -up window) Zmanda network. You should have Zmanda network subscription to download the RPMs. Zmanda network subscription license is required for all Amanda clients. If you do not have Zmanda network subscription for the Amanda client, please contact [email protected] or go to Zmanda network subscriptions page.
  • Amanda enterprise RPMs contain GPG signatures. To verify the integrity of the downloaded rpms, please see package verification section. If the signature verification fails, please download the RPMs from Zmanda network again.
  • If the Amanda dependency RPM is already installed in the host, remove it using rpm command.

Example: Removing old tar RPM

# /bin/rpm -qa | grep tar
tar-1.14-4
# /bin/rpm -e tar-1.14-4
  • Download needed dependency rpms from the Zmanda network. Use rpm command to install the package on the Amanda server and client as needed.

Example: Command to install tar rpm

# /bin/rpm -ivh tar-1.15.1-5.i386.rpm
  • Amanda enterprise RPMs have dependencies on some packages that are part for the platform distribution:
    • xinetd
    • perl
    • awk
If these packages are not installed on the target host, please install from the distribution media.
  • Use rpm install command to install the RPM on the target host. If the target host is a Amanda server, amanda_enterprise_backup_server RPM must be installed. If the target host is a Amanda client, amanda_enterprise_backup_client RPM must be installed.

Example: Command to install Amanda server RPM

# /bin/rpm -ivh amanda_enterprise-backup_server-2.5.0-1.rhel4.i386.rpm
  • Amanda package installation messages and errors are logged in /var/log/amanda/install.log and /var/log/amanda/install.err on the target host. In case of installation failures, please check for messages in these log files.
  • As part of Amanda package installation, some configuration steps are automatically completed.
    • Amanda rpms create backup user - "amandabackup" and the user belongs to "disk" group. The password for amandabackup user is locked. Please set the user password for amandabackup user.
    • Configuration templates are installed in the "amandabackup" user home directory - /var/lib/amanda
    • Amanda daemons are added to xinetd configuration files. The xinetd daemon is forced to read the new configuration.
    • SSH keys are generated for ssh authentication between Amanda client and server

Example: Amanda enterprise server installation on Fedora Core 4 platfrom

# rpm -ivh amanda_enterprise-backup_server-2.5.0-1.fc4.i386.rpm
warning: amanda_enterprise-backup_server-2.5.0-1.fc4.i386.rpm: Header V3 DSA signature: NOKEY, key ID 3c5d1c92
Preparing...                ########################################### [100%]
Apr 21 2006 14:55:43: Checking for 'amandabackup' user...
Apr 21 2006 14:55:43:
Apr 21 2006 14:55:43:  The 'amandabackup' user account for this system has been locked
Apr 21 2006 14:55:43:  for security purposes.  Once a password for the  'amandabackup'
Apr 21 2006 14:55:43:  account has been set, the user can be unlocked by issuing
Apr 21 2006 14:55:43:  the following command as root.:
Apr 21 2006 14:55:43:
Apr 21 2006 14:55:43:  # passwd -u amandabackup
Apr 21 2006 14:55:43:
Apr 21 2006 14:55:43:  If this is not a new installation of Amanda and you have
Apr 21 2006 14:55:43:  pre-existing Amanda configurations in /etc/amanda
Apr 21 2006 14:55:43:  you should ensure that 'dumpuser' is set to 'amandabackup'
Apr 21 2006 14:55:43:  in those configurations.  Additionally, you should ensure
Apr 21 2006 14:55:43:  that /var/lib/amanda/.amandahosts on your client systems
Apr 21 2006 14:55:43:  is properly configured to allow connections for the user
Apr 21 2006 14:55:43:  'amandabackup'.
Apr 21 2006 14:55:43:
Apr 21 2006 14:55:43:
Apr 21 2006 14:55:49: === Amanda Enterprise backup server installation started. ===
   1:amanda_enterprise-backu########################################### [100%]
Apr 21 2006 14:55:50: Updating system library cache...done.
Stopping xinetd: [  OK  ]
Starting xinetd: [  OK  ]
Apr 21 2006 14:55:50: Restarting xinetd...success.
Apr 21 2006 14:55:50: Installing '/etc/amandates'.
Apr 21 2006 14:55:50: Ensuring correct permissions for '/etc/amandates'.
Apr 21 2006 14:55:50: '/etc/amandates' Installation successful.
Apr 21 2006 14:55:50: Installing '/var/lib/amanda/.gnupg'.
Apr 21 2006 14:55:50: '/var/lib/amanda/.gnupg' will be created.
Apr 21 2006 14:55:50: The directory '/var/lib/amanda/.gnupg' created successfully.
Apr 21 2006 14:55:50: Ensuring correct permissions for '/etc/.gnupg'.
Apr 21 2006 14:55:50: '/var/lib/amanda/.gnupg' Installation successful.
Apr 21 2006 14:55:50: Creating directory '/var/lib/amanda/.ssh'.
Apr 21 2006 14:55:50: Creating ssh RSA key in '/var/lib/amanda/.ssh/id_rsa'
Apr 21 2006 14:55:50: Setting ownership and permissions for '/var/lib/amanda/.ssh' and  '/var/lib/amanda/.ssh/id_rsa*'
Apr 21 2006 14:55:50: Checking for '/var/lib/amanda/.profile' and ensuring correct environment.
Apr 21 2006 14:55:50: Setting ownership and permissions for '/var/lib/amanda/.profile'
Apr 21 2006 14:55:50: === Amanda Enterprise backup server installation complete. ===
Amanda installation log can be found in '/var/log/amanda/install.log' and errors (if any) in '/var/log/amanda/install.err'.

Configuration

An Amanda server can support multiple Amanda configurations. Each configuration is identified by unique name and all information is stored in /etc/amanda/<configuration name> directory. Each configuration is a associated with a backup run schedule and a specific media device.

Each Amanda configuration directory contains:

Amanda configuration directory also contains backup index, backup run logs and other backup run information such as "curinfo". It is necessary to backup Amanda configuration directories.

Amanda enterprise edition provides configuration tools - amserverconfig and amaddclient and configuration templates to ease the initial setup of Amanda configuration.

All the configuration steps are performed on the Amanda server.

Configuration templates

To ease the creation of Amanda server configuration file - amanda.conf, amanda.conf configuration file is created from multiple configuration files.

amanda.conf 
Configuration parameters that are likely to be changed for each Amanda configuration. This file includes all other configuration files. This file should be present in /etc/amanda/<configuration name>/ directory.

Example: amanda.conf file

org "DailySet1 "               # your organization name for reports
mailto "amandabackup"          # space separated list of operators at your site
dumpcycle 1 week               # the number of days in the normal dump cycle
runspercycle 5                 # the number of amdump runs in dumpcycle days
                               # (4 weeks * 5 amdump runs per week -- just weekdays)
tapecycle 25 tapes             # the number of tapes in rotation
                               # 4 weeks (dumpcycle) times 5 tapes per week (just
                               # the weekdays) plus a few to handle errors that
                               # need amflush and so we do not overwrite the full
                               # backups performed at the beginning of the previous
                               # cycle
runtapes 1                     # number of tapes to be used in a single run of amdump
tpchanger "chg-disk"           # the tape-changer glue script
tapedev "file://var/lib/anabda/backup" # the no-rewind tape device to be used
changerfile "/etc/amanda/DailySet1/changer.conf"
changerdev "/dev/null"
tapetype HARDDISK               # what kind of tape it is 
labelstr "^DailySet1-[0-9][0-9]*$"    # label constraint regex: all tapes must match
dtimeout 1800                          # number of idle seconds before a dump is aborted.
ctimeout 30                            # maximum number of seconds that amcheck waits
                                       # for each client host
etimeout 300                           # number of seconds per filesystem for estimates.

includefile "./advanced.conf"
includefile "/etc/amanda/template.d/dumptypes"
includefile "/etc/amanda/template.d/tapetypes"


advanced.conf 
Configuration parameters that are less likely to be changed for each Amanda confiuration. This file is included by amanda.conf. This file should be present in /etc/amanda/<configuration name/ directory.
dumptypes 
All supported dumptypes are present in /etc/amanda/template.d/dumptypes file. Dumptype configurations are shared by all Amanda configurations in the Amanda server. If dumptype configuration have to be customised, they are added to the amanda.conf by including the dumptype template.

Example: Customised dumptype configuration to exclude GIF files in amanda.conf

dumptype custom_exclude_tar {
  user-tar
  exclude-file *.gif
}
tapetypes 
All supported tapetype definitions are present in /etc/amanda/template.d/tapetypes file. Tapetype definitions are shared by all configurations in the Amanda server. This file is included in amanda.conf.

Configuration tools

amserverconfig

Amanda server configuration tool that takes various parameters from user and create a working Amanda server configuration.

The easiest way to use amserverconfig is to use the --template option. Three standard templates are supplied:

  • harddisk
  • single-tape
  • tape-changer

Template files can be found in /var/lib/amanda/template.d directory.

Example: Creating a Amanda configuration "new_config1" that uses virtual tape

$ amserverconfig --template harddisk new_config1

A working Amanda configuration will be created in /etc/amanda/new_config1. Virtual tapes will be in /var/lib/amanda/vtapes/new_config1 and properly labelled.

Example: Create a customized Amanda configuration "new_config2", supply the parameters that has to be customized

$ amserverconfig --tapedev /dev/nst2 --tapecycle 30  new_config2

amserverconfig will use default values for the rest of the parameters.

amaddclient

Amanda client configuration tool to add a client to an Amanda configuration.

Example: Add a client client1.zmanda.com to Amanda configuration "new_config1" to backup /home directory:

$ amaddclient --config new_config1 --client client1.zmanda.com --diskdev /home

Example: Add a client client2.zmanda.com to Amanda configuration "new_config2". To backup /usr but exclude /usr/tmp:

$ amaddclient --config new_config2 --client client2.zmanda.com --diskdev /usr --excludefile ./tmp

Configuring using configuration templates

This section provides an example configuration using configuration templates. This example backs up "/var/log" directory from Amanda client - copper.zmanda.com to a disk storage on the Amanda server "iron.zmanda.com" using "harddisk" configuration template. All configuration steps are performed on the Amanda server - iron.zmanda.com

  • Switch user to "amandabackup" - Amanda backup user.

Example: Switching to amandabackup

su - amandabackup
  • Run amserverconfig command with "harddisk" configuration template parameter to create amanda.conf

Example: Creating amanda.conf for configuration "dailyset1" on iron.zmanda.com

$ /usr/sbin/amserverconfig dailyset1 --template harddisk
Logging to /tmp/amanda/amserverconfig.20060420095207.debug
/var/lib/amanda/gnutar-lists directory exists
/etc/amanda/template.d directory created
/etc/amanda/dailyset1/amanda.conf created and updated
/etc/amanda/dailyset1/advanced.conf created and updated
curinfo and index directory created
tapelist file created
disklist file created
DONE

Note:

  1. The created amanda.conf uses "amandabackup" as the "mailto" parameter value. All the mail notifications about the backups in this configuration will be sent to the user "amandabackup" on the Amanda server. It is necessary to configure email account for the amandabackup user.
  • Add client and the directory to be backed up using amaddclient

Example: copper.zmanda.com as Amanda client to backup /var/log directory

$ /usr/sbin/amaddclient --config dailyset1 --client copper.zmanda.com --diskdev /var/log/
Logging to /tmp/amanda/amclientconfig.20060420101637.debug
/etc/amanda/dailyset1/disklist updated
updating /var/lib/amanda/.amandahosts on iron
/var/lib/amanda/.amandahosts contains copper.zmanda.com root, file not updated
I am attempting to update /var/lib/amanda/.amandahosts on copper.zmanda.com
.amandahosts                                                                 100%  109     0.1KB/s   00:00
.amandahosts.tmp                                                             100%  130     0.1KB/s   00:00
copper.zmanda.com:/var/lib/amanda/.amandahosts updated successfully

Note:

  1. If the Amanda client is same as the Amanda server, you will have to add 'localhost amandabackup' and 'copper.zmanda.com amandabackup' in /var/lib/amanda/.amandahosts on iron.zmanda.com
  2. If ssh public-key authentication is set up between the Amanda server and the client, amaddclient command will update /var/lib/amanda/.amandahosts on the Amanda client using scp. Otherwise, amaddclient command will print a message with information on what has to be added to /var/lib/amanda/.amandahosts on the client machine. To set up public-key authentication:
    1. Copy ~amandabackup/.ssh/id_rsa.pub to the client machine through a secure channel(*) and append it to ~amandabackup/.ssh/authorized_keys file. For example: copy id_rsa.pub to a floppy or flash drive and hand carry to the client machine.
    2. Run ssh-add on the Amanda server to add the RSA identities to the authentication agent.
    3. Change file permissions
$ chmod 600 ~amandabackup/.ssh/authorized_keys
  • Run Amanda configuration check tool - amcheck command.

Example: Running amcheck on configuration "dailyset1"

$ /usr/sbin/amcheck dailyset1
Amanda Tape Server Host Check
-----------------------------
slot 25: read label `dailyset1-25', date `X'
NOTE: skipping tape-writable test
Tape dailyset1-25 label ok
NOTE: host info dir /etc/amanda/dailyset1/curinfo/copper does not exist
NOTE: it will be created on the next run.
NOTE: index dir /etc/amanda/dailyset1/index/copper does not exist
NOTE: it will be created on the next run.
Server check took 0.120 seconds

Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 0.055 seconds, 0 problems found

(brought to you by Amanda 2.5.0)

  • Do a backup run manually. Please check default parameters in /etc/amanda/<configname>/amanda.conf before backup run. Please make sure default "tapedev" has enough space to accomodate the backup.

Example: Running amdump manually on confiuguration "dailyset1"

$ /usr/sbin/amdump dailyset1
You have mail in /var/mail/amandabackup
 
  • Check mail for backup run report.

Example: Amanda report email message

These dumps were to tape dailyset1-25.
The next tape Amanda expects to use is: a new tape.
The next new tape already labelled is: dailyset1-1.


STATISTICS:
			Total       Full      Incr.
			--------   --------   --------
Estimate Time (hrs:min)    0:00
Run Time (hrs:min)         0:00
Dump Time (hrs:min)        0:00       0:00       0:00
Output Size (meg)           8.6        8.6        0.0
Original Size (meg)         8.5        8.5        0.0
Avg Compressed Size (%)     --         --         --
Filesystems Dumped            1          1          0
Avg Dump Rate (k/s)     10771.1    10771.1        --

Tape Time (hrs:min)        0:00       0:00       0:00
Tape Size (meg)             8.6        8.6        0.0
Tape Used (%)               0.2        0.2        0.0
Filesystems Taped             1          1          0

Chunks Taped                  0          0          0
Avg Tp Write Rate (k/s)  9442.1     9442.1        --

USAGE BY TAPE:
Label              Time      Size      %    Nb    Nc
dailyset1-25       0:00     8800K    0.2     1     0

NOTES:
planner: Adding new disk copper:/var/log/.

Creating Customized configuration

This section provides an example for creating customised Amanda configuration instead of using configuration templates. This example backs up "/var/log" directory from Amanda client - copper.zmanda.com to a disk storage (/mnt/storage) on the Amanda server "iron.zmanda.com" using "harddisk" configuration template. All configuration steps are performed on the Amanda server - iron.zmanda.com

See Notes in the Creating Amanda configuration using templates for amserverconfig and amaddclient commands (Steps 1 and 2).

Example: Creating customer configuration "dailyset1"

$ /usr/sbin/amserverconfig dailyset1 --tapedev "file://mnt/storage" --tapetype HARDDISK --tpchanger chg-disk \
--changerfile "/etc/amanda/dailyset1/changer.conf" --changerdev /dev/null --labelstr "^dailyset1-[0-9][0-9]*$" \
--mailto "amandabackup" --dumpcycle 5days --runspercycle 5 --runtapes 1 --tapecycle 25
Logging to /tmp/amanda/amserverconfig.20060420142202.debug
/var/lib/amanda/gnutar-lists directory exists
/etc/amanda/template.d directory created
custom amanda.conf created
/etc/amanda/dailyset1/advanced.conf created and updated
curinfo and index directory created
tapelist file created
disklist file created
DONE.

  • Add Amanda client - copper.zmanda.com and directory to be backed up using amaddclient.

Example: Using amaddclient to add Amanda client

$ /usr/sbin/amaddclient --config dailyset1 --client copper.zmanda.com --diskdev /var/log/
Logging to /tmp/amanda/amclientconfig.20060420101637.debug
/etc/amanda/dailyset1/disklist updated
updating /var/lib/amanda/.amandahosts on iron
/var/lib/amanda/.amandahosts contains copper.zmanda.com root, file not updated
I am attempting to update /var/lib/amanda/.amandahosts on copper.zmanda.com
.amandahosts                                                                     100%  109     0.1KB/s   00:00
.amandahosts.tmp                                                                 100%  130     0.1KB/s   00:00
copper.zmanda.com:/var/lib/amanda/.amandahosts updated successfully
  • Create virtual tape slot directories and label them with amlabel command. Change to tapedev directory, Create slot directories equal to "tapecycle" value in amanda.conf (default value: 25) and label them with amlabel command.

Example: Following shell script will create 25 virtual tape slot directories under "/mnt/storage" directory and label them

$ cd /mnt/storage
$ i=1; while [ $i -le 25 ]; do mkdir slot$i; /usr/sbin/amlabel dailyset1 dailyset1-$i slot $i; i=$[$i+1];  done;

  • Check Amanda configuration with amcheck command.

Example: Running amcheck on configuration "dailyset1"

$ /usr/sbin/amcheck dailyset1
Amanda Tape Server Host Check
-----------------------------
slot 1: read label `dailyset1-1', date `X'
NOTE: skipping tape-writable test
Tape dailyset1-1 label ok
NOTE: host info dir /etc/amanda/dailyset1/curinfo/copper.zmanda.com does not exist
NOTE: it will be created on the next run.
NOTE: index dir /etc/amanda/dailyset1/index/copper.zmanda.com does not exist
NOTE: it will be created on the next run.
Server check took 0.144 seconds

Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 0.506 seconds, 0 problems found 

(brought to you by Amanda 2.5.0)

  • Force a backup run manually for testing the configuration.

Example: Running amdump on configuration "dailyset1"

$ /usr/sbin/amdump dailyset1
You have mail in /var/mail/amandabackup 
  • Check email for backup run report.

Example: Backup run report email message

These dumps were to tape dailyset1-1.
The next tape Amanda expects to use is: a new tape.
The next new tape already labelled is: dailyset1-2.


STATISTICS:
                          Total       Full      Incr.
                        --------   --------   --------
Estimate Time (hrs:min)    0:00
Run Time (hrs:min)         0:00
Dump Time (hrs:min)        0:00       0:00       0:00
Output Size (meg)           8.6        8.6        0.0
Original Size (meg)         8.6        8.6        0.0
Avg Compressed Size (%)     --         --         --
Filesystems Dumped            1          1          0
Avg Dump Rate (k/s)     10640.9    10640.9        -- 

Tape Time (hrs:min)        0:00       0:00       0:00
Tape Size (meg)             8.6        8.6        0.0
Tape Used (%)               0.2        0.2        0.0
Filesystems Taped             1          1          0 

Chunks Taped                  0          0          0
Avg Tp Write Rate (k/s)  9723.8     9723.8        --

USAGE BY TAPE:
  Label             Time      Size      %    Nb    Nc
  dailyset1-1       0:00     8800K    0.2     1     0

NOTES:
planner: Adding new disk copper.zmanda.com:/var/log/.

Recommended configuration parameters

  • Gnu tar is recommended as the backup program for Amanda enterprise edition. The "Program" parameter in the dumptype section of amanda.conf must be set to "GNUTAR".
  • "ssh" is the recommended mechanism for encrypting communication. The "auth" parameter in the dumptype section of amanda.conf must be set to "ssh". Encryption increases the backup time significantly. So, use encrytion only if it is needed.
  • If you are using "ssh" for Amanda server and client authentication, it's not recommended to client data encryption. That's not to use both 'auth "ssh"' and 'encrypt client' in the same dumptype.
  • Always use indexing to track the files in the backup image.
  • Use Fully Qualified Domain Names for hostnames in disklist entries. See amanda(8).

Example: Recommended dumptype configuration

define dumptype recommended-tar {
   global
   program "GNUTAR"
   comment "recommended dumptype configuration"
   auth bsd
   index
   record yes
}

Security features

Amanda enterprise edition provides various options for securing backup data, securing Amanda server/client communication. Amanda enterprise edition can also work on secure environments such SE Linux. This section describes

  • Data encryption methods
  • Transport encryption methods
  • Amanda server and client communication port usage for configuring Firewalls
  • IP tables firewall and information for other firewall configuration
  • Working on SE Linux environment


Amanda Enterprise Edition Security Features

Backing up Access control lists and Extended file attributes

Some file systems such as ext3fs, XFS, Windows NTFS have had the ability to store Access Control Lists and file attributes for individual files. Schily tar, or star (pronounced 'ess-tar') has the capability to backup and restore both ACLs and extended file attributes.

Amanda can now backup individual file ACLs and attributes through the support of star (ess-tar) as a backup program. Use GNU tar will not backup access control lists and extended file attributes. Please note that filesystem dump program will backup ACLs and extended file attributes.

In SE Linux environment, the mandatory access control lists are stored as extended file attributes. So, it is necessary to use Star program to backup in SE Linux environment.

Schily tar (star command) provides better backup performance than GNU tar progam. Use of schily tar will reduce the backup window.

Before using star program for backup, you must install the star RPM package from the Zmanda network on the Amanda client.

Configuring Star backups

Star is supported by Amanda enterprise edition in same manner as GNU tar program. Set the program field in the dumptype configuration in amanda.conf configuration file to STAR. Use the dumptype definition in disklist entry to use star command to backup the data from the Amanda client.

Example: dumptype configuration using star in amanda.conf

 define dumptype user-star {
         comment "Full dump of /boot using star
         global
         program "STAR"
         compress none
         priority high
 }

Example: disklist entry using user-star dumptype

 copper.zmanda.com /boot user-star

Adding include and exclude lists for STAR program in the dumptype is identical to GNU tar. It can be specified in the amanda.conf dumptype configuration or in a separate file.

(include|exclude)  file1 file2 file3 

or may be listed in a file

one file per line, as in : '(include|exclude) list filename'.

Incremental backups

Star program requires a backup level 0 (full backup) backup to be done before incremental backups. The backup process will fail if incremental backup is done before any full backup. The star program maintains /etc/tardumps to keep track backup level and timestamp file on the Amanda client. This file should not be modified by the user.

Recovery from backups done using star command

Recovery commands - amrecover and amrestore will work with backup images created using star commands.

If the backup index is no longer available, the backup image header will provide information on how to restore the image and show the command to be used.

Example: Backup header of a backup done using star

 AMANDA: FILE 20060414174126 localhost /tmp/amanda  lev 0 comp N program /usr/bin/star
 To restore, position tape at start of file and run:
       dd if=<tape> bs=32k skip=1 |    /usr/bin/star -f - ...
^L

Restoring the individual files from the backup images is different. Please take a look at the star man page for command line syntax.

Example: Restoring backup images created by star under SELinux. Following command will restore amanda debug files from Amanda backup image - localhost._tmp_amanda.20060414174126.0

$ star -x -v -xattr -f localhost._tmp_amanda.20060414174126.0 amandad.20060414165105.debug amandad.20060414165741.debug amandad.20060414170145.debug amandad.20060414174127.debug
Host name   ktill2.zmanda.com
File system /tmp/amanda
Working dir /tmp/amanda
Release     star 1.5a69 (i386-redhat-linux-gnu)
Archtype    exustar
Dumptype    partial
Dumplevel   0
Dumpdate    1145061704.555902 (Fri Apr 14 17:41:44 2006)
Volno       1
Blocksize   20
x amandad.20060414165105.debug 3636 bytes, 8 tape blocks
x amandad.20060414170145.debug 135656 bytes, 265 tape blocks
x amandad.20060414174127.debug 16393 bytes, 33 tape blocks
x amandad.20060414165741.debug 3636 bytes, 8 tape blocks
star: 70 blocks + 4096 bytes (total of 720896 bytes = 704.00k).

Example: Restored file attributes from the backup image

$ ls -Z
-rw-r-----  amandaba disk     system_u:object_r:amanda_tmp_t    amandad.20060414165105.debug
-rw-r-----  amandaba disk     system_u:object_r:amanda_tmp_t    amandad.20060414165741.debug
-rw-r-----  amandaba disk     system_u:object_r:amanda_tmp_t    amandad.20060414170145.debug
-rw-r-----  amandaba disk     system_u:object_r:amanda_tmp_t    amandad.20060414174127.debug
-rw-r-----  amandaba disk     amandabackup:object_r:sysadm_home_t  localhost._tmp_amanda.20060414174126.0

Backing up large filesystems

Amanda enterprise edition supports backup images of multi-terabyte size. The support of large backups is subject to availability of Amanda system and network resources. There are lot of configuration parameters that can be used to perform large backups efficiently.

Splitting backup images into multiple media volumes 
In case of large backup images, it is necessary to split backup images into multiple media volumes. For more information see Split dumps.
Dedicated backup network interface 
Use of dedicated backup network interface for a disklist list entry will decrease the time required to perform the backup. The dedicated backup network interface is specified as part of disklist entry.
Large holding disk 
Use of large holding disk exclusively for a large filesystem will allow the backup data from the filesystem to be written to the holding disk independent of other disk list entries in the backup run.
Use of multiple dumpers for the disk list entry 
Amanda allows configuration of multiple dumpers for a client. One dumper must be assigned for each DLEs in the client that has the large filesystem to be backed up.
Use of calcsize or server estimation algorithm 
Amanda can spend lot of time in estimating the backup image size for the backup level. The client estimation algorithm can take significant amount of time for large filesystem. Backup window will be reduced if server estimation algorithm or "calcsize" algorithm that takes significantly less time.
If the backup size is large due to a filesystem that is changing a lot, it will be better if the dump strategy is changed to do only full backups (level 0 backups).
Compressing data on the client 
Compressing the data on the client would reduce the amount of data that has to be transferred to Amanda server.
Avoid use of encryption 
Encryption algorithms take a lot of time to complete and are proportional to amount of data to be backed up. If data security is required, it is better to split the disk list entry into multiple entries.
Increase dtimeout for backups 
dtimeout in amanda.conf specifies the time for which data connection between Amanda server and client can be idle before the connection times out. It may be necessary to the increase the value for a large filesystem.

POSIX filenames in configuration files

Amanda enterprise edition supports the POSIX path naming standard for all filenames in dumptype configuration in amanda.conf and client configuration files.

This feature makes configuration of Amanda clients running Windows and Amanda clients that use international character sets possible.

Any filename referenced, including include file names, may contain any character except a NULL ('\0') character. Actual path interpretation is system dependent. POSIX file name rules are also allowed when specifying configuration file tags. For example we use spaces in a dumptype name in the examples below.

Specifying Special characters

Pathnames with special characters must be enclosed in double quotes ("). Some unprintable charactes are given special escape sequences.

Escape sequences
Sequence Character
\n Newline
\r Carrage Return
\t Tab
\f Formfeed
\" Double Quote


Example: Spaces in a dumptype name, exclude list, include list in amanda.conf

 define dumptype "user-tar (a1)" {
    root-tar
    comment "User partition dumped with tar and a funny dumptype name"
    priority medium
    exclude "diskfile b*"
    include list "/tmp/include list with spaces in file name"
 }

Example: Disklist file entries with spaces in backup directory and dumptype names

 localhost "/tmp/disk name with spaces" user-tar
 localhost "/tmp/disk name with\nnewline" "user-tar (a1)"

Example: Using file names with spaces in Amrecover sub-commands

 setdisk "/tmp/disk name with\nnewline"
 add "diskfile *"
 delete "diskfile a1"

Support for Optical devices

Amanda enterprise edition support UDO and MO archive appliances from Plasmon. Amanda treats these devices as disks. The Archive Appliance is a storage appliance that presents an NFS or SMB share, which can be used to control a configurable about of UDO storage -- starting at 960GB, up to 19 TB. The device also has a RAID cache of 170 GB and 2 TB.

Configuration

To use the Plasmon Archive Appliance with Amanda, mount the NFS share provided by the appliance on the Amanda server, and then follow the standard instructions for disk-based backup. However, because the Archive Appliance does not support files larger than 5 Gb, you must instruct Amanda to split dumps larger than this size.

Example: dumptype definition in amanda.conf specifying tape split size

define dumptype global {
    tape_splitsize 4900 Mb
    ...
}

Notes about the high-water mark

The Archive Appliance supports configurable high- and low-water marks which determine when data is migrated to UDO disks from the RAID cache. The default high-water mark is 85% of the RAID cache size by default, and this default is acceptable for most installations.

Users with very large dumps may wish to reduce the high-water mark for improved performance. In particular, those planning to dump more than about double the RAID cache size (300 GB - 4 TB, depending on the Archive Appliance) will need to lower the high-water mark.

Multiple backup runs in a day

Normally backups are done on a daily basis. Amanda enterprise edition can do multiple backup runs in a day. This feature is useful for client filesystems that changes a lot over time.

Backup run is scheduled using crontab entry. To do multiple backup runs in a day, you can change the crontab entry for amdump process or run amdump command from command line.

During the recovery process, amrecover "setdate" command allows users to specify which specific backup image should be restored.

Example: Selecting backup image to recover from when multiple dumps are done in a day from an Amanda configuration test

# /usr/sbin/amrecover test
AMRECOVER Version 2.5.0. Contacting server on localhost ...
220 iron AMANDA index server (2.5.0) ready.
200 Access OK
Setting restore date to today (2006-04-21)
200 Working date set to 2006-04-21.
200 Config set to test.
amrecover> sethost localhost
200 Dump host set to localhost.
amrecover> setdisk /usr/tmp
200 Disk set to /usr/tmp.
amrecover> ls
2006-04-21-15-50-27 ssh_config
2006-04-21-15-50-27 foo.gpg
2006-04-21-15-50-27 foo
2006-04-21-15-50-27 config-2.6.11-1.1369_FC4smp
2006-04-21-15-50-27 asimple
2006-04-21-15-50-27 System.map-2.6.11-1.1369_FC4
2006-04-21-15-50-27 .


Example: Restoring backups with time stamp April 21, 2006 15:47:19 to /usr/tmp directory.

amrecover> setdate 2006-04-21-15-47-19
200 Working date set to 2006-04-21-15-47-19.
amrecover> ls
2006-04-21-15-47-19 ssh_config
2006-04-21-15-47-19 rpm-tmp.92294
2006-04-21-15-47-19 rpm-tmp.83787
2006-04-21-15-47-19 rpm-tmp.81866
2006-04-21-15-47-19 rpm-tmp.65537
2006-04-21-15-47-19 rpm-tmp.65462
2006-04-21-15-47-19 rpm-tmp.42926
2006-04-21-15-47-19 rpm-tmp.42601
2006-04-21-15-47-19 rpm-tmp.41519
2006-04-21-15-47-19 rpm-tmp.37869
2006-04-21-15-47-19 rpm-tmp.27296
2006-04-21-15-47-19 rpm-tmp.25634
2006-04-21-15-47-19 foo.gpg
2006-04-21-15-47-19 foo
2006-04-21-15-47-19 config-2.6.11-1.1369_FC4smp
2006-04-21-15-47-19 asimple
2006-04-21-15-47-19 System.map-2.6.11-1.1369_FC4
2006-04-21-15-47-19 .
amrecover>add *
Added file /ssh_config
Added file /rpm-tmp.92294
Added file /rpm-tmp.83787
Added file /rpm-tmp.81866
Added file /rpm-tmp.65537
Added file /rpm-tmp.65462
Added file /rpm-tmp.42926
Added file /rpm-tmp.42601
Added file /rpm-tmp.41519
Added file /rpm-tmp.37869
Added file /rpm-tmp.27296
Added file /rpm-tmp.25634
Added file /foo.gpg
Added file /foo
Added file /config-2.6.11-1.1369_FC4smp
Added file /asimple
Added file /System.map-2.6.11-1.1369_FC4
amrecover> extract

Extracting files using tape drive null: on host localhost.
The following tapes are needed: test-2

Restoring files into directory /tmp/recover
Continue [?/Y/n]? y

Extracting files using tape drive null: on host localhost.
Load tape test-2 now
Continue [?/Y/n/s/t]? y
./System.map-2.6.11-1.1369_FC4
./asimple
./config-2.6.11-1.1369_FC4smp
./foo
./foo.gpg
./rpm-tmp.25634
./rpm-tmp.27296
./rpm-tmp.37869
./rpm-tmp.41519
./rpm-tmp.42601
./rpm-tmp.42926
./rpm-tmp.65462
./rpm-tmp.65537
./rpm-tmp.81866
./rpm-tmp.83787
./rpm-tmp.92294
./ssh_config


Example: Restoring backups with time stamp April 21, 2006 15:50:27 to /tmp/recover2 directory

amrecover> lcd /tmp/recover2
amrecover> setdate 2006-04-21-15-50-27
200 Working date set to 2006-04-21-15-50-27.
amrecover> ls
2006-04-21-15-50-27 ssh_config
2006-04-21-15-50-27 foo.gpg
2006-04-21-15-50-27 foo
2006-04-21-15-50-27 config-2.6.11-1.1369_FC4smp
2006-04-21-15-50-27 asimple
2006-04-21-15-50-27 System.map-2.6.11-1.1369_FC4
2006-04-21-15-50-27 .
amrecover> add *
Added file /ssh_config
Added file /foo.gpg
Added file /foo
Added file /config-2.6.11-1.1369_FC4smp
Added file /asimple
Added file /System.map-2.6.11-1.1369_FC4
amrecover> extract

Extracting files using tape drive null: on host localhost.
The following tapes are needed: test-1

Restoring files into directory /tmp/recover2
Continue [?/Y/n]? y

Extracting files using tape drive null: on host localhost.
Load tape test-1 now
Continue [?/Y/n/s/t]? y
./System.map-2.6.11-1.1369_FC4
./asimple
./config-2.6.11-1.1369_FC4smp
./foo
./foo.gpg
./ssh_config


Note 
If you use this feature, Amanda enterprise edition server cannot be downgraded to Amanda community edition 2.5 server. If you do not want to use this feature, set "usetimestamps" to "no" in server configuration file - amanda.conf. The amserverconfig command sets "usetimestamps" to "yes" in amanda.conf

Migration from Amanda community edition

Amanda community edition 2.5 is fully compatible with Amanda enterprise edition. Amanda community edition server can work with Amanda enterprise edition clients and vice versa.

Note: Recommended upgrade procedure is to upgrade an Amanda client from community edition to enterprise edition. 
Test the backup and recovery process. If the testing is successful, upgrade the remaining clients and the server.