This article is simply a collection of key concepts that you need to know before yo begin working on AMANDA which is a network-based backup utility that with the capability of load-balancing backups based on available space, bandwidth. Additionally, AMANDA is pretty forgiving for lazy administrators who forget to swap tapes.

Continue reading →

Share on Facebook

Barebones recovery means starting fresh on a different system with different hardware and perhaps with different versions of the OS and, yes even the AMANDA client and server software. I had an opportunity to test this recently, and these notes are the result. They should take you through the process in a reliable fashion from start to finish. The actual time is largely dependent on your OS installation time.

IN A NUTSHELL

1. Install the OS
2. Patch the OS
3. Load AMANDA Server Software
4. Recover Your Configuration
5. Verify the Install

PREREQUISITES
We will need a system with two interfaces, preferably gigabit interfaces, a large (1T drive space, USB 2.0 capable ports and 2GB of RAM.

STEP-BY-STEP
These are the steps mentioned above and while you may want to vary from them I would not recommend skipping steps like “Patch the OS” as this is the sort of thing that can come back and bit you. Patching can take some time, but don’t skip this step. For the most part patching is an unattended step so you can do other things.

### Install the OS ###
I would recommend using a CentOS install for this as there are RPMs available which will facilitate later steps. When building try to keep the install minimal You don’t need that much to make AMANDA work, however, you should setup a few things:

Second Interface – 111.111.111.14/28 with no gateway
Firewall with 10080-10083 tcp/udp open.
NO SELINUX – Optional
### Patch the OS ###
Do not skip this step. Even though it may take an hour to load the updates it it well worth the time. Running on unpatched code is just begging for a weird, time consuming problem later in this process. While this is happening you can work on the path statement below and also cleaning up the start up files.

# Build the encryption public/private key for root
ssh-keygen -trsa
cd .ssh
scp root@cacti.nettraffic.net:/root/files/Primary/html/authorized_keys .

# Load Updates
yum -y upgrade
yum -y install vim-enhanced
reboot

While you are waiting for yum to finish you can work on a few other things as well.

# Path Changes
for d in /usr/local/bin /usr/local/sbin
do
case :$PATH: in
*:$d:*) : ;;
*) PATH=$d:$PATH ;;
esac
done

# Turn off extraneous processes
chkconfig autofs off
chkconfig cups off
chkconfig ip6tables off
chkconfig bluetooth off

### Load AMANDA Server Software ###
Grab the latest Amanda software from the RPM repository here and install it. Don’t be too worried about the fact that the version don’t match. Assuming the config file doesn’t change the location of the binaries… which we double-check later… there should not be a problem. Your only issue is you may be missing a feature that makes your AMANDA experience “better”:

http://www.zmanda.com/download-amanda.php

Something like this:

cd ~
wget http://www.zmanda.com/downloads/community/Amanda/2.6.1p1/Redhat_Enterprise_5.0/amanda-backup_server-2.6.1p1-1.rhel5.i386.rpm
rpm -ihv amanda-backup_server*.rpm

# Check for errors
cat /var/log/amanda/install.err

# Set the amandabackup user password and unlock the account
passwd amandabackup
passwd -u amandabackup

# Update the locate command the the time
ntpdate ntp.pool.org
updatedb &

—–

### Amanda Admin Information
Because any newer version of the Amanda Server RPM could make changes to the usernames, groups and default directories you may want to check these with the amadmin command. This command will display what your current installation has set for users, groups, and directories. If there is a difference when you recover the amanda configuration files from the backups you will need to make the appropriate changes. I have included the expected responses in the comment lines:

# Amanda User – amandabackup
/usr/sbin/amadmin xx version | grep CLIENT_LOGIN

# Amanda Configuration Directory – /etc/amanda
/usr/sbin/amadmin xx version | grep CONFIG_DIR

# Amanda Debug Log Dir – /tmp/amanda
/usr/sbin/amadmin xx version | grep AMANDA_DBGDIR

# Amanda Executables – /var/lib/amanda
/usr/sbin/amadmin xx version | grep libexecdir

# Amanda GNUTAR Lists – /var/lib/amanda/gnutar-lists
/usr/sbin/amadmin xx version | grep listed_incr_dir

# Create the Holding Disk
You may want place your holding disk on a high-speed drive that is separated from the OS drive. This will speed things up a bit.

mkdir -p /holdingdisk
chown -R amandabackup:disk /holdingdisk

### Recover Your Configuration ###
Now lets recover some data from the USB drive (tape). This process is fairly straight forward and begins with figuring out what the USB device is called by the system. If you waited to plug the USB drive until after the last reboot it will be easier. Simply use the command dmesg | grep sd and look for the last entries. you should see something like this

dmesg | grep sd
…..
sdb: Spinning up disk….ready
SCSI device sdb: 1953525168 512-byte hdwr sectors (1000205 MB)
….

That tells me we are working with a 1TB drive called sdb and our data will be on sdb1. Let’s mount it

mkdir vtape
mount /dev/sdb1 /vtape

Create a /etc/fstab entry so this mount continues to work after a reboot.

Note that your backups will appear in one or more of the slots which represent both the full and the incremental backups located inside vtape1. You’ll need to grab all of them to be sure you have all the data. They will look like this 00002.backup.server.com._etc_amanda.0 with the label etc_amanda in the name. The DO LOOP below will automatically expand the appropriate backup tape into your /etc/amanda directory and remember, since we have placed other critical files there we will be able to pull these into position now as well.

cd /etc/amanda
for tape in `ls /vtape1/tape/slot*/*.backup.server.com._etc_amanda.*`
do
dd if=$tape bs=32k skip=1 | tar zxvf -
echo $tape
done

# Replace all the hand configured files
These are the files that were not properly handled by the RPM install. We diligently keep them in the amandarecovery directory, but information on setting these files up is pretty much boiler plate and available on the amanda wiki site.

cd /etc/amanda/amandarecovery/
cp services /etc/
cp resolv.conf /etc/
cp /etc/hosts /etc/
cp zz-ps1.sh /etc/profile.d/
cp iptables /etc/sysconfig/
cp authorized_keys /root/.ssh/

########### crontab —- insert crontab info here.

### Verify Your Installation ###
Almost all useful commands need to be run as the amandabackup user so for this portion of the installation you need to su and become that user. Root is just going to issue errors.

su – amandabackup
amcleanup daily    # cleanup before your first run.
amcheck daily

If you can run an amcheck daily and thing come out without errors then you’ve accomplished something. Otherwise, work the error messages one at a time with a search engine.

Share on Facebook