Quick start (old)
Installation
Amanda can be installed from pre-built RPMs or built from source tree. Please see installation chapter for information on the installation procedure.
Backup server configuration
Create a backup user on the Server
Amanda runs as a normal user, but must be in the same group that has read access to the raw disk devices. Frequent choises are: amanda, backup, operator. Do not use root to run the Amanda suite. If the user does not exist, create one:
# useradd -u amanda -g disk -d /home/amanda -s /bin/bash -c ...
Invent a name for the configuration
A configuration in Amanda has a name. Most Amanda commands need that configuration name as first argument. You may have many configurations. Frequent names are: "daily" for daily backups, "archive" for offsite stored achive tapes, "test" for your test environment. Some distributions ship Amanda with a configuration named "DailySet1".
Find out where the CONFIG_DIR is:
$ amadmin x version | grep CONFIG_DIR CONFIG_DIR=/usr/local/etc/amanda
and create a directory with the choosen configuration name inside it:
$ cd /usr/local/etc/amanda $ mkdir daily
Modify amanda.conf
Copy the example amanda.conf into that directory. Edit this file to be correct for your site, consulting the amanda.conf(5) man page if necessary. Note the values you choose for the next parameters in amanda.conf:
amanda.conf:
logdir "/usr/local/var/amanda/confname/log" # log directory infofile "/usr/local/var/amanda/confname/curinfo" # database filename indexdir "/usr/local/var/amanda/confname/index" # index directory tapelist "/usr/local/var/amanda/confname/tapelist" # list of used tapes
and create the directories or files, making sure the directories and files are owned by the amanda user:
# mkdir -p /usr/local/var/amanda # chown -R amanda:disk /usr/local/var/amanda # su - amanda $ mkdir -p /usr/local/var/amanda/confname/log $ mkdir -p /usr/local/var/amanda/confname/curinfo $ mkdir -p /usr/local/var/amanda/confname/index $ touch /usr/local/var/amanda/confname/tapelist
Note the holdingdisk(s) you specified in the amanda.conf file:
amanda.conf:
holdingdisk hd1 {
directory "/space/amandahold/confname"
...
}
And create them:
# mkdir -p /space/amandahold/confname # chown -R amanda:disk /space/amandahold
Entries in /etc/services on the Server
Put the Amanda services into your /etc/services file. Add entries like:
/etc/services:
amanda 10080/udp amandaidx 10082/tcp amidxtape 10083/tcp
You may choose a different port number if you like, but it must match that in the services file on the client hosts too. If you are running NIS (aka YP), you have to enter the Amanda service into your NIS services database. Consult your NIS documentation for details. You may use the `patch-system' script, from client-src, in order to modify this file. Run it with a `-h' argument for usage.
Configure (x)inetd on Server
Find out if you server uses inetd, xinetd, or Dan Bernstein's daemontools.
- Strictly speaking, the serverside configuration of amanda does not include the "amandad" entries below, but because the amanda-server is usually a client for itself (i.e. you make backups of the amanda server too), I added the "amandad" entries already.
inetd on Server
If the server uses inetd, then add these lines to the inetd.conf on the tape server host:
/etc/inetd.conf:
amanda dgram udp wait $USER $AMANDAD_PATH/amandad amandad amandaidx stream tcp nowait $USER $AMINDEXD_PATH/amindexd amindexd amidxtape stream tcp nowait $USER $AMIDXTAPED_PATH/amidxtaped amidxtaped
where $AMANDAD_PATH, $AMINDEXD_PATH and $AMIDXTAPED_PATH are the complete paths to where the amandad, amindexd and amidxtaped executables are located (usually the libexec directory), and $USER is the Amanda user.
The first entry is not strictly needed when the server itself is not configured as a client.
You may use the `patch-system' script, from client-src, in order to modify this file. Run it with a `-h' argument for usage.
Make inetd reread its configuration file:
# kill -1 <pid-of-inetd>
On older systems you may have to kill it completely and restart it.
xinetd on Server
If the tape server uses xinetd, then you have to add the following file to the xinetd-configuration (usually :/etc/xinetd.d) and edit the paths:
/etc/xinetd.d/amanda:
service amanda
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = $USER
group = $GROUP
groups = yes
server = $AMANDAD_PATH/amandad
}
service amandaidx
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = $USER
group = $GROUP
groups = yes
server = $AMINDEXD_PATH/amindexd
}
service amidxtape
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = $USER
group = $GROUP
groups = yes
server = $AMIDXTAPED_PATH/amidxtaped
}
where $AMANDAD_PATH, $AMINDEXD_PATH and $AMIDXTAPED_PATH are the complete paths to where the amandad, amindexd and amidxtaped executables are located (usually the libexec directory), $USER is the Amanda user, and $GROUP is the group name the Amanda user is in.
Some administrators like to split up the above entries in 3 files instead of one.
Make xinetd reread its configuration file:
# kill -HUP <pid-of-xinetd>
daemontools on Server
If your tape server uses Dan Bernstein's daemontools (http://cr.yp.to/daemontools.html) instead of (x)inetd, you have to create amandaidx and amidxtape services by hand.
mkdir -p $prefix/etc/amanda/supervise/amanda mkdir -p $prefix/etc/amanda/supervise/amandaidx mkdir -p $prefix/etc/amanda/supervise/amidxtape
Create service startup files and make them executable:
/etc/amanda/supervise/amandaidx/run:
#!/bin/sh exec /usr/local/bin/setuidgid amanda \ /usr/local/bin/tcpserver -DHRl0 0 10082 \ /usr/local/libexec/amindexd >/dev/null 2>/dev/null
/etc/amanda/supervise/amidxtape/run:
#!/bin/sh exec /usr/local/bin/setuidgid amanda \ /usr/local/bin/tcpserver -DHRl0 0 10083 \ /usr/local/libexec/amidxtaped >/dev/null 2>/dev/null
Link service directories into your svscan directory:
# cd /service # ln -s $prefix/etc/amanda/supervise/amandaidx . # ln -s $prefix/etc/amanda/supervise/amidxtape .
svscan should detect and start your new services automatically.
Create the disklist file
In the same directory as the amanda.conf file is the disklist file. Begin with a few entries while you are testing.
disklist:
client1.yourdomain.com /some/dir comp-user-tar client2.yourdomain.com /var comp-user-tar
Note that you might want to temporarily set the option "no-record" in all your dumptypes when first installing Amanda if you'd like to run tests of Amanda in parallel with your existing dump scheme. Amanda will then run but will not interfere with your current dumpdates. However, you don't want to run with "no-record" under normal operations.
Crontab entries
Schedule the amcheck and amdump command by use of crontab: As user amanda execute "crontab -e". Here is a sample:
0 16 * * 1-5 /usr/local/sbin/amcheck -m confname 45 0 * * 2-6 /usr/local/sbin/amdump confname
Note: some OS'es have a shared crontab for all users, and may require a userid on each cron line. See your cron(8) for details.
With these cron lines, Amanda will check that the correct tape is in the drive every weekday afternoon at 4pm (if it isn't, all the operators will get mail). At 12:45am that night the dumps will be run.
It may be wise to add these crontab entries later, when all the tests succeeded.
The File .amandahosts on the Server
Create a file named ".amandahosts" in the home directory of the dumpuser. The syntax is similar as a .rhosts file. Such a file should exist on each client containing a line to allow the server access to the client (see Backup Client configuration). On the server additional entries are needed for each client in the disklist file that wants to use amrecover (amrecover needs to be run as root).
# su - amanda $ cat .amandahosts amandahost.yourdomain.com amanda amandahost.yourdomain.com root client1.yourdomain.com root client2.yourdomain.com root
The first line in the .amandahosts file above is for the Amanda client running on the server itself. The next lines allow the user root on each client computer to access the Amanda tape server and Amanda index server on this host.
When compiled with the configure option --without-amandahosts, use the file .rhosts and/or /etc/hosts.equiv instead.
Backup Client configuration
Each client in the disklist file of the server needs to be configured with the client part of Amanda.
Note: The server itself is usually also a client; this section applies to the server too.
Create a backup user on the Client
The dump user on the client does not have to be same name, uid or gid as the server. It must be in the same group that has read access to the raw disk devices. A real login shell is not really needed.
If the user does not exist, create one:
# useradd -u amanda -g disk -d /home/amanda -s /bin/false -c ...
Do not use root to run the amanda suite.
The File .amandahosts on the Client
Create a file named ".amandahosts" in the home directory of the dumpuser on the client. The syntax is similar as a .rhosts file. Fill it with the hostname of the Amanda server and the Amanda user on the server:
amandahost.yourdom.com amanda
This entry allows user amanda on host amandahost.yourdom.com to initiate a backup on this client.
When compiled with the configure option --without-amandahosts, use the file .rhosts and/or /etc/hosts.equiv instead.
The Files /etc/amandates and /etc/dumpdates
Create an empty file /etc/amandates and make it owned by the dumpuser.
# touch /etc/amandates # chown amanda /etc/amandates
Make the file /etc/dumpdates writeable by user the dumpuser:
# chmod 664 /etc/dumpdates # chgrp disk /etc/dumpdates
where "disk" is the group that amanda is in, and the group that has read access to the raw disk devices (see "ls -l /dev/hda1" or whatever your disks are).
Entries in /etc/services on the Client
Put the Amanda service into your /etc/services file:
/etc/services:
amanda 10080/udp
You may choose a different port number if you like, but it must match that in the services file on the tape server host too.
If you are running NIS (aka YP), you have to enter the AMANDA service into your NIS services database. Consult your NIS documentation for details.
You may use the `patch-system' script, from client-src, in order to modify this file. Run it with a `-h' argument for usage.
Configure (x)inetd on the Client
Find out if the host uses inetd, xinetd, or Dan Bernstein's daemontools.
inetd on Client
If the Amanda client uses inetd, put the Amanda client service into inetd's config file. This file is usually found in /etc/inetd.conf, but on older systems it is /etc/servers. The format is different on different OSes, so you must consult the inetd man page for your site.
/etc/inetd.conf:
amanda dgram udp wait $USER $AMANDAD_PATH/amandad amandad
where $AMANDAD_PATH is the complete path to where the amandad executable is located (usually the libexec directory), and $USER is the Amanda user.
You may use the `patch-system' script, from client-src, in order to modify this file. Run it with a `-h' argument for usage.
Make inetd reread its configuration file:
# kill -1 <pid-of-inetd>
On older systems you may have to kill it completely and restart it.
xinetd on Client
If the Amanda client uses xinetd, you have to add the following file to the xinetd-configuration (usually /etc/xinetd.d) and edit it to reflect your settings and paths:
/etc/xinetd.d/amanda:
service amanda
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = $USER
group = $GROUP
groups = yes
server = $AMANDAD_PATH/amandad
}
where $AMANDAD_PATH is the complete path to where the amandad executables is located (usually the libexec directory), $USER is the Amanda user, and $GROUP is the group name the Amanda user is in.
Make xinetd reread its configuration file:
# kill -HUP <pid-of-xinetd>
daemontools on Client
If the Amanda client uses Dan Bernstein's daemontools (http://cr.yp.to/daemontools.html) instead of (x)inetd, you have to create the Amanda service by hand. You will need also an UDP super-server (netcat in this example).
Create service directory:
# mkdir -p /etc/amanda/supervise/amanda
Create service startup file and make it executable:
/etc/amanda/supervise/amanda/run:
#!/bin/sh exec /usr/local/bin/setuidgid amanda \ /usr/bin/netcat -l -u -p 10080 -q 0 \ -e /usr/local/libexec/amandad >/dev/null 2>/dev/null
The netcat-binary used in this run-file might also be called /usr/bin/nc on your system, depending on the OS-distribution you use. Refer to http://netcat.sourceforge.net for details of netcat.
Link service directory into your svscan directory:
# cd /service # ln -s /etc/amanda/supervise/amanda
svscan should detect and start your new services automatically.
Create the listed_incr_dir for Gnutar
If the dumptype for this client uses Gnutar, then you have to create a directory for it. Find out the compiled-in value, and create the directory, making sure the dumpuser can write into it:
# amadmin x version | grep listed_incr_dir listed_incr_dir=/usr/local/var/amanda/gnutar-lists # mkdir -p /usr/local/var/amanda/gnutar-lists # chown -R amanda:disk /usr/local/var/amanda
Special Requirements
- If you intend to back up xfs filesystems on hosts running IRIX, you must create the directory /var/xfsdump/inventory, otherwise xfsdump will not work.
Running the Configuration
Label a Tape
Take a fresh tape, make sure the tapedrive has the correct settings, like compression off and variable blocksize, and label it using the amlabel command:
# su - amanda $ mt -t /dev/nst0 compression 0 $ mt -t /dev/nst0 setblk 0 $ amlabel daily Daily-01
While testing a setup, using a "virtual tape" (a tape emulated on disk) is very handy. Use this entry in amanda.conf:
amanda.conf:
tapedev "file:/space/amanda-vtapes/tape"
And create the virtual tape as a directory (including a "data" directory inside it):
$ mkdir -p /space/amanda-vtapes/tape/data
And use ammt to manipulate the virtual tape:
$ ammt -t file:/space/amanda-vtapes/tape rewind $ amlabel test Test-01
You can even emulate a virtual tape changer having many tapes. See File driver/Disk backups.
Testing the Configuration
Log in on the Amanda server, and run amcheck as the dumpuser:
# su - amanda $ amcheck daily
Solve all problems it finds. You don't need to solve the "NOTE" level messages.
When debugging the setup, the debug files created by the different Amanda programs can be a great help. Find the Amanda debug directory that was compiled in:
$ amadmin x version | grep DBG AMANDA_DBGDIR=/tmp/amanda
The client programs create a debug file in this directory. The filename starts with the program name, followed by a date-time stamp.
The server writes a log in a file named "amdump" in ~dumpuser/config. When finished the file is named "amdump.1"; the previous file is then found with name "amdump.2", etc.
Run a Backup
Rerun amcheck several times, until all the errors amcheck finds are solved. Now it is time to make a real backup with amdump(8):
$ amdump daily
This command takes as long as the backup runs. Do not enter large disks in the disklist at this time.
When finished, you should receive a mail with the backup report.
When you want to reuse the already labeled tape for another test run, make Amanda forget about it using the amrmtape(8) command, and amlabel it again with the same label:
$ amrmtape daily Daily-01 $ amlabel -f daily Daily-01
Frequent Errors
- Directories/files created during the configuration are not writeable by the dump user.
- Running some programs as root, instead of the dumpuser, creates some files owned by root instead of the dumpuser. When later running as the dumpuser, there could be permission problems with these files. Do not test or run Amanda suite programs as root (except amrecover, which must be run as root).
- Specifying the wrong tapedevice: Amanda needs the no-rewind version of the tape device in your amanda.conf file.
- Forgetting to set "disable = no" in the amanda services of xinetd.
- Forgetting to have (x)inetd reread the config after adding the entries. Run "netstat -a" to verify the ports it should be listening.
- Firewall issues on/between client and server.
- Sendmail/postfix/... configuration on the mail server refusing mail from your Amanda server.
Start Production Run
- Remove the "no-record" option from the dumptype, if you added this for testing purposes.
- Add more hosts and disks to the disklist
- When you add them all at once, be prepared for loud complaints in the report from Amanda about not being able to get all the data on one tape. But after a few runs, Amanda should settle down.
- Alternatively, add hosts and disks a few at a time to avoid an indigestion.
- Label more tapes. Labeling them one each day a new tape is needed is fine too. After "tapecycle" runs, Amanda will ask the first, oldest tape again.
- Verify/activate the crontab entries on the server.
- Insert the next tape for tonight, and let the amcheck in crontab verify the configuration.
- Verify the backup report you receive the next day carefully.
- Study more of the Amanda programs, and tune the amanda.conf to your needs.
- Subscribe to the Amanda-user mailing list.