ZMC User's Manual for Amanda Enterprise Edition 3.4
The Amanda open source backup server protects more data than any other open source backup solution. It allows backup administration through a single backup server that can back up one or more client systems. Amanda Enterprise combines the benefits of open source backup with enterprise-level support, a graphical user interface for the server, and enhanced backup client software such as the ability to perform hot backups on Windows server applications (separate licensing required).
The advantages of Amanda/Amanda Enterprise include:
Please see the latest platform support information on the Zmanda Network at http://www.zmanda.com/supported-platforms.html.
This page describes the environmental requirements you should verify before running the install program. The Amanda Enterprise components required on each are described in Downloading and Installing Amanda Enterprise Components.
Throughout this document, The Amanda Client refers the system being backed up by the Amanda Enterprise Server, which also called the Amanda Server or backup server.
Backup server performs various CPU, Memory, Network, and Disk intensive operations. While hardware requirements will vary based on your backup environment, we recommend a server with at least 4GB of memory and a modern quad-core server-class CPU. The bandwidth of the network link between backup server and your network switch is also very critical. If network bonding is supported by your switch, we recommend providing a bonded connection to the backup server.
The following packages are required on the Amanda backup server and clients:
Solaris 10/11 and Open Solaris
Program Dependencies: The following programs are needed for Linux backup server and client
These additional programs are required on the Linux backup server
Library Dependencies: The server packages are 32bit, so 32bit libraries are required. Native 32bit systems already have the required libraries. 64bit systems require the 32bit compatibility libraries. They are available for RHEL/CentOS/SLES/Oracle Enterprise/Fedora/Open Suse Linux platforms. On Ubuntu/Debian platforms, they may not be available for older platforms. On Ubuntu/Debian platforms, they may not be available for older platforms. See Linux Debian/Ubuntu for more details.
These packages are installed by default on most Linux distributions. If you need to add them, you can use yum, apt-get, or yast. Packages can be obtained from the distribution media or from a distribution repository (run either as root):
#yum install package_name
or
#apt-get install package_name
or
#yast -i package_name
In the case of yast on SLES, you can also use the YaST Online Update (YOU) to install new package and to keep the SLES distribution updated (which is recommended).
For example:
Amanda server installation on 64bit RHEL 6/CentOS 6/Oracle Enterprise Linux will require the following packages:
# yum install compat-libstdc++-33.i686 curl glib2.i686 glibc.i686 gnupg libcurl.i686 libgcc.i686 libidn.i686 libstdc++.i686 libXp.so.6 mailx ncurses ncurses-libs.i686 readline.i686 tar xinetd zlib.i686 openldap24-libs.i386
Amanda server installation on 64bit Debian 6 will require the following packages:
# apt-get install gettext gnuplot ia32-libs lib32gcc1:i386 libcurl3:i386 libcurl3-gnutls:i386 libglib2.0-0:i386 libidn11:i386 libpcre3:i386 libreadline6:i386 libssh2-1:i386 lsb-release lsscsi mailutils mt-st mtx xinetd
Amanda server installation on 64bit Debian 7 will require the following packages:
# apt-get install lib32stdc++6 bsd-mailx gcc-4.7-base:i386 gettext libc6:i386 libffi5:i386 libgcc1:i386 libglib2.0-0:i386 libncurses5:i386 libpcre3:i386 libreadline5:i386 libselinux1:i386 lsb-release lsscsi mt-st mtx xinetd zlib1g:i386
Amanda server installation on 64bit Debian 8 will require the following packages:
# apt-get install bsd-mailx gcc-4.9-base:i386 gettext libc6:i386 libffi6:i386 libgcc1:i386 libglib2.0-0:i386 libncurses5:i386 libpcre3:i386 libreadline5:i386 libselinux1:i386 lsb-release lsscsi mt-st mtx xinetd zlib1g:i386 libstdc++6:i386
Amanda Enterprise server installation on 64bit Ubuntu 14.04 will require the following packages:
# apt-get install gcc-4.9-base:i386 libc6:i386 libstdc++6:i386 libgcc1:i386 libglib2.0-0:i386 libffi6:i386 libncurses5:i386 libpcre3:i386 libreadline5:i386 libreadline6:i386 libselinux1:i386 zlib1g:i386 lsb-release lsscsi mt-st mtx bsd-mailx mailutils xinetd
Note: To install 32bit packages on 64bit Debian 7 or Debian 8, please run
# dpkg --add-architecture i386
# apt-get update
The following packages are required on the Amanda clients:
The Amanda backup client requires 32-bit version of following Debian packages; Amanda 64-bit backup client requires the following 64-bit version Debian packages
The AE 32bit client requires the following 32-bit packages; AE 64-bit backup client requires the following 64-bit packages
For RHEL/CentOS 5 and earlier versions and Fedora, please install the following packages:
ncurses.i686
libgcc.i686 (for fedora platforms only)
For RHEL/CentOS 6, please install the following packages:
For example: In case of 64bit RHEL6/CentOS 6/Oracle Enterprise Linux, following yum command line should be used (this list includes direct Amanda Enterprise and indirect dependencies)
# yum install glibc.i686 xinetd nss-softokn-freebl.i686 glib2.i686 libselinux.i686 gamin.i686 readline.i686 ncurses-libs.i686 zlib.i686 libstdc++.i686 libgcc.i686 perl-Switch perl-JSON perl-Encode-Locale perl-Data-Dumper
On 64bit SLES 11 platforms, these packages are called
32-bit packages for dependencies are required for all Amanda Solaris server and clients.
It is easier to install dependencies by using Solaris pkgutil tool available at the http://www.opencsw.org/get-it/pkgutil/ It automatically get all indirect dependencies. Use the following pkgutil command to install dependencies on Solaris server (you can install gnupg2 instead of gnupg):
pkgutil -i gtar gnupg gawk libgcc_s1 mtx
Use the following pkgutil command to install dependencies on Solaris Client (you can install gnupg2 instead of gnupg):
pkgutil -i perl gtar gnupg libcurl4
Download and install the package dependencies available from the Zmanda Network download page when you select Mac OSX as the client platform.
The amandabackup user must exist, and be added to the Users, Backup Operators, and Administrators groups. Windows clients must open inbound TCP ports 10080 and 10081, and outbound TCP ports 700:800. Windows application backups (licensed as separate agents) require that the Volume Shadow Copy Service be enabled and started. To prevent excessive memory consumption on application backup clients, Zmanda also recommends that you install the following VSS hotfix from Microsoft:
Link to Microsoft Knowledgebase
See the The Zmanda Windows Client User's Manual for further details on Windows client installation.
index_server "localhost" # your amindexd server tape_server "localhost" # your amidxtaped server
Change "localhost" to match to the hostname of the Amanda backup server.
On MacOSX systems, run the following command: launchctl unload -w /Library/LaunchDaemons/org.amanda.zmrecover.plist. To re-enable the standard client restore mechanism, enter: launchctl load -w /Library/LaunchDaemons/org.amanda.zmrecover.plist.
The following browsers have been tested and verified to work with the Zmanda Management Console:
In all cases you must have JavaScript enabled. Note that if JavaScript is enabled during a session either in the browser itself or in a plug-in such as NoScript, you must log out of the ZMC and then log in again to avoid potential problems with the interface. If you are browsing over a slow connection such as dial-up, loading of the JavaScript files may time out after 15 seconds with the following error:
ZMC has not yet loaded required javascript files. Do you want to continue waiting for these files to load?
Clicking OK will cause the ZMC to try again for 60 seconds. If that fails, another error. If it takes more than 60 seconds to load the JavaScript files, logging out and then in again will usually give the browser enough time to cache all necessary JavaScript files and allow the ZMC to load.
To install the ZMC, you must first download Amanda Enterprise Edition with the Zmanda Management Console. Packages for all Zmanda products are available from the Zmanda network downloads page. The Amanda Enterprise Edition with ZMC package includes:
You can upgrade from earlier version of 3.3.x by running the installer. The installer detects the older version of 3.3.x release and automatically upgrade to newer release. Please check 3.3.x release notes for any caveats.
During upgrade, the installer will prompt the user to preserve configuration and catalog information. It is important to preserve configuration and catalog if you want to restore from older backup images and use backup set policies created using earlier version of 3.3.x release.
ZRM and Amanda Enterprise must be installed in a specific order to work. Please perform the following procedure as superuser on the backup server. If you need to install ZRM 3.6 on top of Amanda Enterprise 3.3.x, please contact Zmanda Support team.
/etc/init.d/zmc_zrm stop
/etc/init.d/zmc_aee stop
/etc/init.d/zmc_zrm start
/etc/init.d/zmc_aee start
After you have purchased a base license and any feature licenses (such as application module licenses), the Zmanda Network Downloads page will include an option to download a license key (zmanda_license). Download this file and save the file as /etc/zmanda/zmanda_license on the Amanda Enterprise Linux server, then make sure that the file permissions are set to 644 and owner is root. On Solaris servers, The license file location is /opt/zmanda/amanda/etc/zmanda/zmanda_license.
Although the Zmanda Management Console is shipped with pre-packaged Apache SSL certificate to get you started, Zmanda recommends you purchase (or create your own self-signed) SSL certificates and distribute them to all the browsers from which you wish to access the ZMC. The pre-packaged certificates are not secure (as they are shared by all Zmanda customers). These generic certificates will also generate security warnings on some browser versions.
Zmanda recommends that you either 1) Create self-signed certificates and distribute them to all the client machines that require access to the ZMC, or 2) Distribute certificates from a recognized Certificate Authority. Option 1 (self-signed certificates) is free, and is adequate for most organizations that deploy ZMC servers and the machines that access them '''behind the same firewall'''.
If using a certificate from a recognized Certificate Authority, your browser will automatically create the secure connection with no errors or warnings.
If using a self-signed certificate, you must then deploy a mechanism to get the relevant browser(s) to accept this new root CA. One method is to generate the certificate using a special format that can be directly imported by common web browsers, and then providing a link on a secure intranet for ZMC users to download (web browsers automatically display the import dialog if the file is in the correct format and sent by the intranet web server using the correct mimetype). PKCS12 (now part of OpenSSL, provides a mechanism to distribute self-signed private key certificates in a number formats recognized by different browsers.
Another approach is to manually add the new self-signed root CA to the root CA list of the client system, which will automatically provide access to the new CA for all web browsers on the client system. This article covers the procedures for doing this in a Microsoft Windows server environment.
For more details on certificate validation issues, see this article from OpenSSL.
For installation using a method other than the Rapid Installer, please see the sections that follow.
1. Copy the Rapid Installer binary file to the host where the given component will be installed.
2. Log in to the host as the superuser.
3. Make sure that the Rapid Installer binary file (it may have .bin extension also) is executable. For example:
# chmod +x amanda-enterprise-3.3.2-installer.run
4. Run the installer by double-clicking on it, or enter the following command line:
# ./amanda-enterprise-3.3.2-installer.run
5. The Rapid Installer then starts. Follow the on-screen instructions.
Important Note: When prompted to choose the Zmanda Web Server protocol, we strongly recommend that you choose https for security reasons. Even if you choose http for browser/ZMC communication, the ZMC still requires HTTPS for internal communication purposes, and will therefore prompt you for an SSL port during installation in all cases.
Note: The installer performs several tasks after creating and populating the Zmanda directories. These are completed after the progress bar (which only tracks the archive extraction) shows 100% completion. These tasks take time. Please wait till they complete.
6. After the Amanda Enterprise binaries have been extracted and installed, the Zmanda Management Console is launched and the readme file is displayed. The readme file includes the default Zmanda Management Console username and password. You can now login to the console using any supported browser and begin configuring backup sets.
Run the installer with the --help option to see what command line parameters are available.
Important Note to Customers of ZRM for MySQL: Before running the uninstall script for Amanda Enterprise, you must first stop the ZRM for MySQL services from running (enter /etc/init.d/zmc_zrm_init stop as root), then restart it manually after the uninstall script completes (/etc/init.d/zmc_zrm_init start).
You can uninstall Amanda Enterprise by running the uninstall script located at /opt/zmanda/amanda/uninstall on the backup server. Using this script, you can remove the Amanda Enterprise binaries, with the option of leaving configuration files intact. Follow the on-screen instructions after running the script.
The uninstaller program does not remove the backup scheduled in the crontab. They will have to be removed manually.
Zmanda Management Console is accessed using a web browser. Amanda Enterprise is supported on latest version of Internet Explorer, Mozilla FireFox and Google Chrome.
Please access https://<host name of the Amanda server>/ if you are using default port. If you had changed the port number using installation, please use URL https://<host name of the Amanda server>:<port number>/
The default port is 443. Please make sure access to this port is allowed by network configuration (such as firewalls).
These are the file locations on Linux server.
Amanda Enterprise files are installed in following directories:
Amanda Server File(s) Location CLI Executables /usr/sbin Man pages /usr/share/man GUI/Web Components (including GUI log files) /opt/zmanda/amanda, /opt/zmanda/common License key file /etc/zmanda/zmanda_license Backup Set and other configuration files /etc/amanda, /etc/cron.d, /etc/logrotate.d Libraries /usr/lib Amanda-controlled executables /usr/lib/amanda Amanda Perl Libraries /usr/lib/amanda/perl Amanda Debug log files /var/log/amanda/
Backup images (vtapes) and staging area (holding disk) /var/lib/amanda (default location for backup to disks)
On Solaris server, the Amanda Enterprise files are located at /opt/zmanda/amanda directory. For example: The configuration files under /etc/amanda in Linux server will be found under /opt/zmanda/amanda/etc/amanda on Solaris server.
Do not directly delete or change any of these files or directories unless directed to do so by the Zmanda Support Team. Changing any of these files directly can result in failed backups and other problems.
Zmanda provides Amanda server disaster recovery solution to protect Amanda server. Please contact Zmanda Sales or Zmanda Support Team for more details.
You should monitor free space availability in /tmp, /etc/amanda and /opt/zmanda/amanda directories. At least 10% free space must be available in these file systems. Amanda stores the backup index, Zmanda Management Console database and temporary files in these locations, and thus these directories can fill up over time. The /tmp directory is also used to store backup images temporarily during the restore process, which can fail if it runs out of space. Lack of space in these directories can affect Amanda functionality and performance.
Amanda Debug log files are collected by Zmanda support tool for troubleshooting Amanda problems. Amanda debug file for a process or command instance are kept for four days for each backup set.
Zmanda Management Console is accessed using a web browser. Amanda Enterprise is supported on latest version of Internet Explorer, Mozilla FireFox and Google Chrome.
Please access https://<host name of the Amanda server>/ if you are using default port. If you had changed the port number using installation, please use URL https://<host name of the Amanda server>:<port number>/
The default port is 443. Please make sure access to this port is allowed by network configuration (such as firewalls).
If you are running Amanda Enterprise and ZRM Enterprise products on the same server, you will have to use port number configured during Amanda Enterprise installation to access both Amanda Management console and ZRM Management console.
This is the first page of Zmanda Management Console. If you are running Amanda Enterprise and ZRM Enterprise products on the same server, you will get a product selection page.
The default user is admin/admin Please change the password in the ZMC Admin Users page. This user is different from Zmanda Network user and operating system user.
If you are making changes to Backup Sets manually, you should enable Sync Backup Sets at the time of login process. Otherwise, ZMC will present incorrect information.
ZMC can check the Amanda server installation and dependencies at the time of login. This process can take time. You should enable Check Server Installation when you are logging in the first time or if you logging in after hardware or OS upgrade. If there are errors in server installation, please resolve them before a backup or restore job is started. Please note that these checks are not the same as the client checks performed by the Check Hosts action in the Backup What page.
If you do not remember the password, please click Can't access your account? link. You will see the following section as shown below. Please enter the ZMC user name in the Lost Password section.
Please enter the ZMC user name in the Lost Password section. Please note that password will be mailed to the mail address registered to the ZMC user account. Please note that email service should be configured on the Amanda backup server to receive the lost password email.
ZMC will ask Zmanda Network User name and password if you login as admin user. This authentication allows ZMC to connect to Zmanda Network to authenticate the user as well as obtain alerts including security alerts.
Zmanda Network Authentication is not supported when Web proxy server is in use. If there is a web proxy server or there is no internet connection on the Amanda server, please select Cancel button.
Zmanda Network Authentication is performed every time ZMC admin user logs in.
Amanda Backup server configuration is done in terms of backup sets. The backup set is a grouping mechanism that simplifies and optimizes backing up many systems with different backup requirements. It lets an administrator define a set of backup policies (what, how, where and when) to different backup runs.
All ZMC actions (backup, restore, reporting, and monitoring) are performed in the context of backup sets.
Backup sets cannot share target media volumes. For example, two backup sets can use the same tape changer simultaneously, but each should have a separate set of slots.
Multiple backup sets are useful for protecting a large number of systems with different backup requirements, but many organizations with less complex backup requirements can define a single backup set to meet their needs. For example, on a network that includes servers with high rate of data change along with desktop systems that change more slowly, you would probably want to create one backup set for the servers, and another backup set for the desktops.
All data to be backed up can be organized in backup sets based on:
A backup set is a uniquely-named record of backup policies, including:
Amanda ensures that two backup sets do not write to the same tape (or to the same directory if disk media is used for backup). Amanda also enforces that it does not accidentally overwrite a tape/disk belonging to another backup set.
Backup sets are created in Admin Backup sets page as shown below.
You can create Storage devices for backups in Admin devices page. Generic information about the devices are configured in this page. All devices supported by Amanda Enterprise can be configured in this page. After creating device configuration, you can bind the device to the backup set.
The Backup tab lets you configure and edit backup sets. The six sub-tasks under the Backup tab let you specify the parameters of the currently selected backup set:
Once this information has been specified,
Zmanda Management Console is accessed using a web browser. Amanda Enterprise is supported on latest version of Internet Explorer, Mozilla FireFox and Google Chrome.
Please access https://<host name of the Amanda server>/ if you are using default port. If you had changed the port number using installation, please use URL https://<host name of the Amanda server>:<port number>/
The default port is 443. Please make sure access to this port is allowed by network configuration (such as firewalls).
If you are running Amanda Enterprise and ZRM Enterprise products on the same server, you will have to use port number configured during Amanda Enterprise installation to access both Amanda Management console and ZRM Management console.
This is the first page of Zmanda Management Console. If you are running Amanda Enterprise and ZRM Enterprise products on the same server, you will get a product selection page.
The default user is admin/admin Please change the password in the ZMC Admin Users page. This user is different from Zmanda Network user and operating system user.
If you are making changes to Backup Sets manually, you should enable Sync Backup Sets at the time of login process. Otherwise, ZMC will present incorrect information.
ZMC can check the Amanda server installation and dependencies at the time of login. This process can take time. You should enable Check Server Installation when you are logging in the first time or if you logging in after hardware or OS upgrade. If there are errors in server installation, please resolve them before a backup or restore job is started. Please note that these checks are not the same as the client checks performed by the Check Hosts action in the Backup What page.
If you do not remember the password, please click Can't access your account? link. You will see the following section as shown below. Please enter the ZMC user name in the Lost Password section.
Please enter the ZMC user name in the Lost Password section. Please note that password will be mailed to the mail address registered to the ZMC user account. Please note that email service should be configured on the Amanda backup server to receive the lost password email.
ZMC will ask Zmanda Network User name and password if you login as admin user. This authentication allows ZMC to connect to Zmanda Network to authenticate the user as well as obtain alerts including security alerts.
Zmanda Network Authentication is not supported when Web proxy server is in use. If there is a web proxy server or there is no internet connection on the Amanda server, please select Cancel button.
Zmanda Network Authentication is performed every time ZMC admin user logs in.
The Backup What page specifies what is to be backed up: what clients, and what directories (or applications) on each client. ZMC can back up the whole network or a portion thereof, all from one central server.
To organize the backup in an efficient manner, ZMC divides the Enterprise into backup sets, and sub-divides each backup set into Host/Directory pairs called Disk List Entries (DLEs). The DLEs can also specify directories and files to be excluded from the backup. Encryption and compression options can also be applied at the DLE level.
Warning: You should not change backup set parameters while a backup run for that set is in progress. You can check the status of backup runs for a backup set by going to the Monitor page.
The top portion of the of the page lets you create and edit backup objects, which define the file system, database(s), or applications you intend to back up. After you select a type from one of the dropdown menus (or select an existing object from the list at the bottom of the page), appropriate options for that backup object are displayed:
Supported object types include the following. All objects are licensed. Note that the ZMC indicates how many licenses have been purchased and how many remain available for those object types that require licensing. Application Agents are described in more specific detail here.
Click the Add button at the bottom of the page to create a new entry, or select an entry from the table to edit. You can also duplicate an existing entry (see below) and then edit the entry before using the Add button to add it to table of backup objects..
Objects to be backed up (also known as "Disk List Entries" or "DLEs" in Amanda Community Edition) are listed in the table at the bottom of the page.
File System Options
The options for backing up file systems are essentially the same regardless of platform. Options pertaining to other object types are discussed in relevant sections of the Zmanda Application Agents Guide
"./platform" "./system" "./proc" "./tmp" "./dev" directories/file systems.
Excluding files can optimize the performance of the backup set, especially one that would otherwise back up an entire host from the root directory down.
Exclude specifications depends on the object type. The patterns supported are different for Linux/Solaris/Mac OS X and Windows. Please see next two sections for the details.
The Linux/Solaris/Mac OS X filesystems uses the GNU-tar utility (unless extended attribute backup is enabled) which supports exclude patterns. If backup of extended attributes are enabled (schily tar is used), exclude pattern cannot be specified.
The ZMC can accept one or more explicit pathnames or wildcard patterns per backup object/disk list entry, separated by a space. Some simple examples for GNU tar, Windows clients and Schily tar below.
GNU tar
You can explicitly exclude any file or directory by pathname. For example, it is recommended that you avoid backing up staging areas for backup sets, so if you are backing up a root directory (/) that includes staging area /var/lib/amanda/staging/, the exclude specification would be
./var/lib/amanda/staging. If the backup object/DLE is set to back up /var, the exclude specification would be ./lib/amanda/staging. The pathname in exclude specification should be relative to the DLE directory.
exclude "*.doc" *.txt
is saved as
exclude "*.doc" "*.txt"
Shadowed excludes are automatically deleted whenever the user saves any edit to the backup object/DLE. Thus a backup object containing an exclude list of:
exclude "*.doc"
exclude "*.txt"
will show only "*.txt" in the Exclude form field, and the first exclude ("*.doc") is removed from the backup object when any edits are saved.
Schily tar
Globbing characters and simple regex, for instance [A-Z], * character can be used to matchfiles and directories in the first level.
Windows filesystems support wildcards in the exclude specification. Wildcards "*" (match one or more character) and "?" (match exactly one character) are supported. The pathname in exclude specification can be absolute or relative to the DLE directory. For example: We are backing up C:\Data directory. We would like to exclude all files with *.jpg extension. The exclude specification should be "*.jpg". You can specify the directory name with the exclude pattern. For example: To exclude *.exe from C:\Data\Test and C:\Data is being backed up, specify "Test\\*.exe", To exclude a folder, specify "C:\users\all users\".
The list of patterns in the exclude specification for Windows file systems should be separated by space character.
When specifying exclude patterns for Windows clients, pathnames are case-insensitive. The ./ or .\characters do not work.
There are a number of different reasons to exclude files from a backup set.
This section describes the compression and encryption options common to most of the backup object types.
ZMC compresses the data on the Amanda server or client. Amanda client compression resulting in more efficient use of bandwidth when the backup image is sent to the server. ZMC supports compression using gzip, which creates archives that can be extracted almost universal. Compression levels - fast, best and custom can be specified. The fast compression provides smaller backup window. The best compression likely provides smaller backup sizes. The custom compression provides user an option to specify different compression command. Most common custom compression program used is /bin/pigz - this compression command provides faster, parallel compression that uses multi-core CPUs better.
Many Tape drives have built-in hardware compression. There are many advantages in allowing such hardware to handle the compression task.
TIP: Devices that use a proprietary compression can fail or otherwise becomes unusable, presenting difficulties in restoring from backups that were written to it. For images and other pre-compressed files, do not consume the backup window by pointlessly re-compressing them.
Backup data should be secured as carefully as you would protect the live version. Encrypting backup data adds a layer of protection against misuse.
Backup encryption can be performed on the server or on the client. It is important to store encryption key passphrases and certificates securely. Backups cannot be retrieved if the passphrase files or certificates are lost.
Encryption passphrase or keys must be provided during the restore process for the backup images to be decrypted. Amanda Enterprise does not provide encryption key management. Customers should make sure the encryption keys are backed up.
Note: Encryption is a CPU intensive task. Enable it with care.
ZMC encrypts the data on the Amanda server and Linux/Solaris clients using the amcryptsimple(8) program, which uses Gnu Privacy Guard (GPG) to perform symmetric data encryption.
Encryption passphrases are stored in the amandabackup user directory on the server. It is important to keep the encryption passphrases (default passphrase - /var/lib/amanda/.am_passphrase) safely and securely. The data cannot be restored without the passphrase. It is important to backup the passphrases on regular basis by adding /var/lib/amanda directory as an Amanda DLE without enabling encryption for that DLE. Also keep a backup of the passphrase in another secure location (for example: printed hardcopy).
ZMC uses encryption passphrase from the Amanda server to do restoration of Linux/Solaris/Mac encrypted backup images. You should copy the appropriate encryption passphrase file to the Amanda server - /var/lib/amanda/.am_passphrase (Linux/Mac) or /opt/zmanda/amanda/amanda/.am_passphrase (Solaris) before doing restoration of client encrypted backups using ZMC.
You can use command line tool - amrecover running on the Amanda client to restore client encrypted backups. The command line tool uses the encryption passphrase from the Amanda client to decrypt client encrypted backup images.
Backup encryption on Windows client is performed using AES encryption keys. Please see Windows Client manual for more details.
Extended Attributes
This is the default for Windows and Mac OS X filesystems.
This is an optional feature for Linux, UNIX, and Solaris filesystems. Enabling this option in these cases selects a different archive program used for backing up the given object type. When this option is enabled, Amanda Enterprise uses (and requires) Schily tar instead of GNU tar as the archive program. Schily tar is required on the Amanda client and is not installed by default on Linux. Schily tar package is available for download from Zmanda Network.
If the backup object is a Solaris ZFS file system, Extended Attributes refer to ZFS Access Control Lists (ACLS); see Solaris Client for details.
Please be aware that exclusions are not supported when selecting Extended Attributes for Linux, UNIX, and Solaris file systems.
Estimate
Selects the method used for estimating the backup window. You can choose from a number of options that balance the requirements of accuracy vs. speed. The "fastest" method can be accurate enough if the backup source remains relatively constant in size; the "Always Accurate" option may be too slow given the backup window, or may not be available from the given backup client. Options not supported for a given backup client are grayed out so that you cannot select them.
Alias
Alternate name can be provided for the backup object. This is useful when you are backing up the same file system with different exclude lists. You may have to do this to divide a large filesystem into multiple backup objects.
Client Max Backups
The maximum number of backup threads on the client. This is usually specified for each host. Specifying large value may not decrease the backup window because the backup client may not able run multiple threads. For example: Client compression can become the CPU bottleneck for multiple backup threads on the client.
Strategy
You can specify the backup level restrictions for the backup object such as perform only full backups, perform only incremental backup. You can also skip backup of backup object using this field.
Disable Staging
Some backup objects such as NDMP backups do not support Staging Area. They can be disabled on a backup object basis using this field.
Amanda Backup Client Application
Amanda can perform backup of objects using multiple applications. There is a default application for each backup object. You can use different backup application for Linux, Solaris file systems and Oracle.
The override field should be used only when Zmanda Support instructs you to do so. This field is usually used for custom applications.
The list of backup objects are configured in the backup set can be seen in a table.
If you have skipped the backup of an object, it will appear in yellow color as shown above. If you delete a DLE, it will appear in the list of backup objects with strike through in the list of backup objects.
Once the backup source for a backup set has been defined on the Backup What page, a backup device must be selected on the Backup Where page. If no devices have been configured (as will be the case with a new installation), the ZMC will take you directly to the Admin Devices page to define one or more backup devices. If backup devices are defined, Backup Where allows user to define a backup device for the backup set. You will have to provide backup set specific information for each device depending on the type. Sections below provide more information on how to configure the device for the backup set.
The physical object that stores a backup is referred to in Amanda as a medium. Thus, Amanda organizes all backup data in the following heirarchy (note that slots only apply to a tape changer device):
Regardless of the device type, the ZMC also allows you to define an optional write-cache mechanism called a staging area or holding disk, which stores the backup image on the server's hard disk. Because backups can be written in parallel to the holding disk, backups can be completed in much smaller windows than would be possible if writing directly to the device (even if the device is a virtual tape). The staging area can be configured in the Backup Staging page.
Note that while a backup set can include more than one host as a backup source, there can be only one target device per backup set. If you want to send backups from different host systems to different backup media, you must create multiple backup sets to do so. The Duplicate feature of the Admin Backup sets page is useful for this. Also, once a device has been associated to a backup set it cannot be changed (this would invalidate the restore catalog). To start sending backups from an existing backup set to a new device, duplicate the existing set and bind the resulting backup set to the new device. Note that Backup When settings will have to be manually set to match the old backup set; these settings are not duplicated.
This table shows how the devices are used by different backup sets.
Device Name is the name of device as specifiec in Admin Devices page.
Changer Path and Device Path are device file names for tape changer and device. In case of disk backup, Changer Path appears as /dev/null (i.e, changer entry is not valid). In case of Amazon S3 backup, the S3 access key is shown as Device Path.
Media Per Backup defines the number of media volumes that can be used in a backup run. For Amazon S3, tapes and tape changers, the value can be changed in the Backup Where page.
Comments are the notes that were specified when the backup device was configured with the backup set.
Each Device has advanced options that are required to be modified only under special circumstances or when Zmanda Support team requests you to do so. Please see specific device section about the Advanced options available.
Using hard disk space for a backup provides a number of important benefits:
Disk can be locally attached disk or NAS or SAN device. Disk must accessible from the Amanda server.
Comments
Reserved Percent
Most file systems reserve certain amount of free space. This value is used for free space calculations to provide ZMC warnings when the backup volume is running out of space.
Advanced Options for Disk should not modified unless Zmanda Support Team recommends you to do so.
Comments
Enter a descriptive comment, such as the physical location of the device or any operational notes
Taperscan
The order in which tapes should be searched in the tape changer. Amanda has to load a tape to identify correct tape unless bar code reader is available.
Auto Label Tapes
The 'Auto Label Tapes' radio button allows users to specify whether they want to use the facility of automatic labeling of tapes. The default value is set to No, meaning ZMC expects you to use the Backup Media page to pre-label the tapes you intended to use for backup. Used tapes cannot be labeled automatically. Amanda will label the tape automatically based on the policy that is specified in the drop-down box. The list of policies are shown below
Setting the policy to "Always" is dangerous and is not recommended. If you are using tape changer for multiple backup products including Amanda Enterprise, do not use "Only if Amanda label not found" policy.
Slot range
You can specify the list of slots that can be used for the backup set. Only tapes in these slots will be looked to find tapes for backups. The ranges can be specified as "2-5", "9-13".
Total Tapes Allocated
This value determines the backup retention policy. Amanda will rotate backups among the number of tapes in rotation. You can take tapes out of rotation by archiving it in Backup Media page. Please see Backup When page for more information on this field.
Changer Device
This information is provided for information only and cannot be changed. It can be changed in the Admin Devices page.
Tape Drive Device
The tape drive that should be used by the backup set. Please note that Amanda will use mt command to manage the device. You can specify multiple tape drives for a backup set. This will allow parallel backups to the tape changer. Users have to match the tape device name to drive slot number. If the match is not done correctly, correct tapes may not be loaded and written to.
Ignore Bar Codes (Advanced Option)
You can disable bar code if the tape do not have bar code labels. This is not recommended because it is difficult to keep track of Amanda media labels and tape. Users will have track this on their own if the bar codes are not enabled.
On Linux servers, the output of lsscsi and mtx output is provided as a guide to fill out the values as shown below. On Solaris servers, mtx command output is provided (lsscsi command is not available on Solaris).
Comments
Enter a descriptive comment, such as operational notes, amazon account owner.
Location Restriction
The default is US Standard (Closest Amazon US data center). European customers should use European Union(Amazon Ireland data centers) to reduce latency and backup Windows. Other S3 locations can be US-West(Northern California data center), Asia Pacific (Singapore data center) and other S3 locations. The Storage and Data transfer pricing for each S3 location is different. For details on the storage and data transfer charges associated with different locations, see the Amazon S3 web site at http://aws.amazon.com/s3/.
Backups stored at
The S3 bucket where the backup images will be stored, which was generated when the device was configured in the Admin Devices page.
Secure Communications (Advanced Options)
Enable this to perform secure SSL transfers of data to and from Amazon S3 cloud. Zmanda recommends enabling secure communication.
Speed Per Thread
Users can throttle the network bandwidth for each upload and download thread. The speed limits apply only for the backup set. You can control the backup and restore from the cloud device.
Threads per Upload/Download
Users can control the number of threads used to upload (backup) and download (restore) for the backup set.
Comments
Enter a descriptive comment, such as operational notes, Google account information
Location Restriction
Backups can be stored in US or EU (Europe) in Google Cloud Sotrage
Backups stored at
The bucket where the backup images will be stored. This value cannot be changed.
Durable Reduced Availability Storage
You can use storage that has less availability. This storage is less expensive. This value cannot be changed after it is set. Changing this value does not migrate data in the cloud.
Secure Communications
Enable or Disable secure backup and recovery to and from the cloud.
Bandwidth throttle
You can use all available bandwidth or throttle the upload (backup) or the download (restore) speed. The throttling is done per thread (see below).
Parallel threads
Each cloud object is uploaded or downloaded in separate thread. You can specify how many threads you want to use. Using too many threads might slow the system down.
Device Name
Unique name for the Device that will be used in further configuration.
Comments
Enter a descriptive comment, such as operational notes
Location Restriction
Multiple regions in a OpenStack Cloud
Backups stored at
The bucket where the backup images will be stored. This value cannot be changed.
Secure Communications
Enable or Disable secure backup and recovery to and from the cloud.
Bandwidth throttle (Speed per Thread)
You can use all available bandwidth or throttle the upload (backup) or the download (restore) speed. The throttling is done per thread (see below).
Parallel threads (threads per Upload/Download)
Each cloud object is uploaded or downloaded in separate thread. You can specify how many threads you want to use. Using too many threads might slow the system down.
Regardless of the device type, the ZMC also allows you to define an optional write-cache mechanism called a staging area or holding disk, which stores the backup image on the server's hard disk. Because backups can be written in parallel to the holding disk, backups can be completed in much smaller windows than would be possible if writing directly to the device (even if the device is a virtual tape).
In case of device/media failures (such as an unavailable S3 connection or running out of tapes in the changer), backups are stored in the staging area. The backup images stored in the staging area can be used for recovery and will be moved to the secondary media in next backup run if the media problem is resolved.
The staging area is used for Amanda DLE only if the whole backup image will fit in the staging area. Otherwise, DLE is directly written to the backup media volume without the use of staging area. Zmanda recommends the staging area size should be at least the size of one full backup image of all DLEs in the backup set.
The above table shows staging areas used by each backup set. The Device column whether it is a Disk or Tape or Amazon S3 backup. Flush column indicates if the previous backup images in the staging area are moved to backup media before the current backup run automatically. The location of staging area, disk space used, amount of data used in staging area are also displayed.
Device Name
The name of the ZMC device used by the backup set. This information cannot be modified in this page.
Reserve for Incrementals
Important Note:
Do not attempt to back up the staging area. Use Exclude options if necessary to prevent any backup set from including a staging area for itself or any other backup set.
This pane shows the space used for staging area for this backup set and list of files in the staging area.
Amanda use labels to identify backup media. Labels ensure that the correct backup media is loaded for the backup set, and that no backup is overwritten before the planned cycle is complete. When ZMC finds a labeled piece of media (or media that appears to already contain backup data), it will not write a backup to that tape. When the ZMC finds unlabeled media, it:
When the ZMC finds media that belongs to some other backup set (or media that has been written to by another application), it is not used, and an error message is returned. You can manually "force" labeling of such media by setting the Overwrite Media Option described below to Yes.
ZMC will not overwrite an existing backup tape until it has first written a number of fresh tapes equal to the number of tapes in the planned Backup When page.
ZMC Backup Media page allows users to view backup sets media information, manage media and label media. They are described in the following sections.
This table shows the list of backup sets, the backup schedule, the list of media volumes archived. This table can be used to select a backup set for media management.
The Manage Media table (as shown below) shows the list of media volumes in the backup set and volume labels. It shows when the media was used for backups. You can sort the table using Last Used column. The Archived? column shows the media volume has been archived. Archived volumes are retained forever and are not used for backups (i.e, never overwritten).
L0 in the Media Labels column shows that the media contains level 0 backup of a backup object (DLE). You can find more information about the data in the media volume in ZMC Report pages.
Yellow color on media volume row(s) indicate that this volume(s) is likely to be used in next backup run. This information can be used to put the tapes in the tape changer before the next scheduled backup run. The green color in a row indicates that this volume will be overwritten as part of the media rotation by Amanda. The red color indicates that tape is likely to be overwritten unless new tapes are available. This information is useful in tape changer configurations to make sure fresh tapes are available.
The Manage Media table below shows a tape changer configuration that has multiple labelled empty tapes available for future backup runs (yellow color). The table also shows the tapes labels that include the tape bar codes.
Above picture shows Backup Media page for S3 storage where Amazon S3 is used for archival. The backups are stored with forever retention. Users can use Prune button to manually delete backup images from Amazon S3 storage.
Amanda media must be labelled before it is used for backups. Disk backup media volumes are labelled automatically. If the backup sets uses disk backups, following message will appear. Auto Labelling can be enabled in Backup Where page.
It should be noted auto labelling will work only with new tapes and auto labelling will not work on tapes have any data (not just other Amanda labels).
You can label media volumes (tapes) manually. In a backup set that uses a tape changer, use Scan All Slots to read the labels from the tapes (if any) that are on the slots reserved for the backup set (See Starting/Last Slot number in Backup Where page). Scan all slots before starting manual labelling process.
The list of tapes with barcode is displaed with slot numbers. It also shows the Last Used date when a backup run used the tape. If there is no tape label, the table shows unknown. If there is no tape in the slot, empty slot is displayed as shown for slots 6 to 10 in the table below.
In Advanced Options, you can include tape bar code in the tape labels. Please note that bar code reader must be enabled in Backup Where page. See the next section on how to configure Tape changer bar code information.
Use Overwrite Media option to label tapes that already have data in them. Use caution before overwriting label. The old data cannot be recovered.
To label a tape, enter the label name in the Current/New Label field as shown below and click Save Labels button. The label name must be in <number(s)>-<alphanumeric> format
The label name will be <backup set name>-<text entered>-<bar code>.
Click Load New Media to display a dialog that prompts you to load new media in the selected slots. When you load media and click Done, the ZMC reads the tape labels and refreshes the display.
If the labelling process fails, there is a red cross next to the entry and message appears in the message box as shown below.
Amanda Enterprise edition supports tape changers with bar code readers. To use bar codes in a backup set, it is necessary to initialize the bar code database. Initialization steps must be performed using command line tools. Initialization is required only if tapes were not labeled with bar code enabled or not managed using Zmanda Management Console.
1. Remove the existing bar code database file (if any) on the Amanda server.
$ /etc/amanda/<backup set name>/changer-barcodes
2. Create bar code database file for the backup set on the Amanda server. This process can take a lot of time. The process involves loading of all tapes in the tape changer and bar codes are read.
$ /usr/sbin/amtape <backup set name> update
This operation can be performed only after saving a Backup Where configuration for the backup set, and must be performed as the amandabackup user on the Amanda server.
Unlike most other backup software, ZMC does not require users to lay down detailed rules as to when the backup should be performed. ZMC works through Amanda's backup scheduler which tries to maintain a consistent backup window across all backup runs by controlling the size of the backup image for each backup run.
Amanda also simplifies the configuration of the backup run schedule and specification of backup level. Instead of users pre-specifying either a Full Backup or an Incremental Backup in a particular schedule, ZMC has Full backup and 9 levels of Incremental Backup. However, ZMC does not require Administrators to specify the backup levels for each backup run. It calculates, using an internal algorithm, the levels of each DLE within the backup set for every run on a dynamic basis.
The Tapes In Rotation/Virtual Tapes in rotation option lets you define a backup retention policy how much media is available for rotation (see below) for a single backup cycle, and therefore indirectly set a retention policy. By putting more media in rotation, you are effectively setting a longer retention policy because if more media is available, completed backups will not get overwritten as quickly by subsequent backup runs.
The table shows the list of backup sets and backup schedules. Overall view on the backup schedules help understand how the backup windows are overlapping and how many backups are running at any time.
The backup job for the backup set starts at the time Hours:Minute column and it is run based on schedule in When column. The When column shows two rows: The first row has the days of the week (Sun to Saturday). The second row shows the type of backup schedule is performed on each day.
The backup schedule can be Amanda (A), Full (F) and Incremental (I). Amanda backup schedule means Amanda decides backup level to use. Amanda tries to balance the amount of data backed up on each run and is the recommended schedule.
Backup Start Time
Specifies the time of day when the backup run starts. This time is the same for all days and for all the DLEs in the set.
Backup Cycle
Schedule Type
The Schedule Type can be Every Day, Every Weekday, Custom Weekday, Incremental Weekdays-Full Sunday, and Incremental Weekdays-Full Saturday. Amanda will schedule backup levels in Every Day and Every Weekday schedule on every day of the week and Monday-Friday respectively. You can see force specific backup levels using Increment Weekdays-Full Sunday and Incremental Weekdays-Full Saturday schedule.
Custom Weekday schedule is an advanced option. For each day of the week, you select from No Backup, Full (backup level 0), Incremental (backup level > 0) and Auto (Amanda decides backup level) as shown below.
Custom Days of the Month (shown below) is another advanced option. For each day of the month, you can select Amanda schedule (auto), full backup or incremental (level > 0) or no backup. For days of the month that are not valid for the specific month (such 31st in Feb), the value is ignored.
Virtual Tape/Backup or Tape/Backup
Specifies the maximum amount of media that Amanda will be allowed to consume in a single backup run. This value, coupled with Virtual Tapes/Tapes in Rotation above, effectively sets the data retention policy for the backups.
Amanda scheduling and retention policies are inter-twined with the number of media volumes required (i.e, number of tapes needed for the backup set or amount of disk space required for backups). The following picture shows the values for disk backups.
You can enter the Desired Retention Period in days and click Update to obtain various values. It provides an estimate of number of virtual tapes. It also provides the number of virtual tapes archived so far and total number of virtual tapes for the backup set on the Amanda server.
It also provide comparison with current number of Virtual tapes and current backup schedule.
The information provided in this pane is advisory and is not used by Amanda. It can be used to fill in values for Tape/Virtual Tape in rotation, backup schedule and backup cycle in the Backup When page.
After you have defined what, where and when for the backup set, you can use the Backup How page to define some of the key internal parameters that control how the backup set will run after it has been activated. In most situations, the default values set for these parameters will work well for most backup sets and therefore need not be changed.
Advanced users intending to modify the default values should study the logs and reports of a few past backup runs in light of the discussion that follows.
The parameters should be specified for each backup set. Select the backup set using the table at the bottom of the page by clicking the table row.
Example 1 : A string like "sssS" which represents the priority order for four parallel backups indicates that three dumpers will seek the smallest size hosts while one dumper will seek the biggest size host to backup. Example 2 : A string like 'BbsTt' indicates there are five parallel backup process of which: One backup process(B) is looking for the Biggest Bandwidth occupying backups. Another backup process(b) is looking for the smallest Bandwidth occupying backups. Another backup process(s) is looking for the smallest size backups. Another backup process(T) is looking for biggest Time occupying backups. Another backup process(t) is looking for smallest Time occupying backups.
The port range to use on Amanda server to connect to clients. Amanda will use all the ports in the range that are not bound by another process or not reserved in the /etc/services file. You will have increase the range (or use different range) if you are increasing the value of Server Parallel Backups.
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
A backup set must be activated for its automatically-scheduled backups to execute. backup sets must be activated individually. The Backup Activate page also includes an option for immediate execution of the backup set.
Activate Backup lets you select backup sets to put in production (in other words, begin executing the backups as scheduled). You can also Deactivate an already activated backup set. When a backup set is deactivated, ZMC does not execute backup runs associated with that backup set. You can also trigger an Immediate Backup to be executed at any time. When an Immediate Backup is run, you can observe the progress of the backup run in the Monitor page.
Before a backup set is activated, make sure the backup schedules are configured in the Backup When page, the backup device is configured in the Backup Where page and clients/applications are configured in the Backup What page for the backup set.
You view status of each backup set. The Active column in the above shows state of activation. A green "power" icon indicates the backup set has a schedule configured and installed using the "cron" program. Red icons indicate the backup set has a schedule, but the schedule has not been activated. A grey icon indicates the backup set can not be activated. Backup sets lacking device bindings or having other problems can not be activated.
Activating a backup set causes ZMC to create a crontab entry for the amandabackup user corresponding to the backup set schedule specified in the Backup When page. Some complex ZMC schedules will require multiple crontab entries. ZMC will create and manage these crontab entries automatically, when the backup set is activated using the "Activate" button.
All crontab entries added by ZMC have the option argument --zmcdev. These ZMC-created crontab entries are automatically regenerated by ZMC. To manually edit and alter these crontab entries, first remove the argument --zmcdev. Since ZMC ignores crontab entries lacking --zmcdev, ZMC will not replace the manually edited entry, and ZMC will show the backup set as inactive.
You can Activate/Deactivate/Edit backup sets after selecting multiple backup sets. You can also abort the backup run for a backup set using the Abort button. Aborting a backup stops the backup job and cleans up all the backup processes on the server.
Above image shows the confirmation window for the abort operation.
Once backup sets have been configured and activated, the only operator intervention remaining is to manually load media as required. The Monitor page lets you track the progress of backup sets and fix any problems should they arise.
If no backup is running for the currently selected backup set, the Monitor Backups page will be empty.
The Monitor page is not updated automatically. To see updated details, please click Refresh button.
Use Filter (check boxes) to select specific backup runs to look at.
Use Toggle Details button get information about a backup phase as shown below.
The Monitor Chart as shown above displays the progress of backups that have already completed as well as those that are in progress. The chart is labeled with the time at which the selected backup set run was started. Each Disk List Entry is displayed as a separate row. Each row displays the following information:
To see reports on previously-completed backup runs, go to the Report Timeline page.
A summary of the Backup Status is displayed in left panel.
The Legend Box displays the three legends that are used in the Time Line section of the Monitor chart, and shows what the various colors and patterns used in the timeline mean.
This page describes ZMC Monitor Alerts page.
Alerts are information from Zmanda Network. Usually you will get new product updates and alerts. These messages are also posted in your Zmanda Network home page.
ZMC Monitor Events page provides information about all events on the backup server. This includes backup and restoration.
The table columns are:
Timestamp
Amanda Enterprise log files are stored in /var/log/amanda. ZMC UI log messages are stored in /opt/zmanda/amanda/logs and /opt/zmanda/amanda/apache2/logs directories. The zm-support tool captures these logs and sends them to Zmanda Technical Support to assist troubleshooting.
ZMC works with the Linux logrotate utility to prune active logs. If desired, use crontab to set up log rotation.
Here is an example crontab entry:
0 1 * * 1,5 logrotate /etc/logrotate.d/zmc_logrotate (For 1 AM on Monday and Friday of each week)
Amanda automatically generates backup reports after the backup run is completed (or if it fails for some reason). This backup summary report shows statistics about the backup and summarizes any error, warning, or informational messages that were generated during the backup.
If the Amanda server is configured to send mail, reports can be automatically e-mailed after every backup run. See ZMC Backup How for email notification configuration.
The Summary Report page is divided into two panels.
You can select and navigate reports on each backup run using any of the following:
When you identify a backup that you want to restore from, clicking the timestamp link in the report will take you directly to the Restore What page with the information for that backup already filled in.
All of these methods are described below.
The Summary Report page displays the progress and final status of previous backup runs of a given backup set.
The Report Summary panel on the right has the following navigational aids:
The date browse buttons allow to conveniently move back and forth one day (using < or >) or one week (using << or >>) at a time.
If you select a date with multiple backup runs, timestamp links with status icons are displayed below the browse button. These links allow you to scroll the report display directly to that timestamp.
The timestamp link within the report window shows the time at which the backup run was initiated along with a status icon. Clicking on a Timestamp link go to the Restore What page with the date and time automatically filled in.
The widths for various columns in reports are defined in the amanda.conf file. If the data for a field exceeds the maximum width defined in amanda.conf, the display is truncated. You can change the maximum width. For example, to display longer hostnames, edit the amanda.conf file to define a wider column width for hostnames. If you edit amanda.conf to include the following entry:
columnspec "HostName=0:15"
See the description of the columnspec parameter in the amanda.conf man page for further information.
The Summary Report page will display hostnames of up to 15 characters.
The report is in format described in amreport(8) man page. The Compressed size is determined by (new size/original size * 100). Dump rate is the rate at which backups are transferred from the client to backup server. Tape rate is the rate at which backup images are written to the media.
The Summary Report page opens with the calendar set to the current month. Icons (described by the Legend) identify the status of the backup (Success, Warning, Failure, In Progress) as shown below.
You can either enter the date (mm/dd/yy[yy]) and click Go, or click on any icon in the calendar. When you click Go (or click on a different date), the report shows any summary data (if any is available) for that date.
The calendar control offers a graphical way to choose a report date. Dates that include backup data have a status icon; click the icon to display the given report (you cannot select dates with no backups to report on). When you click a report icon, it changes color to show it has been visited.
The example above shows April 8 as having been selected and visited.
Note that the calendar icons indicate when backup runs have occurred, which is not necessarily the same as what backups are currently available to Amanda for verification/restore. For example, ff you have Dropped the media from the Backup Media page, clicking the calendar icon will result in the following message:
No complete backup available on timestamp timestamp_value. Error in Verifying:
This message can also occur after the backup for a particular date has been overwritten because the backup cycle/retention policy (or options selected on the Backup Media page) allow that media to be recycled.
The Report Timeline tab provides a timeline view of the backup objects/DLEs in the backup set. Note that the most recently completed backup run is not listed here; for the status of the last completed run, see the Monitor tab.
The Report Timeline page displays the backup level and progress of previous backup runs, organized by backup object/DLE. The display uses the same legends that the Monitor page would use for backups currently in progress.
The Report Timeline panel includes a Calender turner control. Click either of the two inner single arrows to move backwards and forwards, one day at a time.
Click either of the outer two arrows to move back and forth by a week (seven days) at a time.
The Report Timeline page opens with the current month selected for display. Use the Calendar controls to change as desired.
The top portion consists of a Backup Date input box along with a Go button. Clicking Go displays the given date in the Calandar. The input box accepts dates in both mm/dd/yyyy and mm/dd/yy formats.
The Calendar control at the bottom of the panel works the same as it does for the Summary Report.
The Legend is same as the Monitor Backups page.
The Report Media tab provides a media-based view of completed backup runs on a particular date for a particular backup set.
Note that multiple backup objects/DLEs can be backed up to a single media volume. To backup up different backup objects to separate pieces of media, assign the backup objects to separate backup sets. If the objects are small in size, a number of them could fit on a single piece of media.
The Report Media page presents a "backup media-centric" view of a past backup run of a backup set. It is especially useful for examining media utilization over time.
The percentage utilization reported for each volume is based on the actual data stored / estimated length provided in the Backup Where page. The length provided (denominator) is accurate for disk backups. In the case of tape
backups, data is written till EOT (end of tape), thus utilization can exceed 100%. In the case of S3 backups, this value not useful.
The Media Chart panel has the a Calender Turner Pressing either of the two inner single arrows allows the users to change reports one day at a time. When either of the outer two arrows signs are pressed, the Calender changes by a week (seven days) at a time.
The Chart also has three controls as shown below: Various dates are spread across the top. Each date carries with it the same legend that is shown in the Summary report. A drop down box below it allows users to choose different Backup runs on the same day, if they exist. On changing the selection from the drop down box changes the Legend and Text summary details displayed below the date. Finally, below the Legend is a short Text summary. The number after the Backup Set name (like -004 or -001) is that of the backup run (of multiple runs, if any) on that day on the same backup set.
By default the Report Media page opens to the current month.
These work exactly the same as for the Summary Reports page.
The Legend differentiates between two media i.e. Tape and Disk. It also differentiates between Full and partial utilization of the media.
The Report Data tab reports on backup runs for a week of a particular backup set.
The Report Data page is divided into two sections:
One panel contains a date/calendar controls and a legend that explains the report status icons that is described in the next section.
The Data Chart list results for each backup object/DLE, using iconsthat show the type of backup (full or incremental) and whether t any errors or warnings were returned. The browse buttons at the top lets you scroll back and forth in time.
The Report Data page provides a Backup object-by-backup level view of backup runs for a week of a particular backup set. The graphical display also incorporates the backup status in its display.
The Right hand Report Data panel has the Calender Turner (see above). Pressing either of the two inner single arrows allows the users to change reports one day at a time. When either of the outer two arrows signs are pressed, the Calender changes by a week (seven days) at a time.
The Chart has additional controls shown below: Various dates are spread across the top. Each date carries with it the same legend that is shown in the Summary report. A drop down box below it allows users to choose different Backup runs on the same day, if they exist.
All the DLEs that exist in the Backup Set are displayed in the two left most columns labeled 'Hostname and ' Directory' respectively. The seven dates are displayed in the next seven columns with the selected date shown in the right most position. In the cell that is formed by the inter-section of DLE and date, one of the nine legends is displayed. The display allows users to see the historical trend of a Backup Set broken into its DLEs
The top portion consists of a Backup Date input box along with a Go button. Clicking Go displays the given date in the Calandar. The input box accepts dates in both mm/dd/yyyy and mm/dd/yy formats.
The Calendar control at the bottom of the panel works the same as it does for the Summary Report.
ZMC automatically decides what level of Backup (full or incremental) is appropriate for a backup run. Full backups are labeled level 0 and incremental levels are labeled 1 or 2 and higher levels. When ZMC runs the backup, users are not aware of the level at which it has run. NB: While, immediate backups can be enforced from the Backup Activation page, that does not mean that Immediate Backups are Full backups! ZMC takes its own decision as to the appropriate level while running the Immediate Backup. Level 0 is shown by a long bar. Level 1 is shown by bar which is about half the size of full bar. Level 2 or above are shown by a bar which is one fourth the size of full bar. These lengths have no intrinsic meanings. Their lengths are just to differentiate them from each other.
ZMC labels each DLE backup as having completed as Normal, or as with Warning or with Errors. Normal status is indicated by a green color. Warnings are indicated by a yellow color. Errors are indicated by a red color. The combination of level and status gives rise to nine legends shown in the Fig. 3.
The various Report sub-tabs display backup run data from many perspectives. The Report Custom tab lets you create custom reports for a backup set and save them.
The Custom Report page display the results of backup set runs. In addition to the standard reports, you can configure and save your own custom report configurations. The results can be saved as a Comma Separated Value (CSV) file for use in other applications and to generate graphical reports.
There are three standard reports; these cannot be edited or deleted.
Note also that you can mix Client and Media report options in the same report. Choose the appropriate tab from the Customize Report pane to select which type of report you would like to create.
To create your own report, check the desired parameters from the custom reports panel, enter a name in the Report Name field and click Save Report. The saved user-defined reports will then appear in the drop down box.
Custom reports can be overwritten. A confirmation message box will be displayed when a report is being overwritten.
The Report Results displays the results of the report defined in the left panel in a table. Data can be sorted in ascending or descending order by clicking on the column headers. You can save the report as a CSV file by clicking the Save as CSV button in the lower right. You can then use the CSV file in any application (spreadsheet, wordprocessor, etc.) to generate print and PDF output.
If there are no statistics available for a given parameter because of a backup failure, "na" (not applicable) is displayed in the first column of the row. These "blank" lines are not included in CSV file output.
The widths for various columns in reports are defined in the amanda.conf file. If the data for a field exceeds the maximum width defined in amanda.conf, the display is truncated. You can change the maximum width. For example, to display longer hostnames, edit the amanda.conf file to define a wider column width for hostnames. If you edit amanda.conf to include the following entry:
columnspec "HostName=0:15"
See the description of the columnspec parameter in the amanda.conf man page for further information.
The Summary Report page will display hostnames of up to 15 characters.
Checking Data Integrity of the backup media volumes ensures that the backup data has not been modified after being sent to the backup media.
During various transfers from one media to another, there is a remote possibility that such a change has happened and restoring from such altered data may not give the desired result.
The Report Data Integrity page reads and verifies that backed up data image on the media has not been modified. In the case of application clients (such as Windows Oracle), the check does not proceed beyond determining whether the tape is readable. In this case, the message “Could not determine validation for dumper“ is displayed and logged. This message can be safely ignored.
If you verify by date, all the tapes associated with each backup run on the selected date are verified (in most cases there will be only one run per day). If you verify by label, only a particular tape is verified. The correct tape(s) must be loaded in the tape device. Verification of each backup run begins by listing the tape(s) required for that run, and then prompting you to load each tape as necessary until all have been checked.
The Data Integrity page lets you check out that the already-written media (selected by either date or label) has not been altered after the backup. Run the Data Integrity before restoring a backup image.
The default method of invoking a Data Integrity report is by Tape label.
From the Please select verification method drop down box the method of verification can be changed to By Date. Selecting by date displays the appropriate interface controls.
The Select by Tape Label dialog is displayed in the left panel by default. It allows you to select an Amanda tape by volume from the dropdown menu. Click the Verify button to start the data integrity check of the selected tape.
On choosing 'By Date' option the GUI opens to a page with the Calender control in left hand panel, with the current month selected for display. Use the calendar controls to change as desired.
The top portion consists of a Backup Date input box along with a Go button. Clicking Go displays the given date in the Calandar. The input box accepts dates in both mm/dd/yyyy and mm/dd/yy formats.
The Calendar control at the bottom of the panel works the same as it does for the Summary Report. Click the Verify button to start the data integrity check for all the tapes used by the selected backup date.
The right hand panel displays the status of the verification process. You can Clear Output of the message panel by clicking the link.
It is possible to automate the media verification procedure using amcheckdump command. Please contact Zmanda Support team if you need more information.
This page allows to you manage ZMC users. You can create, edit and delete ZMC users. ZMC users are different from the operating system/network users.
Each user should have a valid email address. This address is used to recover lost ZMC passwords.
There are four user roles as shown above
All ZMC users with Administrator role should be associated with Zmanda Network. You can specify the same Zmanda Network authentication information for all users. When the information is entered, it is validated with Zmanda network. Internet access is required for this process.
The list of ZMC users are shown in a table. Users role and their email address are also displayed. Users with Administrator role can use this table to delete ZMC users.
The Backup Sets tab allows you to create, edit, duplicate, and delete backup sets. All Amanda configuration is organized as backup sets.
Report Display Unit
The unit used in Amanda reports for the backup set. Please note changing the value will not impact reports of the already completed backup runs.
User is warned if there are no storage device or backup clients or backup schedule is associated with the backup set as shown below. These operations must be completed before the backup set can be activated.
The list of backup sets are displayed in the table. The state of the backup sets: active, inactive and not configured as displayed. The health status of the backup set are also displayed. If there are errors, the backup set cannot be used.
Deletion of the backup set removes the given backup set and all the settings associated with it from the ZMC. After deletion, the ZMC will have no record of backups completed by the backup set, but the backups themselves are retained regardless of storage media (staging area, tape, S3, etc.) unless manually deleted. To retrieve backup data from the staging area after the backup set (and hence its catalog) has been deleted, please see this Zmanda Knowledgebase article.
When you click the Delete button, the ZMC prompts for confirmation. Proceed with caution as there is no way to undo the deletion. If you attempt to delete a backup set that is active (i.e., selected from the Backup Set dropdown at the top right of the page), the ZMC will take you to the Create a New Backup Set page after confirmation, otherwise you are returned to the Admin Backup Sets page.
You can also abort the backup run for a backup set using the Abort button. Aborting a backup stops the backup job and cleans up all the backup processes on the Amanda server. Following confirmation window is displayed to confirm abort operation.
The Admin Devices page lets you select and configure target devices for backup. Once configured, a device is then bound to the current backup set.
When you click on a device type (Attached storage, Cloud Storage or Tape Storage) and click Add, the options for that device are displayed in the top pane as shown above. Devices already configured are listed in the bottom pane along with buttons that allow you to Edit, Delete, and Use the device as shown below. When there are more items that can be listed one page, page navigation links at the bottom of the table allow you to move between pages.
NDMP Changer Device can be used only with NDMP application. For more information, please see NDMP appliance application agent configuration.
All devices must have a Name; a descriptive Comment is optional. Device-specific options are described in the subsections that follow.
You can select the specific device to edit from the backup devices table. Clicking on List button will list the buckets/containers and objects in case of cloud device. All files (even non-Amanda objects) are listed. Following figure shows an example of Openstack cloud device containers and objects.
Root Path The directory to store backup images, specified as an absolute path.
When using vtapes, you must first decide whether to oversubscribe before you can determine how much disk space to allocate. If oversubscribing, you should still determine by how much you plan to oversubscribe and set up processes on the host system to alert you when oversubscription threatens to prevent backups from occuring.
If you set the number of vtapes in rotation to match the number of vtape slots on the Backup Where page (i.e. normal, recommended configuration), then to avoid oversubscription issues you must allocate disk space equal to the number of vtapes times the size of each vtape. Changes to either of these two parameters require adjusting the amount of disk space allocated for use by ZMC's backup set outside of Amanda, since currently the Amanda does not reserve space before usage.
Reserved Percent Percentage of the file system that should be free. This value depends on the file system in use. All file systems have reserve space. This value is used for ZMC disk space warning messages.
Output Buffer and Maximum Total DLEs need not be adjusted unless Zmanda support team recommends changes in these value for the backup set configuration.
Setting up an Amazon S3 storage device requires that you sign up for an Amazon S3 account and obtain the Access Key ID and Secret Key as described in Setting up an Amazon S3 Account for Use with Amanda. If the S3 account is already set up, you can obtain the Key ID and Secret Key by logging in here (Amazon username and password required), from where you can cut and paste the Key ID/Secret Key.
Storage Option
It can be either standard (Amazon S3 will complete redundancy and more availability) or Reduced Redundancy (Amazon S3 with reduced redundancy and less expensive storage).
Advanced Options
You can disable secure communications to the cloud. This will increase performance at the cost of security. This is recommended only when you are not backing up sensitive data and backing up from Amazon EC2 to Amazon S3.
You can also enable AES 256bit Cloud Encryption provided by Amazon. The backup data is stored at rest in S3 encrypted. The keys are managed by Amazon. Please note that you can enable this option even if you are using Amanda client or server encryption with your private keys.
Other options should be changed only if they are recommended by Zmanda Support team.
ZMC attempts to discover tape changer and tape drive device names automatically. The devices must be readable and writeable by amandabackup user.
Tape Size
Bar Code Reader
All other advanced options should be used when advised by Zmanda Support Team.
You will have to set up Google Account and sign up for Google Cloud Storage. You will have get access and secret keys from Google APIs console under Legacy Access from Google Cloud Storage tab.
Amanda Enterprise talks to Open Stack Swift cloud using Keystone authentication mechanism and without using S3 compatibility layer.
Identity/Auth Service
The IP address and port number used by Keystone authentication service.
Tenant Name
Tenant name or the project name that can be used to isolate resources for a group/project.
Access Key
Name of the user in the tenant or the access key.
Secret Key
Password of the user or the secret key.
This page allows users to manage ZMC preferences and as well as execute Amanda and some system command on the Amanda server.
Above panel shows the list of ZMC preferences that are available. These preferences are common to all ZMC users. Please contact Zmanda Support Team before making changes to these parameters. Some interesting preferences are
Maximum Login Timeout Allowed
The timeout after which an idle ZMC session times out. User will have to login again. You can resume the ZMC session by selecting the check box.
License Expiration Warning
The Admin Licenses page provides warnings about expiring licenses. Many features in Amanda Enterprise are licensed. When license expires, the backups will not be performed. It is important to take notice of warning and contact Zmanda Support about license renewal.
Usually Zmanda Support team will also contact you about the license renewal.
Critical Space Threshold
Warning Space threshold
Space Check Frequency
It is important to have sufficient space available in certain directories such as /tmp, /opt for ZMC to function properly. These three preferences control the messages regarding lack of disk space.
These are preferences specific to the ZMC user.
User Login Timeout specifies the time after which the idle user session will be timed out. User will have to log in again.
The Admin Licenses page provides a view for the list of Amanda feature licenses in the license file /etc/zmanda/zmanda_license. The Amanda licenses are counted based on the number of hosts protected. Amanda server is also a client and uses up a license.
The licensed feaure summary shows the number of licenses available for each feature (Licensed), number of licenses that have been used (Used), number of license remaining(Remaining), number of licenses close to expiring (Expiring) and numer of licenses that have expired (Expired).
When the number of licenses remaining is less than 2, the number appears in red color. Expiring licenses warning can be controlled using License Warning preference in Admin Preferences page.
When feature licenses are used up, it is not possible to add any more DLEs of that type. If Amanda server license (Unix file system) expires, all backups will not performed. So, it is important to renew licenses before the expiration date.
Zmanda team will contact you via email before the license expiration date.
Licenses Used table shows how the licenses are used by various hosts and backup sets configured on the Amanda server.
ZMC Restore What page is the first step in restoring files using the Zmanda Management Console. This section covers generic file system restores; for details on application-specific restores, see the appropriate section of the Zmanda Application Agents for Amanda Enterprise Edition User Guide.
The Restore What page specifies what to restore. It allows you to choose a single file or a single directory or all directories/files under a single directory.
Selecting what to restore is a two step process:
Select the directories/files to be restored by clicking left and right arrows. Selected entries should be in the right panel.
Explore process can take time and the time taken depends on the number of entries in the Amanda index for the Host Name and the Directory.
The number next to directory (in the above figure - (3)) shows the number of files in the explore window pane.
Restore All Option.
Use this button to restore complete backup image. This is short-cut to avoid the exploring the backup images for quick restores. This is useful in case of complete restoration of the application or the file system. For some applications, only Restore All is supported.
Note that although the ZMC allows multiple users to access the Restore pages from the same Amanda server, the ZMC server can only explore one backup object/DLE at a time. A warning message is displayed if multiple users are accessing the restore pages for the same backup set.
The Restore Where page specifies the destination directory for recovered files. Before attempting a restore, you may want to review the Requirements for Restore Clients section of the pre-installation checklist.
The Restore Where defines where the data is to be restored. It also lets you control how the file restore operation proceeds. For example, you can choose whether to permit overwriting of existing files.
When you are restoring to Amanda Linux, Solaris or Mac OS X client, configuration is required on the client. See next section. For Windows client, no configuration is required other than client software must be installed on the machine being restored to.
index_server "localhost" # your amindexd server tape_server "localhost" # your amidxtaped server
Change "localhost" to match to the hostname of the Amanda backup server.
DLE/Object Type and Source Host Type are non-editable fields and they are provided for information to fill other fields.
If you are restoring Windows backups to Linux/Unix/Mac/Solaris host, the data is restored as zip file which can be copied to Windows machine and extracted using pkzip or winzip tools that support ZIP64 format. Example message that appears in ZMC:
Linux/Unix/Mac/Solaris client backups cannot be restored to Windows.
Above Restore Where page shows how to restore alternate vCenter/ESX server with different Virtual Machine name.
Conflict Resolution is displayed only for Windows, Linux, Solaris and Mac OS X file systems.
The radio buttons in the above panel lets you set how to handle filename conflicts in the destination directory (select one):
Express restores allows users to exclude file names or files/directories that match the exclude pattern. Multiple files or patterns (filename globbing syntax) can be specified.
The Run Restore page is the last step in the recovery process. In the Run Restore page review the restore options you have specified, start the actual restore process, and monitor its progress. Only one restore process can be performed for a backup set in ZMC.
Restore From, Restore To, Tapes needed panels (as shown below) provide information about the restore job. Make sure the required tapes are in the tape changer (in the slots reserved for the backup set) if the restoration is from a tape.
Click the Restore button to start the restore process.
The Restore Summary panel shows the restore process progress. The backup image is read from the media and it is transferred to the Destination Host. The relevant files/directories are extracted or the applications are restored on the Destination Host. If tapes are required, you will be prompted in this window.
If this restore is being performed using ssh, you will requested for the password.
This section discusses some browser issues you should be aware of when using the Zmanda Management Console.
Most browsers have an option to "remember" what is entered in forms. In Firefox, this is set in the Preferences->Privacy tab. Turning this option on can result in fields being pre-filled with incorrect parameters, as the browser merely remembers the ZMC page and knows nothing about Backup Sets and other ZMC input.
When refreshing a page after a POST operation, most browsers display a dialog asking if you want to repeat the operation. Avoid reposting form data when using ZMC. Re-posting form data can result in undesired consequences.