Backing Up Amanda Metadata

Amanda has a lot of metadata associated with its backups. Logs, configuration data, and more. Yes, you can restore from Amanda backups with just mt (for physical tapes) and tar if need be.

But why bother? Why not save Amanda's metadata along with its backups? With virtual tapes, it's easy. You have your backups somewhere. Along side them you also save key metadata using tar and a compression program.

This assumes you are using virtual tape. It requires a shell script which you call from cron, and a Perl script to get the tape directory.

The Perl Script:

I wrote this function in Perl because I am lazy. The Amanda Perl modules have a tool for parsing an Amanda configuration file. I just use that to pull the tape device out of the configuration file. That is the directory in which Amanda stores its virtual tapes. As luck would have it, one of the examples in the POD was almost exactly what I needed.

#! /usr/bin/perl -w

# Note, you may have to adjust this path:
use lib "/usr/lib/amanda/perl";

use strict;
use Amanda::Config qw( :init :getconf );

my $config_name = shift @ARGV;
config_init($CONFIG_INIT_EXPLICIT_NAME, $config_name);
# apply_config_overrides($config_overrides);
my ($cfgerr_level, @cfgerr_errors) = config_errors();
if ($cfgerr_level >= $CFGERR_WARNINGS) {
  if ($cfgerr_level >= $CFGERR_ERRORS) {
    die("errors processing config file");

my $tapeDev = getconf($CNF_TAPEDEV);
$tapeDev =~ s/^file://g;

print $tapeDev;

The code depends on knowing where the Amanda Perl libraries are. Adjust the use lib line for your installation and you should be set. Note that we strip out the "file:" protocol specification. If you feed these scripts the name of a configuration that uses physical tapes, the results are undefined and probably not what you want.

We assume that the tape device path has the name of the configuration as the last directory. If you have multiple configurations sharing the same hard drive and path, this is probably a good idea.

The Shell Script: amanda.dump

#! /bin/bash

# Run the amanda dumps and back up key amanda data. Run this as the
# backup user. Note the complete utter lack of error checking.


backDir=$( $config)

/usr/sbin/amdump ${config}

umask 0066
cd /
tar cjf ${backDir}/back.var/var.lib.amanda.$(date +\%a).tar.bz2 \
    var/lib/amanda/ --exclude=*~
tar cjf ${backDir}/back.etc/etc.amanda.$(date +\%a).tar.bz2 \
    etc/amanda/ --exclude=*~
tar cjf ${backDir}/back.log/log.amanda.$(date +\%a).tar.bz2 \
    var/log/amanda/ --exclude=*~

We get the configuration as an argument to the script. That way the user can specify multiple configurations to back up at different times and frequencies in cron. We then use the Perl script to get the tape device path. Then we strip off the configuration name. That gives us the name of the Amanda directory. That directory has one or more configurations' worth of virtual tapes. It also has three directories for metatdata:

The Amanda configuration under /etc/amanda
The logs under /var/log/amanda
The metatdata under /var/lib/amanda

N.B.: These paths are specific to my Ubuntu system and the Ubuntu Amanda packages. They might work on Debian installations. They may or may not work on other distributions and other methods of installation. Check your amanda.conf for details. You may find you need more or fewer directories. Also, since the script doesn't build them for you, you will have to do that manually. Fortunately you should only have to do this once.

The file names include the day of the week on which they were created. So you can if need be fall back as much as a week. This also means the files are overwritten weekly. If you do multiple runs in a week, you should have plenty of redundancy.

The Cron Entry

Recent versions of cron have a directory for custom cron entries, /etc/cron.d/. It will not be affected by upgrades, where /etc/crontab might be. So create yourself a file in /etc/cron.d/, and enter a cron line something like so:

  23 0    * * 1-5 backup   /usr/local/bin/amanda.dump DailySet1

See man 5 crontab for the gory details of how this line works. Note that, in good crontab style, we have specified the fully qualified path to the script.