Amanda, I Don't Care About Tapes

FIXME: WARNING: As of Wed Dec 9 11:53:45 PST 2009, untested. Just
notes.

Amanda is, I'm told, a very robust backup
system with excellent tunability and performance. I find it
annoyingly complicated myself, and I find its dependence on the
concept of tapes incredibly annoying; I'd rather use
BackupPC, for disk-based
backups anyways. But my work wants to use it for performance
reasons, even though we're doing disk-based backups.

The problem is that Amanda is really
attached to the concept of tapes. In the
supposed
"how to" for setting up disk-based backup, you'll notice that
you're actually setting up virtual tapes. Ugh.

This means you have to make a lot of ferociously irrelevant
decisions, like how big the "tapes" are, and how many "tapes" each
backup run will require, and on and on. I just don't care; I have a
bunch of disk; use it!

It turns out there is a way around all this, to get what you
want if you just have a bunch of disk and want Amanda to use it.
It's non-trivial to figure out, though, so I'm writing it down here.

I assume you've got at least Amanda 2.6 here.

First, make your big pile o' disk space. You can have more than one
such pile, although I won't cover that here; I just did RAID5 and
LVM (these are *backups*, after all; the odds of the backup machine
failing at the same time as the real machine are so slim as to be
irrelevant, so I didn't feel the need for RAID10 or anything).

Second, grab a disk. Any disk. One is plenty. This is your
holding space.

Pick some amount of the holding space that divides evenly into most of
the big disk. In other words, you want N * the size you pick to be
about 0.9 of the big disk size, so you don't fill it up. The size
you pick is now your tape size. N is the number of tapes you have.
The remaining space on the holding disk will be lost; you'll live.

I'm going to use my numbers here because I like concrete data (and
these numbers will all change anyway as we add more backups). The
holding disk is 476922 MiB, and the big space is 1907698 MiB. So,
we'll use a holding size of 429000 MiB, and a tape size of 428000
MiB, and 4 tapes, for a total possible usage of 1716000 MiB and
191698 MiB left over (our disk alarms go off at 10%, you see). 

holdingdisk hd1 

 Plugin disabled
Plugin comment cannot be executed.




define tapetype HARDDISK {
  length 428000 mbytes
}


That's great, but now there's the problem that a backup less than
428000 MiB in size will lose the remaining space, which is Bad (tm).

To fix this, find the section with the following parameters and set
them as shown: 

flush-threshold-dumped        100 
flush-threshold-scheduled     100 
taperflush                    100
autoflush                     yes


This leaves you with the problem of a backup that is larger than
428000 MiB. Add this: 

tape_splitsize 1000 Mb


to your dumptype listing. For that to work, you'll need to tell
Amanda the maximum number of tapes it can use for one backup; might
as well set this to all of them: 

runtapes 4


The problem that you run into at this point tapecycle: "The ideal
scenario is for the tapecycle to be at least (runspercycle + 1) *
runtapes. It is possible to configure Amanda with fewer tapes than
runspercycle * runtapes but this scenario will not allow Amanda to
function properly and will create at least the possibility of
overwriting data that is still needed for a full restore. " (from
http://wiki.zmanda.com/index.php/Tapecycle). I don't know about
you, but I find the idea of Amanda dealing with space issues by
destroying backups, rather than refusing to backup further, rather
scary. I don't know if this is fixable yet.

List of documentation I used: