Quick start (old): Difference between revisions
m (Copy editing and formatting) |
|||
Line 262: | Line 262: | ||
===Create file .amandahosts on the server=== | ===Create file .amandahosts on the server=== | ||
Create a file named | Create a file named '''.amandahosts''' in the home directory of the Amanda user. The syntax is similar to that of the '''.rhosts''' file. An '''.amandahosts''' file is required on each client containing a line to allow the server access to the client (see [[Quick start#Backup client configuration|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). | 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 - amandabackup | # '''su - amandabackup''' | ||
$ cat .amandahosts | $ '''cat .amandahosts''' | ||
amandahost.yourdomain.com amandabackup | amandahost.yourdomain.com amandabackup | ||
amandahost.yourdomain.com root | amandahost.yourdomain.com root | ||
Line 272: | Line 272: | ||
client2.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 first line in the '''.amandahosts''' file above is for the Amanda client running on the server itself. | ||
The next lines allow the user | The next lines allow the root user on each client computer to access the Amanda tape and Amanda index servers on this host with the [[amrecover]] command. | ||
When compiled with the configure option --without-amandahosts, use the file .rhosts and/or /etc/hosts.equiv instead. | When compiled with the configure option '''--without-amandahosts''', use the file '''.rhosts''' and/or '''/etc/hosts.equiv''' instead. | ||
The .rhosts file or | The '''.rhosts''' file or, since version 2.5.0, the '''.amandahosts''' file also require strict permissions. These files should be owned by the Amanda user, which should have exclusive read privileges to them; they should not be accessible to any other user. | ||
Also, the home directory of the Amanda user (containing the '''.amandahosts''' file) should be write-protected from modification by any other user: | |||
Also, the home directory of the Amanda user (containing the .amandahosts file) should | |||
# chown amandabackup ~amanda ~/.amandahosts | # '''chown amandabackup ~amanda ~/.amandahosts''' | ||
# chmod 755 ~amanda | # '''chmod 755 ~amanda''' | ||
# chmod 600 ~amanda/.amandahosts | # '''chmod 600 ~amanda/.amandahosts''' | ||
==Backup client configuration== | ==Backup client configuration== |
Revision as of 20:21, 11 November 2007
Installing Amanda
Use any of the following methods to install Amanda:
- Run one of the installation packages available from Zmanda or elsewhere:
- The Zmanda downloads site includes installation packages for Debian/Ubuntu, Red Hat Enterprise Linux 4.0, Red Hat Enterprise Linux 3.0, Fedora Core 7, Fedora Core 6, Fedora Core 5, Fedora Core 4, Fedora Core 3, SUSE Linux Enterprise Server 10, SUSE Linux Enterprise Server 10 and SUSE Linux 10.0) and Windows. If you are using packages from Zmanda downloads page, go to the Zmanda packages quick start example. If you are using Windows client, refer to the Windows client page for installation instructions.
- Linux and BSD distributions include Amanda packages, as does the Sun freeware site.
- Compile Amanda from the source RPM. Obtain the RPM from one of the sites mentioned above, or from the CVS source tree - 2.5.1 and earlier versions, or the subversion tree (post-2.5.1)
Whether you are installing Amanda packages or compiling from the source, please see the installation page for detailed instructions.
The pre-built Amanda packages make some configuration assumptions regarding the location of log files, .conf files, binaries, etc. Packages from the Zmanda downloads page perform these configuration steps at the end of the installation procedure. Please see Amanda packages from Zmanda downloads page for a list of configuration steps that are performed.
Collecting configuration information
To set up Amanda backups, you will need to know the configuration parameters of the Amanda installation you are setting up. If you built Amanda from the source tree, these are in the form of configure script parameters. If you have installed binary packages from another source, use the amadmin command piped to grep to determine the Amanda parameters. These commands must be run as superuser (root).
- "CLIENT_LOGIN"
- Amanda user. This user id is used by the backup process. Example: amandabackup, amanda
# /usr/sbin/amadmin xx version | grep CLIENT_LOGIN
- "CONFIG_DIR"
- Amanda configuration directory. All Amanda configurations in the Amanda server are stored here. Default: /etc/amanda
# /usr/sbin/amadmin xx version | grep CONFIG_DIR
- "AMANDA_DBGDIR"
- Amanda directory for debug log files. Default: /tmp/amanda
# /usr/sbin/amadmin xx version | grep AMANDA_DBGDIR
- "libexecdir"
- Amanda directory where executables started by amandad process are installed. Default: /var/lib/amanda
# /usr/sbin/amadmin xx version | grep libexecdir
- "listed_incr_dir"
- This directory in Amanda client is used by GNU tar command. This directory only used if GNUTAR is configured as a backup program in the dumptype section of amanda.conf. Default: /var/lib/amanda/gnutar-lists
# /usr/sbin/amadmin xx version | grep listed_incr_dir
Configuring the backup server
Create an Amanda 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. Do not run Amanda as the root user. The Amanda user name is defined by the CLIENT_LOGIN parameter from the Collecting configuration information section.
It is possible to change the name of the user used during Amanda compilation. Amanda packages from different distributions use different user names and home directories for Amanda.
For example: If you install Amanda using pre-built packages from Zmanda downloads page, a user "amandabackup" gets created, and is added to the group "disk" with the home directory "/var/lib/amanda". You must assign a password to the "amandabackup" user for unlocking the account.
Alternatively, if you built Amanda using the source tree, you can create the user by running the useradd command. For example:
# useradd -u amandabackup -g disk -d /var/lib/amanda -s /bin/bash -c ...
If you are running Network Information Services (NIS, a.k.a. Yellow Pages or YP), you can add the Amanda user to your NIS database. Consult your NIS documentation for details.
Make sure that the Amanda programs are accessible to the Amanda user (in other words, add them to that users PATH). For example, if the programs reside in /usr/local/sbin directory, set the PATH variable in .profile, and/or .bashrc in the Amanda user's home directory. The following script excerpt shows how to set PATH variable in a shell script:
# Prepend these directories to PATH if needed for d in /usr/local/bin /usr/local/sbin do case :$PATH: in *:$d:*) : ;; *) PATH=$d:$PATH ;; esac done
Invent a name for the configuration
You must provide a unique name for each configuration in Amanda. This named configuration acts a backup profile, allowing you to reference a set of configuration files describing the source and target for the type of backup you want executed. Each configuration specifies the source and target of the backup:
- The backup source defines the disks, partitions, or directories you intend to back up.
- The target defines the destination of the copied data, such as tapes or disk directories.
You may define multiple configurations. Some commonly used configuration names:
- daily for normal daily backups
- archive for offsite stored archive tapes having only full dumps,
- test for your test environment
- DailySet1. Some Linux distributions ship Amanda with this default configuration name.
To create a configuration, first create a directory with the chosen configuration name in the Amanda CONFIG_DIR (See the CONFIG_DIR value described in the Collecting configuration information section:
$ mkdir -p /etc/amanda/daily
This directory works as the configuration name (label) for the configuration files.
Most Amanda commands take the configuration name as the first argument.
Modify amanda.conf
Copy the example amanda.conf into the configuration directory. Under many Linux distributions, this file is located in /etc/amanda/DailySet1. Edit the configuration file as necessary for your site, consulting the amanda.conf(5) man page if necessary.
It is recommended that you set up a quick test environment for disk based backup. See the amanda.conf parameters described in the Test environment with virtual tapes page.
Note the values you choose for the next parameters in amanda.conf:
logdir "/etc/amanda/daily" # log directory infofile "/etc/amanda/daily/curinfo" # database filename indexdir "/etc/amanda/daily/index" # index directory tapelist "/etc/amanda/daily/tapelist" # list of used tapes
Then create these directories or files, making sure the directories and files are owned by the amanda user:
# chown -R amandabackup:disk /etc/amanda # su - amandabackup $ mkdir -p /etc/amanda/daily $ touch /etc/amanda/daily/tapelist
The directories curinfo and index are created automatically if amandabackup has write permission in the /etc/amanda directory.
Specify holding disks in the amanda.conf file:
amanda.conf:
holdingdisk hd1 { directory "/space/amandahold/daily" ... }
And create them:
# mkdir -p /space/amandahold/daily # chown -R amandabackup:disk /space/amandahold
Add entries in /etc/services on the server
Add the Amanda services to /etc/services file on the server. Before you do so, examine /etc/services for existing Amanda entries. Most UNIX and Linux distributions already provide the required entries. If you can't find them, add entries such as:
amanda 10080/udp
amandaidx 10082/tcp
amidxtape 10083/tcp
You may specify a different port number if desired, but it must match the port number in the /etc/services file of the Amanda clients that connect to the Amanda server. If you are running NIS (aka YP), you must add the Amanda service to the NIS services database. Consult the NIS documentation for details.
Configuring Internet services on the Amanda server
Determine whether the Amanda server uses inetd(8), xinetd(8), or Dan Bernstein's daemontools.
- Note that the server configuration of Amanda does not require the amandad entries shown in the examples below. However, because the Amanda server is usually a client for itself (i.e. the Amanda server should be backed up), the amandad entries have been added.
Configuring inetd on the server
These entries are for Amanda 2.5.0 or earlier versions. For Amanda 2.5.1 or later versions, please see Configuring_bsd/bsdudp/bsdtcp_authentication section.
If the server uses inetd, then add these lines to the inetd.conf on the tape server host:
amanda dgram udp wait $USER $LIBEXECDIR/amandad amandad amandaidx stream tcp nowait $USER $LIBEXECDIR/amindexd amindexd amidxtape stream tcp nowait $USER $LIBEXECDIR/amidxtaped amidxtaped
where $LIBEXECDIR is the complete path to where the amandad, amindexd and amidxtaped executables are located, and $USER is the Amanda user. The first entry (amandad) is not required 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 to display help.
Use the kill command to force inetd to refresh its configuration:
# kill -1 inetd_process_id
On older systems you may have to kill it completely (kill -9) and restart it.
Configuring xinetd on the server
If the Amanda server uses xinetd, you must add the following services to the xinetd configuration (usually /etc/xinetd.d) and edit the paths:
These entries are for Amanda 2.5.0 or earlier versions. For Amanda 2.5.1 or later versions, please see Configuring_bsd/bsdudp/bsdtcp_authentication section.
/etc/xinetd.d/amanda:
service amanda { disable = no socket_type = dgram protocol = udp wait = yes user = $USER group = $GROUP groups = yes server = $LIBEXECDIR/amandad } service amandaidx { disable = no socket_type = stream protocol = tcp wait = no user = $USER group = $GROUP groups = yes server = $LIBEXECDIR/amindexd } service amidxtape { disable = no socket_type = stream protocol = tcp wait = no user = $USER group = $GROUP groups = yes server = $LIBEXECDIR/amidxtaped }
The first entry (amandad) is not required when the server itself is not configured as a client.
Some administrators prefer to split up the above entries in 3 files instead of one.
Make xinetd reread its configuration file:
# kill -HUP xinetd_process_id
Configuring daemontools on the server
If your tape server uses Dan Bernstein's daemontools (http://cr.yp.to/daemontools.html) instead of (x)inetd, you must create amandaidx and amidxtape services manually.
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 the service directories to the svscan directory:
# cd /service # ln -s $prefix/etc/amanda/supervise/amandaidx . # ln -s $prefix/etc/amanda/supervise/amidxtape .
svscan should detect and start the new services automatically.
Create the disklist file
The disklist file is located in the same directory as the amanda.conf file. Start with a small number of entries while you are testing.
disklist:
client1.example.com /some/dir comp-user-tar client2.example.com /var comp-user-tar
Note that you might want to temporarily set the option "record no" 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 still run, but it will not interfere with your current dumpdates. However, you shouldn't run with the "record no" option set under normal backup operations.
Add crontab entries
Schedule the amcheck and amdump command by use of crontab:
0 16 * * 1-5 /usr/local/sbin/amcheck -m confname 45 0 * * 2-6 /usr/local/sbin/amdump confname
Note: Some operating systems have a shared crontab for all users, and may require a userid to be specified for each entry. See the cron(8) man page from the host system for details.
With crontab entries from the example above, 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.
You may want to delay adding these crontab entries until all the tests have succeeded.
Create file .amandahosts on the server
Create a file named .amandahosts in the home directory of the Amanda user. The syntax is similar to that of the .rhosts file. An .amandahosts file is required 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 - amandabackup $ cat .amandahosts amandahost.yourdomain.com amandabackup 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 root user on each client computer to access the Amanda tape and Amanda index servers on this host with the amrecover command.
When compiled with the configure option --without-amandahosts, use the file .rhosts and/or /etc/hosts.equiv instead.
The .rhosts file or, since version 2.5.0, the .amandahosts file also require strict permissions. These files should be owned by the Amanda user, which should have exclusive read privileges to them; they should not be accessible to any other user. Also, the home directory of the Amanda user (containing the .amandahosts file) should be write-protected from modification by any other user:
# chown amandabackup ~amanda ~/.amandahosts # chmod 755 ~amanda # chmod 600 ~amanda/.amandahosts
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 Amanda 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.
If the user does not exist, create one:
# useradd -u amandabackup -g disk -d /var/lib/amanda -s /bin/bash -c ...
If you are running NIS (aka YP), you can add the Amanda user to your NIS services database. Consult your NIS documentation for details.
You can use a Amanda client user name different from the server user name. If a different user is used in the client, it is necessary to configure amanda.conf appropriately. See client_user field in DUMPTYPE section of amanda.conf.
Create file .amandahosts on the client
Create a file named ".amandahosts" in the home directory of the Amanda user 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.example.com amandabackup
This entry allows the user amanda on host amandahost.example.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 .rhosts file or (since version 2.5.0) the .amandahosts file also need strict permissions. They should be owned by the Amanda user and not be readable or writeable by anyone else. Also, the home directory of the Amanda user (containing the .amandahosts file) should not be writeable by anyone else:
# chown amandabackup ~amandabackup ~/.amandahosts # chmod 755 ~amandabackup # chmod 600 ~amandabackup/.amandahosts
Create file /etc/amandates and chmod /etc/dumpdates
Create an empty file /etc/amandates and make it owned by the Amanda user.
Note: when installing from RPM or debian packages, this step is already done.
# touch /etc/amandates # chown amandabackup:disk /etc/amandates
Make the file /etc/dumpdates writable by the Amanda user:
# 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).
Add 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.
Configuring inetd on client
These entries are for Amanda 2.5.0 or earlier versions. For Amanda 2.5.1 or later versions, please see Configuring_bsd/bsdudp/bsdtcp_authentication section.
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 $LIBEXECDIR/amandad amandad
where $LIBEXECDIR is the complete path to where the amandad executable is located 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.
Configuring xinetd on client
These entries are for Amanda 2.5.0 or earlier versions. For Amanda 2.5.1 or later versions, please see Configuring_bsd/bsdudp/bsdtcp_authentication section.
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 = $LIBEXECDIR/amandad }
where $LIBEXECDIR is the complete path to where the amandad executables is located, $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>
Configuring 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 GNU-tar, then you have to create a directory for it. Create the directory, making sure the Amanda user can write into it:
# mkdir -p /usr/local/var/lib/amanda/gnutar-lists # chown -R amandabackup:disk /usr/local/var/lib/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.
Using the configuration
Label tapes or vtapes
Backup to tapes
Make sure the tapedrive has the correct settings such as compression off and variable blocksize before labelling the tape. Label the tape using the amlabel command. These commands must be executed as Amanda user (amandabackup)
$ mt -t /dev/nst0 compression 0 $ mt -t /dev/nst0 setblk 0 $ amlabel daily Daily-01
The tape label, in the example above "Daily-01", must match the labelstr regular expression specified in the amanda.conf file. Otherwise amlabel will give an error.
Backup to disk
Amanda uses vtapes to emulate tapes on disk. This is useful for testing Amanda configuration.
Add the tapedev entry to the amanda.conf
amanda.conf:
tapedev "file:/space/amanda-vtapes/tape"
A "vtape" is a directory with a "data" subdirectory inside. Following commands create a vtape.
# mkdir /space/amanda-vtapes # chown amandabackup:disk /space/amanda-vtapes # su - amandabackup $ mkdir -p /space/amanda-vtapes/tape/data
You can use ammt command to manipulate the vtape:
$ ammt -t file:/space/amanda-vtapes/tape rewind $ amlabel test Test-01
You can even emulate a vtape-changer having many tapes, as described in a Test environment with virtual tapes.
Configuration check
Run amcheck command as the backup user (amandabackup in the our example)
$ amcheck daily
Above amcheck command verifies configuration of Amanda server and Amanda client(s).
Resolve all the errors and warnings found by amcheck command. All messages with prefix NOTE: are informational messages. Error messages are explained in the wiki section Amcheck issues.
Log files
When debugging the setup, the debug log files created by the different Amanda programs can be a great help. The debug directory is usually /tmp/amanda (See #Collecting information for configuration section)
The Amanda client programs create a debug file in this directory. The filename starts with the program name, followed by a date-time stamp.
The Amanda server program writes a log in a file named "amdump" in logdir specified in amanda.conf. When finished the file is named "amdump.1"; the previous file is then found with name "amdump.2", etc.
See Amanda log files for detailed information.
Some specific problem you may encounter are explained in the section Troubleshooting.
Run a backup
Rerun amcheck several times, until all the errors amcheck finds are solved.
Please note that this process is part of the normal way of setting up AMANDA: AMANDA is a complex combination of multiple parts and therefore the initial setup has to meet several requirements like existing directories, proper permissions and so on. The output of the amcheck-binary should provide you with any needed pointers to what is missing where.
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.
You might also do:
$ amdump daily &
to run that process in the background and log off in the meantime.
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
Testing recovery
You really need to test that you can restore a file from the backup. We assume that you have indexing on in the dumptype, and use amrecover, which looks like a ftp client program. We'll restore into a temporary location (a very good idea in the real, non-testing world also). To run amrecover you need to be root (and have an entry for that host in .amandahosts on the server, see "The File .amandahosts on the Server" above.
# mkdir /var/tmp/myrestoretest # cd /var/tmp/myrestoretest
Don't forget to rewind the tape!
# ammt -t file:/space/amanda-vtapes/tape rewind # amrecover test ... Invalid directory - /var/tmp/myrestoretest amrecover>
Amanda assumes that you are located in the top directory of a entry in the disklist, and complains here the current directory is not a valid disklist entry. No problem, that's what we intended. We set the disk manually, and explore the index, using ftp-client-like commands.
amrecover> setdisk /var 200 Disk set to /var. amrecover> ls ... amrecover> cd log amrecover> add messages.1 Added /log/messages.1 amrecover> extract Extracting files using tape drive file:/space/amanda-vtapes/tape on host amandahost. The following tapes are needed: Test-01 Restoring files into directory /var/tmp/myrestoretest Continue [?/Y/n]? y Extracting files using tape drive file:/space/amanda-vtapes/tape on host amandahost. Load tape Test-01 now Continue [?/Y/n/s/t]? y ./log/messages.1 amrecover> quit
Common configuration errors
- Directories/files created during the configuration are not writeable by the backup user (amandabackup in our example)
- Running some programs as root, instead of the Amanda user, creates some files owned by root instead of the Amanda user. When later running as the Amanda user, 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 non-rewind version of the tape device in your amanda.conf file.
- Forgetting to set "disable = no" for amanda services in xinetd configuration files.
- Forgetting to have (x)inetd reread the config after adding the entries. Use netstat -a command to verify the ports if xinetd/inetd listening on the ports it should be listening on.
- Wrong hostname (Use fully qualified domain names) in .amandahosts file. Not specifying IP address and host names in /etc/hosts file
- Firewall between client and server. Firewall should correctly configured to allow amanda traffic between server and client. See Firewalls & NAT and configuration with iptables sections.
- Sendmail/postfix/... configuration on the mail server refusing mail from your Amanda server. Amanda sends notification emails as non-root user (Amanda user). Sendmail or Postfix or mail server software should be configured to allow emails from non-root user. Also the SMTP-server of your ISP might block mails from [email protected] if the mailbox does not exist there.
- When upgrading a client and changing the user from 'amanda' to 'amandabackup', remember to delete all amandarelated files at /tmp. They will have wrong permission. Amanda will create new ones when needed.
For more information on resolving other issues, see Troubleshooting section.
Start production run
- Remove the "record no" 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 for 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 forums and Amanda-users mailing list: