TUTORIAL: Amanda - Creating Successful Backups

by Gavin Henry Amanda, the Advanced Maryland Automatic Network Disk Archiver; is a backup system that allows the administrator of a LAN to set up a single master backup server to back up multiple hosts to a single large capacity tape drive. Amanda uses native dump and/or GNU tar facilities and can back up a large number of workstations running multiple versions of Unix. Recent versions can also use SAMBA to back up Microsoft Windows hosts. NOTICE: This is an updated and amended version for Fedora, using Xander Harkness' original article with his permission. I was searching a few weeks ago for a good backup program and tried Arkeia and hated it, as it was very complicated. Xander shared my feelings, as indicated on his site, and I thought I would use his excellent article, but update it for this. The installation and configuration can be done over a few evenings or mornings for the typical system administrator or home user, or in one day, if you have time. NOTE: This tutorial assumes you have a working and installed SCSI tape drive.

Installation - Server Side Download packages the rpm packages (for server and clients, issue rpm -ivh *.rpm in the appropriate directory.):

amanda-2.4.4p1-1.i386.rpm for the server and client. amanda-client-2.4.4p1-1.i386.rpm for the client only. amanda-server-2.4.4p1-1.i386.rpm for the server only.

or simply:

apt-get install amanda amanda-client

and

apt-get install amanda amanda-server

Now onto the configuration; Step 1: Run the command:

amtapetype -f /dev/nst0
(this is not a spelling mistake). This is done so that you may receive an analysis of the tape device and the tape types. This is relevant, for example a Compaq 12/24 Gb DAT drive using DDS3 tapes may only provide

10Gb of space for backups. If the AMANDA configuration is told that the tapes will hold 12Gb then you will consistently get failed backups owing to lack of space. The output from tapetype may well take many hours as it writes to the complete tape a couple of times. The output will look something like this:

tapetype tape-dds3 { comment "just produced by tapetype program" length 9922 mbytes filemark 0 kbytes speed 973 kps }
NOTE: The comment and typetype can be anything you like. You need to edit the file

/etc/amanda/DailySet1/amanda.conf
about half-way down the file you will find many tape definitions and you should add the new one you have just created. Please note that the name of the tape should be unique within the file, I have called mine SONY-DSS-4. do not put spaces in, keep it short and simple. You will see other tape names such as DAT and QIC-60. Also ensure you get both parentheses in too. Further up in the file you will see the definition within the configuration file: tapetype HP-DAT (or similar), this should be changed to tapetype yournewname. There are three amanda packages available for Fedora, these are amanda, amandaclient and amanda-server. For the clients you will only need amanda and amandaclient. For the server you will obviously need amanda-server. There is an example configuration in /etc/amanda/DailySet1/, using this and modifying the files to make them work for the particular setup required is the easiest option.

Step 2: Edit the file /etc/amanda/DailySet1/amanda.conf, the items you need to set in this file are as follows: org - This is in the email subject to differentiate between different backups. mailto - This should be set to the administrator's email addresses. Multiple addresses may be entered separated by spaces. tapecycle - This is the number of tapes in circulation. It is much easier if the tapes are labelled before we start testing. If Amanda encounters an unlabelled tape, it will be rejected rather than attempt to overwrite it. tapedev /dev/null - this should be changed to tapedev /dev/nst0, as this is the non-rewinding device for Linux.

Step 3: Label a tape: The command should be run as amanda, so here we have the command, by the user root

su amanda -c "/usr/sbin/amlabel DailySet1 DailySet101"

This command may be broken down as follows: su (super user / switch user) to amanda -c (run command as this user) amlabel a tape belonging to backup group DailySet1 and label it as DailySet101. Note that the amanda.conf file specifies what the tapes may be labelled as, by default this is DailySet100 to DailySet199. The default back up cycle is a month. If there is an error you normally get a good error message to advise you how to fix it. You will probably get a warning message regarding inability to read .bashrc, this is not something to worry about. I would suggest getting one backup to work and then labelling all the tapes, this may take some time as each tape could take 30-45 seconds to label. Now we set one partition to backup: Before this step make sure, as root, you change (on the server and on the client) disable = no in /etc/xinetd.d/amanda and /etc/xinetd.d/amandaidx (on the client only) thenservice xinetd restart. Issue a netstat -ul | grep amanda and you should have

udp

0 *:amanda

*:*

edit file /etc/amanda/DailySet1/disklist down at the bottom, comment out using # all of the backups that are there by default or for example. Put in one backup that being the name of your machine: localhost /etc comp-root-tar This will only backup the /etc partition, which is normally quite small and makes a good test. Final task for Step 3 is to test and then run a backup: run the command:

su amanda -c "/usr/sbin/amcheck DailySet1"

This should give us some diagnostic data and tell us whether there are any problems. If this is the first time the backup has been run, it will normally complain about missing index files. These are created during the backup. Try running the backup and it will continue until finished at which point it will send the admins an email to tell you all is done and provide a report:

su amanda -c "/usr/sbin/amdump DailySet1"

Step 4: Once we have operational backups, we can then automate them: As root run the following command:

crontab -e
This will normally open the vi editor to edit your cron schedule. press i to insert and type the following:

# backup daily 5 2 * * 1,2,3,4,5 su amanda -c "/usr/sbin/amdump DailySet1" 0 16 * * 1,2,3,4,5 su amanda -c "/usr/sbin/amcheck DailySet1"
These will run backups at 2:05am every weekday (late Sunday night - Monday morning) and at 4pm run a diagnostic to ensure that you have put the correct tape in and that all backup hosts are available.

Step 5: The last jobs are to add disks / machines to the backup, this will probably carry on over time as the system is tweaked and machines are added to the network. The Amanda client is only available to Unix systems at present; however other systems may be backed up using file shares and the samba libraries. For every machine that you add to the disklist / backup you have to tell the client machine that it authorises the backup server to access it. This is done by putting the backup server name in the following file:

/var/lib/amanda/.amandahosts
Just put the server name on a line on its own. Please note that the authorisation will fail if it fails to resolve this IP using DNS. To get round this you can enter the name and IP address in the /etc/hosts file. you can then add more machines to the disk list as follows:

client1.domain.co.uk /etc comp-root-tar client1.domain.co.uk /home comp-root-tar client2.domain.co.uk hda1 comp-root-tar

NOTE: You can either use hardware names or the partitions The hard drive names may be found using the command mount with no arguments. Please also note that amanda cannot backup a disk or partition larger than one disk at present. This

may change in the future. Amanda works very well spreading full backups across the backup cycle, so that full backups are done as frequently as possible and does not leave a huge backup rush at the month end. Windows systems: To backup windows systems you may wish to ensure that you have the latest version of Amanda available. These systems are also entered into the disklist file as follows:

sambaserver.domain.com //windowsclient/share comp-roottar

Windows clients also need to use another file containing the passwords for the shares: The share containing the passwords is /etc/amandapass and has the following format:

//windowsmachine/share user%pass
This file must be readable only by user amanda and group disk. This can be adjusted using the following commands:

chown amanda.disk /etc/amandapass chmod o-rwx /etc/amandapass

NOTE: I had loads of trouble getting xinetd.d to make amanda to listen on the server, this was due to the following line being missing in /etc/xinetd.conf

includedir /etc/xinetd.d
I hope everything is straight forward for you!!! Please e-mail me below if you have any troubles :-) Well, that's it for now. For any comments or corrections, please e-mail me. Keep an eye out for "Amanda - Restoring Successful Backups".