Amanda

[Jason Parker-Burlingham]

Robert Meyer <meyer_rm at yahoo.com> writes:

> I'd like a quick explaination of what needs to be done to set up
> amanda to back up this beast and how tapes are handled.

Okay, first and foremost you'll probably want to compile and install
AMANDA by hand rather than installing a package (if you're using
Debian I can wholeheartedly support the .debs for simple
installations).  If you're not up to this you're probably going to pay
for it later.

But _before_ you do that you should subscribe to the AMANDA user's
list (see http://www.amanda.org/ for more information on that and
AMANDA generally).  The list is your *prime* source of information.
Pay special attention to anything you see John R Jackson saying.

Next you need to understand how AMANDA uses tapes.  At *least* one
tape is used every time you run it (except for, well, exceptional
circumstances like a tape or dumper failure).  It is not currently
possible to store more than one dump on a tape, although some dumps
will take more than one.  For some people, this is a killer defect.

(The rationale is that it's so dangerous---if you screw up writing
tomorrow's backup after today's, you could lose today's dump, thus
(maybe) screwing over tomorrow's, too, if it's an incremental.)

Basically, AMANDA works like this:  you look at how many tapes you
have, how much data you have, how much of it changes and at what rate,
and from that work out the length of your "dump cycle".  1 dump cycle
is the amount of time it takes to start re-using tapes.  While no-one
can tell you what a sensible value is for you, you probably don't want
anything shorter than a week or two.  Probably more.

Then, every day (it doesn't have to be every day but it probably will
be) you run amdump from cron, as root.  amdump first runs another
program to estimate sizes of backups for all the partitions you've
nominated, and will try to dump a combination of incremental and full
backups that will use the same amount of tape as it did yesterday.

After the estimation phase is finished, amdump starts dumping all the
partitions it's going to that day.  It can use either the native dump
program (which I prefer) or GNU tar (though you have to be careful
about which version you're using, since it often has nasty bugs).  I
have also successfully used the XFS dump program for Linux with
AMANDA.

When the backup is done, AMANDA will send the operator email with a
report of what it did that night, and suggest a course of action if
anything went wrong.  Again, the mailing list (and its archives) are
very helpful here.

It's possible to set a time period on a per-filesystem basis that says
"take a level 0 dump this often"; for critical filesystems you'll want
to set this low enough to ensure you get two full backups per dump
cycle (ie before you start writing over old tapes).

I have left out some things, like labelling tapes, and running
amverify, but that's basically how it all works.

> We currently are only using about 5 Gig on a 90-ish gig filesystem
> so we could fit lots on a tape.  We want to start some sort of
> schedule that will allow us to take tapes offsite periodically.

To do this, since you don't have fine control over when the level 0
dumps are made (and what point is there to taking an incremental
backup offsite?), you'll want to set up another configuration (ie
another directory under /etc/AMANDA/ (you'll understand this when you
get going)) which dumps only your most important filesystems, runs
only once per dump cycle, and takes level 0 dumps only.  You may also
want to decide you'll never re-use tapes for this scenario, too.

> We'd also like this to happen automagically after hours.

That's what cron is for!

My qualifications:  I ran the backups for a software startup for
several years; I used AMANDA for the last year of that operation and
never lost a file I couldn't recover.  You may be able to tell I also
wrote extensive documentation about what I did!

A quick word about databases and proprietary formats:  AMANDA stores,
on-tape, files in this order:

        * one tape header, indicating the tape's label (in case the
          paper label scratches off[1])
        * one or more pairs of:
          + a dump header, containing the date and time of the dump,
            and instructions on how to use dd and your dump's restore
            program to effect the data restore by hand.
          + the dump data itself (by far the largest part).

So you can see that even if you lose your backup database (AMANDA does
store a catalog on the host that does the writing to tape) it's still
possible---slow, if you don't know which tape is which, but
possible---to effect a complete `bare metal' restore by hand.

Ask how I know.

jason, delurking

[1] : At least one vendor told me that paper labels on tape are a
      major source of drive failures.
-- 
||----|---|------------|--|-------|------|-----------|-#---|-|--|------||
| ``Ooooaah!                                                            |
|   I'm getting so excited about cheese-making I can't stand it!''      |
||--|--------|--------------|----|-------------|------|---------|-----|-|