This MindTouch Deki has expired; please contact your system administrator. Visit MindTouch.com for activation information.
Project:Amanda Enterprise 3.0 > Amanda Enterprise Edition 3.0 Administrators Guide

Amanda Enterprise Edition 3.0 Administrators Guide

Amanda Enterprise Edition is certified Amanda network backup software, tested and supported by Zmanda, and available for various platforms. Please see the latest platform support information on the Zmanda Network. Windows operating system clients not listed can still be backed up using Samba software. (Using Samba, No Amanda software is needed on the Windows client.)

Amanda Enterprise Edition 3.0 with Zmanda Management Console (ZMC) is available for all server platforms from the Zmanda network downloads page.

Amanda enterprise edition 3.0 with ZMC has a common rapid installer binary for all the supported platforms. The rapid installer installs Amanda enterprise 3.0 server, Zmanda Linux or Solaris 3.0 Clients, the Zmanda Management Console and all dependencies. It also supports upgrades from existing Amanda enterprise 2.6.X installation. It does not change existing installation of dependencies such as MySQL, Apache, perl on the server. Zmanda management console is a simple to use web interface for managing Amanda backup sets and for performing backup and recovery operations. Please read Zmanda Management Console Users Manual for information on how to install and use the Zmanda Management Console.

Although the Rapid Installer is the recommended method of installing Zmanda software, you can also request source rpm and tar packages from the Zmanda Support team; client packages are available from the Zmanda network:.

Feature differences between Amanda Enterprise and Amanda Community Edition and how to use these features are also discussed in this document. The Amanda Community Edition documentation referred to in this document (which covers general Amanda configuration, administration tools and processes) is available from the Zmanda wiki.

The Zmanda Solaris Client is documented in Zmanda Solaris Client guide.

The Zmanda Windows Client is documented in Zmanda Windows Client guide.

The Zmanda Mac OS X Client is documented in Zmanda Mac OS X Client guide.

Important Note: If you use the ZMC to manage backups, you should ensure that all ZMC users are logged off before manually editing any Amanda configuration files such as amanda.conf, disklist.conf, etc. Any manual configuration edits completed while all ZMC users are logged off will be available to users who subsequently log in.

Installation

The installation procedure for Amanda Enterprise Edition 3.0 with Zmanda Management Console (ZMC) is documented in Zmanda Management Console Users Manual. The rapid installer included with the Zmanda Management Console simplifies installation. Use the rapid installer to install software on Amanda servers; it cannot be used to install software on Amanda clients.

This section describes how to install software on the Amanda server (without Zmanda Management Console support) and Amanda clients.

Amanda Enterprise Edition 3.0 packages are available by request from the Zmanda Support team; client packages are available from the Zmanda network downloads page. Two binary packages are available for each Linux platform:

  • Amanda server package (amanda_enterprise-backup_server): Install this RPM package on the Amanda backup server. The Amanda backup server is the host that controls the backup media. The Amanda server RPM contains Amanda server and client binaries. Both client and server binaries should be installed on the Amanda backup server machine.
  • Amanda client package (amanda_enterprise-backup_client): Install this RPM or Debian package on all systems that are to be backed up by Amanda (in other words, the Amanda backup clients).

All Amanda package dependencies for some platforms are also available from the Zmanda network downloads page. It is better to use system installation tools such as yum, apt-get to install the dependencies.

Amanda 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 : Only required on Amanda clients and servers configured to use Schily tar for backup and recovery of extended filesystem attributes and access control lists (ACLs) in a POSIX-compliant manner.

Amanda Enterprise Edition has other dependencies such as the xinetd package. All platforms supported by Amanda Enterprise Edition include Amanda's dependencies (tar, xinetd, perl and awk) in their distributions. The package version that is shipped with the platform is sufficient for Amanda Enterprise Edition.

 

Pre-installation checklist

  • Identify the hosts and filesystems to be protected using Amanda software. The list of hosts to be protected are the Amanda backup clients. The Amanda backup clients and the filesystems or directories to be backed up on each client will need to be specified during Amanda configuration.
  • Identify the Amanda backup server. The Amanda backup server should have access to the media (tape, disk, changers) where the Amanda client backups will be stored. Any Amanda client can also act as an Amanda server, and it is recommended that every Amanda server also be a backup client. In selecting your Amanda backup server machine, keep in mind that the server might use a significant amount of memory during backup runs, and that it must have good network connectivity to all Amanda clients.
  • The Amanda server and clients should have the latest service packs or updates to the distribution installed.
  • Amanda server and client cannot be installed on NFS mounted file systems.
  • The Amanda server and client require that certain communication ports are open:
    • The Amanda server must open inbound TCP ports 11000:11040.
    • Non-Windows Amanda clients must open inbound TCP port 10080 and outbound TCP ports 11000:11040.
    • Windows clients must open inbound TCP ports 10080 and 10081, and outbound TCP ports 700:800.

Amanda Enterprise Edition initial installation

This procedure is for fresh installations only. If upgrading from a previous version of Amanda Enterprise Edition or Amanda Community Edition, please see Upgrading from Amanda enterprise edition 2.6.X  or Migration from Amanda community edition.

Please note that you must be the super-user (i.e., root). If necessary, please switch user to gain root access to the installation target system before before continuing.
  1. Go to the Zmanda network downloads page. Choose the appropriate platform.
  2. Click to download the necessary Amanda and Amanda dependency RPMs for your environment. (Choose Save to disk from the pop-up window). You need a Zmanda network subscription to download the RPMs, and a Zmanda network subscription license for each Amanda client. If you do not have a Zmanda network subscription and licenses, please contact [email protected] or visit the Zmanda Network subscriptions page.
  3. Download any needed dependency RPMs from the Zmanda network (for Solaris). 
  • Amanda enterprise RPMs have dependencies on some packages that are usually part of the platform distribution. If these packages are not installed on the target host, please install from the distribution media.
    • xinetd
    • perl
    • awk
  • Use the rpm or dpkg  or pkgadd install command to install the package on the target host. If the target host is an Amanda server, install the amanda_enterprise-backup_server RPM. If the target host is an Amanda client, install the amanda_enterprise-backup_client RPM or debian package.

Example: Command to install Amanda server RPM

# /bin/rpm -ivh amanda_enterprise-backup_server-3.0-1.rhel4.i386.rpm

Example: Command to install Amanda client debian package

# dpkg ­-i amanda-enterprise­-backup-­client_3.0-1­_i386.deb
  • 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.
  • Some configuration steps are automatically completed as part of the Amanda package installation:
    • Amanda RPMs create the backup user amandabackup belonging to the disk group. The amandabackup user account is locked for security. Please set a user password for the amandabackup user account. 
    • Configuration templates are installed in the amandabackup user home directory, /var/lib/amanda
    • Amanda daemons are added to the xinetd configuration files. The xinetd daemon is then reset to activate the new configuration.
    • SSH keys are generated for ssh authentication between Amanda client and server for secure communications.

Example: Amanda enterprise server 3.0 installation on Fedora Core 4 platform

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

Post-installation checklist

  • Check for errors in the /var/log/amanda/install.err log file.
  • Set a password for the amandabackup user if the user was created during this Amanda installation process.
  • If configuration files (/etc/amanda/amanda-client.conf, /etc/xinetd.d/amandaserver, /etc/xinet.d/amandaclient) exist on the server, they are not overwritten. Sample files will be installed in the /var/lib/amanda/example directory instead. You will need to manually merge or overwrite the configuration files in the correct locations as needed.


Table: Install location and correct location for configuration files

Install location Correct location
/var/lib/amanda/example/amanda-client.conf /etc/amanda/amanda-client.conf
/var/lib/amanda/example/xinetd.amandaserver /etc/xinetd.d/amandaserver
/var/lib/amanda/example/xinetd.amandaclient /etc/xinetd.d/amandaclient

Configuration

All the configuration steps are performed on the Amanda backup server. An Amanda server can support multiple Amanda backup configurations. Each configuration is identified by a unique name and all the information is stored in an /etc/amanda/configuration_name ("/etc/amanda/$config") directory. Please note that it is necessary to back up Amanda configuration directories.

Each configuration is associated with a backup run schedule and specific backup media. To configure multiple devices on Amanda server, please see How to configure multiple tape devices.

Each Amanda configuration directory contains:

  • Amanda server configuration file - amanda.conf 
  • Amanda client configuration file - disklist.conf 
  • Other configuration files and files specific to the backup configuration, such as backup indices (for example, curinfo and backup run logs.
Note that the amanda.conf file contains only parameters that are likely to be changed. Less common parameters have been moved to advanced.conf.

Amanda clients also use an /etc/amanda/amanda-client.conf file. This file specifies the authentication protocol used during recovery. For more information on this file, see the amanda-client.conf man page.

Configuration templates

The Amanda server configuration file, amanda.conf, is created from multiple configuration files. These configuration file templates are installed in /var/lib/amanda/template.d directory.

amanda.conf 
Configuration parameters that should usually be set for each Amanda installation. This file includes all other configuration files. This file should be in the /etc/amanda/configuration_name/ configuration directory. Templates for disk based backups (amanda-harddisk.conf), single tape drive configuration (amanda-single-tape.conf) and tape changer configuration (amanda-tape-changer.conf) are available in the template.d directory.

Example: amanda.conf file template for disk backups

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/amanda/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 backup configuration. This file is included by amanda.conf. This file should be present in /etc/amanda/configuration_name/ directory.
dumptypes 
All supported dumptypes are listed in the /etc/amanda/template.d/dumptypes file. Dumptype configurations are shared by all Amanda configurations on the Amanda server. If a dumptype configuration must be customized, add it to amanda.conf by including the dumptype template.

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

dumptype custom_exclude_tar {
  user-tar
  exclude-file *.gif
}
tapetypes 
All supported tapetype definitions are included in the /etc/amanda/template.d/tapetypes file. Tapetype definitions are shared by all configurations on the Amanda server. Add new or customized tapetype definitions to amanda.conf.

Configuration tools

Amanda configuration tools must be run as the amandabackup user.

amserverconfig

An Amanda server configuration tool that to create a working Amanda server configuration.

The easiest way to use amserverconfig is with the --template option. Three standard templates are supplied with Amanda Enterprise Edition 3.0:

  • hard disk
  • single tape
  • tape changer
  • Amazon S3

Template files are in the /var/lib/amanda/template.d directory.

Example: Create 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 listed in /var/lib/amanda/vtapes/new_config1 and properly labelled.

Example: Create customized Amanda configuration "new_config2", supplying the custom parameters

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

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

amaddclient

An Amanda client configuration tool to add a client to a backup configuration.

Example: Add "client1.zmanda.com" to "new_config1" and backup the /home directory:

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

Example: Add "client2.zmanda.com" to "new_config2" and backup /usr, excluding /usr/tmp:

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

Configuring Amanda with templates

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

  1. Switch user to amandabackup, the Amanda backup user: su - amandabackup
  2. Run the amserverconfig command with the harddisk configuration template parameter to create an amanda.conf file:
$ /usr/sbin/amserverconfig dailyset1 --template harddisk
Logging to /tmp/amanda/amserverconfig.20070520090207.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.conf file created
DONE

Note:

  • The created amanda.conf sets the mailto parameter to the amandabackup user. All mail notifications regarding backups in this configuration are sent to user amandabackup on the Amanda server. If you have not already done so, set up an email account for the amandabackup user.
* Add a 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.20070520101637.debug
/etc/amanda/dailyset1/disklist.conf updated
updating /var/lib/amanda/.amandahosts on quartz
/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:

  • If the Amanda client is same as the Amanda server, you must add localhost amandabackup amdump and copper.zmanda.com amandabackup amdump to the /var/lib/amanda/.amandahosts file on quartz.zmanda.com
  • If ssh public-key authentication is set up between the Amanda server and the client, the amaddclient command updates /var/lib/amanda/.amandahosts on the Amanda client using scp. Otherwise, amaddclient returns a message specifies what needs to be added to /var/lib/amanda/.amandahosts on the client machine. To set up public-key authentication:
  1. Copy ~amandabackup/.ssh/id_rsa_amdump.pub to the client machine through a secure channel(*) and append it to the ~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 the 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 3.0)
Debian/Ubuntu clients configuration check

The Zmanda Ubuntu and Debian Clients might fail the configuration check with following errors:

Amanda Backup Client Hosts Check
--------------------------------
WARNING: debian-client: selfcheck request failed: tcpm_recv_token:
invalid size: amandad: error while loading shared libraries:
libssl.so.4: cannot open shared object file: No such
Client check: 1 host checked in 0.051 seconds.  1 problem found.
(brought to you by Amanda 3.0)
Amanda Backup Client Hosts Check
--------------------------------
WARNING: ubuntu-client: selfcheck request failed: tcpm_recv_token:
invalid size: amandad: error while loading shared libraries:
libcrypto.so.4: cannot open shared object file: No su
Client check: 1 host checked in 0.678 seconds. 1 problem found.
(brought to you by Amanda 3.0)

Workaround for the above configuration error is to create the symbolic link for appropriate libraries. For example: This has to be done as super user on the Debian and/or Ubuntu client

#  ln -s /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.so.4
#  ln -s /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.4
Backup run
  • Run a manual backup. Please check the default parameters in /etc/amanda/<configname>/amanda.conf before the backup run. Please make sure the default tapedev has enough space to accommodate the backup.

Example: Running amdump manually on confiuguration "dailyset1"

$ /usr/sbin/amdump dailyset1
You have mail in /var/mail/amandabackup
  • Check mail or run the amreport command to view a report on the backup.

Example: amreport command generating report in file dailyset1.log for backup run 0 dated 01 May 2009

amreport dailyset1 -f dailyset1.log -l /etc/amanda/dailyset1/log20090501124748.0

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 configurations

This section provides an example for creating customized Amanda configurations instead of using configuration templates. This example backs up the /var/log directory from the Amanda client copper.zmanda.com to disk storage (/mnt/storage) on the Amanda server quartz.zmanda.com using the harddisk configuration template. All commands are executed on the Amanda server quartz.zmanda.com

See Notes in the Configuring Amanda with templates for the 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.20070502142202.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.conf 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.20070502101637.debug
/etc/amanda/dailyset1/disklist.conf updated
updating /var/lib/amanda/.amandahosts on quartz
/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
  • amserverconfig will create 25 virtual tape slot directories under "/mnt/storage" directory and label them using amlabel.
  • 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 3.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

  • "GNUTAR" is the recommended backup program for Amanda enterprise edition. The Program parameter in the dumptype section of amanda.conf should be set to "GNUTAR".
  • "bsdtcp" is the recommended authentication mechanism between server and client. It uses fewer ports, thus simplifying firewall configuration.
  • "ssh" is the recommended encryption method if encrypted communication is required at your site. Encryption increases backup times significantly, and should be enabled only if your site requires it. In the dumptype definition, the auth parameter should be set to "ssh" and the ssh_keys parameter then must be set to "/var/lib/amanda/.ssh/id_rsa_amdump".
  • If you are using ssh for Amanda server and client authentication, encrypting client data is not necessary. In other words, do not 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. 

Example: Recommended dumptype configuration

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

Client/Server authentication

Amanda enterprise edition provides authentication mechanisms for both backup as well as recovery process. There are multiple authentication mechanisms supported. Every amanda client can have different authentication mechanism. Authentication is configured in the dumptype definition entered in amanda.conf(5).

Example: dumptype with bsdtcp authentication

define dumptype copper-dumptype {
   ....
   auth "bsdtcp"
}

Table: List of characteristics of each authentication and ports used by backup process - amdump

Auth method Protocol Port used
on server
Port used
on client
Transport Advantage
bsd tcp and udp 1 reserved udp and
1 normal tcp
10080 udp and
3 normal tcp port per Disk List Entry (DLE)
clear text widely used,
better performance
bsdudp tcp and udp 2 reserved udp and
1 normal tcp
10080 udp and
1 normal tcp port per DLE
clear text uses less ports
bsdtcp tcp only 1 reserved tcp 10080 tcp clear text uses only 1 port,
no UDP packet size limitation
ssh tcp only 1 normal tcp ssh tcp port encrypted secure authentication
and transport encryption


 

Table: List of ports used by amrecover

Auth method Port used
on server
Port used
on client
bsd 10080 udp and
3 normal tcp
1 reserved udp and
1 normal tcp
bsdudp 10080 udp and
2 normal tcp
1 reserved udp and
1 normal tcp
bsdtcp 10080 tcp 1 reserved tcp
ssh ssh tcp port 1 normal tcp


 

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


For more details on configuring security features, see Amanda Enterprise Edition Security Features section.

Backing up Access control lists and Extended file attributes

Linux/Solaris file systems such as ext3fs and XFS can store Access Control Lists (ACLs) and file attributes for individual files. Schily tar, or star (pronounced ESS-tar) can optionally back up and restore both ACLs and extended file attributes. Windows file systems extended file attributes are backed up automatically by Zmanda Windows Client.

Amanda can use star as a backup mechanism. Using GNU tar will not back up ACLs and extended file attributes. Please note that the dump program (which backs up entire filesystems) will backup ACLs and extended file attributes for individual files.

In an Security Enhanced (SE) Linux environment, the mandatory access control lists are stored as extended file attributes. So in an SE Linux environment, using star as a backup mechanism is also mandatory.

In any case, star provides better backup performance than the GNU tar progam, resulting in a decreased backup window.

Configuring Schily tar (star) backups

Schily tar (star) is supported by Amanda enterprise edition in same manner as the 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 the 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

The star program requires a backup level 0 (full backup) backup to be complete before it can run incremental backups. The backup process will fail if an incremental backup is done before an initial full backup. The star program maintains /etc/tardumps to track backup levels and timestamp files on the Amanda client. This file must not be modified by the user.

Recovery from backups done using star command

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

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 multi-terabyte backup images that can span multiple volumes. The support of large backups is subject to availability of Amanda system and network resources. There are many configuration parameters that can be used to optimize the performance of large backups.

Splitting backup images into multiple volumes 
Backup images larger than a single media volume must be split to span multiple volumes. 
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 disklist entry in the client that has the large filesystem to back up.
Specify calcsize or server method of estimating image size
Using the default client method to estimate the backup image size for a given backup level can be time-consuming, especially for large filesystems. You can reduce the backup window by specifying estimate server or or estimate calcsize in the amanda.conf file.
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 client data can reduce file transfer times between client and 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.

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.6.3. Contacting server on localhost ...
220 quartz AMANDA index server (3.0) ready.
200 Access OK
Setting restore date to today (2007-05-02)
200 Working date set to 2007-05-02.
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
2007-05-02-15-50-27 ssh_config
2007-05-02-15-50-27 foo.gpg
2007-05-02-15-50-27 foo
2007-05-02-15-50-27 config-2.6.11-1.1369_FC4smp
2007-05-02-15-50-27 asimple
2007-05-02-15-50-27 System.map-2.6.11-1.1369_FC4
2007-05-02-15-50-27 .

 

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

amrecover> setdate 2007-02-21-15-47-19
200 Working date set to 2007-02-21-15-47-19.
amrecover> ls
2007-02-21-15-47-19 ssh_config
2007-02-21-15-47-19 rpm-tmp.92294
2007-02-21-15-47-19 rpm-tmp.83787
2007-02-21-15-47-19 rpm-tmp.81866
2007-02-21-15-47-19 rpm-tmp.65537
2007-02-21-15-47-19 rpm-tmp.65462
2007-02-21-15-47-19 rpm-tmp.42926
2007-02-21-15-47-19 rpm-tmp.42601
2007-02-21-15-47-19 rpm-tmp.41519
2007-02-21-15-47-19 rpm-tmp.37869
2007-02-21-15-47-19 rpm-tmp.27296
2007-02-21-15-47-19 rpm-tmp.25634
2007-02-21-15-47-19 foo.gpg
2007-02-21-15-47-19 foo
2007-02-21-15-47-19 config-2.6.11-1.1369_FC4smp
2007-02-21-15-47-19 asimple
2007-02-21-15-47-19 System.map-2.6.11-1.1369_FC4
2007-02-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 May 02, 2007 15:50:27 to /tmp/recover2 directory

amrecover> lcd /tmp/recover2
amrecover> setdate 2007-05-02-15-50-27
200 Working date set to 2007-05-02-15-50-27.
amrecover> ls
2007-05-02-15-50-27 ssh_config
2007-05-02-15-50-27 foo.gpg
2007-05-02-15-50-27 foo
2007-05-02-15-50-27 config-2.6.11-1.1369_FC4smp
2007-05-02-15-50-27 asimple
2007-05-02-15-50-27 System.map-2.6.11-1.1369_FC4
2007-05-02-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.0 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

Configuring an Alternative Mail Program

By default, Amanda assumes the local mail program found during initial configuration will be used to send notifications. You may wish to override this. For example, if your site uses an SMTP server, you can configure Amanda to use that instead of the program found during initial configuration. Use the mailer directive in the amanda.conf file:

mailer mail_program_path

The mail program must be able to process messages using the syntax:

MAILER -s "subject" user < message_file

Using Tertiary Media for Backup and Restore

Tertiary Media is a "backup of a backup" that provides an extra layer of protection for essential data. One way to use tertiary media is to produce off-site copies of backups that are kept on-site for recovery from hardware failure and user errors: if a disaster destroys the office, having offsite copies of backups can save your business.

Amanda provides the amvault (8)utility to create a copy of an existing backup run (identified by date and timestamp). In the context of amvault, the existing source backup is referred to as "secondary media," and the target is the tertiary media.

Using amvault to copy a backup run to tertiary media

Amvault makes one-to-one copies of each piece of media used in a backup run The syntax for amvault is:

amvault [-o Amanda.conf_options] backup_set src-run-timestamp changer label-template

Amanda.conf_options can be any of the options described in amanda.conf (5).

Backup_set is the name of the source backup set.

src-run-timestamp is the timestamp of the backup run you wish to copy. Specify lastest uses the most recent run.

changer is the name of the changer to use as defined by amanda.conf (5).

label-template specifies the string used to prefix the tertiary backup media labels. The string should contain some number of contiguous % characters, which will be replaced with a generated number. Be sure to specify enough % characters that you do not run out of tape labels. Example: DailySet1-%%%

For example, to produce a tertiery backup of MyBackupSet to changer MyChanger with label prefixes of "off-site-N" for the tertiary backup media, you would enter the following command:

amvault MyBackupSet latest MyChanger off-site-%%%

The amvault (8) man page describes these options in more detail.

Restoring from Tertiary Media

When you use  amrecover(8) against a backup set, Amanda looks for secondary backup media to restore from first. If none is found, it automatically looks for tertiary media to restore from. 

Upgrading to Amanda Enterprise Edition 2.6.3 with ZMC

You can use Amanda rapid installer to upgrade from Amanda Enterprise 2.6.3 server to Amanda Enterprise 2.6.3 server with Zmanda Management Console for the supported platforms.

Amanda configurations on the server are not impacted by the upgrade. Zmanda management console can be used to look at reports as well as restore from backups completed using Amanda enterprise 2.6.3 release.

Upgrading from Amanda Enterprise Edition 2.6.X

You can use Amanda rapid installer to upgrade from Amanda Enterprise 2.6 and 2.6.1 The rapid installer will take care of upgrade changes to the dependencies as well as the server.

Amanda configurations on the server are not impacted by the upgrade. Zmanda management console can be used to look at reports as well as restore from backups completed using Amanda enterprise 2.6 and 2.6.1

Upgrading from Amanda Enterprise Edition 2.5.X

All data backed up by Amanda Enterprise Edition 2.5.X can be recovered using Amanda Enterprise 2.6 tools. Amanda Enterprise 2.6 provides the amoldrecover command to recover from an Amanda Enterprise 2.5.0 server. Recovery from Amanda Enterprise Edition 2.5.0 server documents this procedure.

Zmanda recommends a rolling upgrade procedure for upgrading to Amanda Enterprise Edition 2.6.X The recommended upgrade sequence is:

  1. Upgrade one of the Amanda clients to Amanda Enterprise Edition 2.6.X
  2. Upgrade all Amanda clients to Amanda Enterprise Edition 2.6.X
  3. Upgrade Amanda server to Amanda Enterprise Edition 2.6.X
  4. If the configuration is using the "bsd" authentication mechanism, upgrading to "bsdtcp" authentication is recommended.

It is possible to do both backups and recovery at any point during the rolling upgrade sequence. However, to use the newer features of Amanda Enterprise Edition 2.6.X, it is necessary to complete the upgrade process.

NOTE: Make Amanda server and client configuration changes during Step 3 of the rolling upgrade procedure. Perform these steps as the amandabackup user unless noted otherwise.

The following section also describes the changes required for switching authentication mechanism.

Configuration file changes on the Amanda server

Update amanda.conf

Change auth in the dumptype definition to use one of the supported authentication mechanisms - bsd, bsdudp, bsdtcp or ssh. "bsdtcp" is recommended.

The auth chosen needs to match the authentication chosen in xinetd.conf and amanda-client.conf configuration files on the Amanda client.

If SSH is chosen, add ssh_keys to the dumptype definition.

Example:

ssh_keys "/var/lib/amanda/.ssh/id_rsa_amdump"

Update /etc/xinetd.d/amandaserver

This step must be performed as root.

If bsdudp authentication is being used, add the following line to the amanda service entry:

"server_args             = -auth=bsdudp amindexd amidxtaped"

For bsdtcp authentication, replace the amanda service entry in /etc/xinetd.conf/amandaserver file to:

   service amanda
   {
       disable               = no
       socket_type     = stream
       protocol        = tcp
       wait            = no
       user                  = amandabackup
       group                 = disk
       groups                = yes
       server                = /usr/lib/amanda/amandad
       server_args     = -auth=bsdtcp amindexd amidxtaped
   }

No changes are required for "bsd" and "ssh" authentication Update /var/lib/amanda/.amandahosts to 2.5.1 or later format

Amanda enterprise edition 2.5.0 format: <client FQDN hostname> root Amanda enterprise edition 2.5.1 or later format: <client FQDN hostname> root amindexd amidxtaped amanda

For example: The following line allows the Amanda client, iron.zmanda.com, to connect to the Amanda server to perform data recovery

  iron.zmanda.com root amindexd amidxtaped

To use ssh auth, generate ssh-key and distribute to all clients. Run the following command:

   ssh-keygen -t rsa

Enter the name of a file in which to save the key (/var/lib/amanda/.ssh/id_rsa)? /var/lib/amanda/.ssh/id_rsa_amdump

Copy /var/lib/amanda/.ssh/id_rsa_amdump.pub to Amanda client machines through a secure channel.

Prepend the line with the following:

from="tape_server_fqdn_name",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/path/to/amandad -auth=ssh amdump"

Append it to /var/lib/amanda/.ssh/authorized_keys and set file permissions for authorized_keys appropriately.

$ chmod 600 ~amandabackup/.ssh/authorized_keys

Example:

from="quartz.zmanda.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/amanda/amandad -auth=ssh amdump"  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAzVBUEN7XO/s9F0178V41HZE7GdNnnAQh7kMDbQD4eo1m9Zqc257XlZC97YY76WHBNI163Tof7dnS8aSmVfIPUZHQRYIPtY9abESTGJkOuLxZRjsnQWHQ0sBdZ5VEmDzEt8SAnaESoZS2IFffe5sTHtAKhbjhIOVvfCkGe1tW9K0= [email protected]

Make sure the Amanda client is in the SSH known_hosts file

# ssh iron.zmanda.com
The authenticity of host 'iron.zmanda.com (192.168.10.1)' can't be established.
RSA key fingerprint is 26:4e:df:a2:be:c8:cb:20:1c:68:8b:cc:c0:3b:8e:9d.
Are you sure you want to continue connecting (yes/no)?yes


Set ssh_keys in the dumptype.

ssh_keys "/var/lib/amanda/.ssh/id_rsa_amdump"

Configuration file changes on Amanda Client

Create /etc/amanda/amanda-client.conf.
See Amanda-client.conf man page for details. This configuration file is used by recovery process only. Example: amanda_client.conf

  conf "test"
  index_server "quartz.zmanda.com"
  auth "bsdtcp"                       # auth chosen needs to match what is running on the Amanda Server
  tape_server "quartz.zmanda.com"
  ssh_keys "/var/lib/amanda/.ssh/id_rsa_amrecover"   #only if ssh is used

Update /etc/xinetd.d/amandaclient

No changes are required for bsd and ssh configuration files.

For bsdudp authentication, Add the following line to amanda service entry

               "server_args             = -auth=bsdudp amdump"

For bsdtcp authentication, replace the amanda service entry in /etc/xinetd.conf/amandaserver file with

service amanda
{
       disable               = no
       socket_type     = stream
       protocol        = tcp
       wait            = no
       user                  = amandabackup
       group                 = disk
       groups                = yes
       server                = /usr/lib/amanda/amandad
       server_args     = -auth=bsdtcp amdump
}

Update /var/lib/amanda/.amandahosts to 2.5.1 or later format

Amanda Enterprise Edition 2.5.0 format: <server FQDN hostname> amandabackup
Amanda Enterprise Edition 2.5.1 or later format: <server FQDN hostname> amandabackup amdump

Example: The following line allows Amanda server, quartz.zmanda.com to perform backups

  quartz.zmanda.com amandabackup amdump
  • To use ssh auth, generate ssh-key and copy to Amanda Server

Log in to the system as superuser

  #ssh-keygen -t rsa
  Enter file in which to save the key (/root/.ssh/id_rsa)? /var/lib/amanda/.ssh/id_rsa_amrecover

Copy /var/lib/amanda/.ssh/id_rsa_amrecover.pub to Amanda server machines through a secure channel.
prepend the line with the following:

    from="client_fqdn_name",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/path/to/amandad -auth=ssh amindexd amidxtaped"

Append it to /var/lib/amanda/.ssh/authorized_keys and set file permissions for authorized_keys appropriately.

$ chmod 600  /var/lib/amanda/.ssh/authorized_keys

Example:

from="copper.zmanda.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/amanda/amandad -auth=ssh amindexd amidxtaped" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA4rOMQbUJxDiMllx8pnjr3hLWZvubzDGKQYdzJATORRQoyUNaEt16Xna14IAYbpmrQLnmYUcgvE8+jP8XzO3LTqQQtcakds5TKTB6dDZ287U9mE/H7p5GvpHTyURFLQ2ymB9q37g07VdNcvGETCS0rkpCfZx4qU+9bMNuCm3LqJ0= [email protected]

Make sure server is in ssh known_hosts file

#ssh quartz.zmanda.com
The authenticity of host 'quartz.zmanda.com (192.168.10.1)' can't be established.
RSA key fingerprint is 26:4e:df:a2:be:c8:cb:20:1c:68:8b:cc:c0:3b:8e:9d.
Are you sure you want to continue connecting (yes/no)?yes

Set auth and ssh_keys in /etc/amanda/amanda-client.conf properly.

auth "ssh"
ssh_keys "/var/lib/amanda/.ssh/id_rsa_amrecover"
Xinetd entries for an Amanda server and client on the same machine

If the Amanda server is also an Amanda client, the "amanda" service entry in the /etc/xinetd.d/amandaserver configuration file should contain "amdump", "amindexd" and "amidxtaped" in the server_args field.

Example: Amanda server is also an Amanda client using bsdtcp authentication

service amanda
{
disable                 = no
socket_type             = stream
protocol                = tcp
wait                    = no
user                    = amandabackup
group                   = disk
groups                  = yes
server                  = /usr/local/libexec/amandad
server_args             = -auth=bsdtcp amdump amindexd amidxtaped
}

"amanda" is the service name and is responsible for starting the amdump process on the client and amindexd/amidxtaped on the server. Remove the amandaidx and amidxtape service entries from the /etc/xinetd.d configuration directory.

Recovery from Amanda Enterprise Edition 2.5.0 server

If you are using Amanda Enterprise Edition 2.6.X client to recover from Amanda Enterprise Edition 2.5.0 (Step 1, 2 of rolling upgrade procedure), use amoldrecover command. The amoldrecover command has the same syntax as amrecover command.

The /var/lib/amanda/.amandahosts file on the Amanda enterprise edition 2.6.X client must use the 2.5.0 format for amoldrecover command to work.

Zmanda Windows Client 2.6.4 will not work with Amanda Enterprise Edition 2.5.X or older versions of 2.6 servers

Amanda Enterprise Edition 2.5.0 format: <server FQDN hostname> amandabackup

Migration from Amanda Community Edition

Amanda community edition 2.6.1 is fully compatible with Amanda enterprise edition 3.0. The recommended upgrade procedure is to use Amanda Enterprise Edition clients with Amanda Community Edition server. Upgrade all clients to the Amanda Enterprise Edition 3.0 before upgrading the Amanda server to Amanda Enterprise Edition 3.0.

Earlier versions of Amanda Community Edition have not been extensively tested with Amanda Enterprise Edition and might require configuration changes to work with Amanda Enterprise Edition 3.0 Please contact [email protected] if you are interested in migrating from Amanda Community Edition 2.5.X or 2.6.X to Amanda Enterprise Edition 3.0.

 
Powered by MindTouch Deki v.8.08.2