How To:Split Dumps Across Tapes (Amanda-3.1 and earlier)

From wiki.zmanda.com
Jump to navigation Jump to search

This article is a part of the How Tos collection.

Amanda tape-spanning support is a new feature in the 2.5.0 release, enabling single dump files to be strung across multiple tapes. This permits you to have Disk List Entries (DLEs) larger than any single tape you may have, as well making more efficient use of tape space under certain circumstances.

It works by splitting a large dump file into smaller chunks of a configurable size before writing to tape, allowing AMANDA to regard each individual piece as a dump file in its own right and following "tape full" semantics as it would a normal dump.

Quick and Dirty HOWTO

amanda.conf(5) changes

In the dumptype section of your amanda.conf(5), create an entry akin to the following:

define dumptype user-tar-span {
    root-tar
    tape_splitsize 2 Gb
    split_diskbuffer "/dumps/split_diskbuffer"
    comment "tape-spanning user partitions dumped with tar"
}

Also note

  1. that the value of "runtapes" in amanda.conf(5) must be greater than 1.
  2. split_diskbuffer must be specified or else the tape_splitsize is forced to 10mb

"runtapes"*"length" must be bigger than the maximal size of all dumps in a run. "length" is assigned to your tapetype device used for backup:

In amanda.conf, create entries like

   runtapes        10 
   tapetype HPDAT40
   
   define tapetype HPDAT40 {
    comment "DAT tape drives"
    length 19560 mbytes
    filemark 1147 kbytes
    speed 2957 kbytes
   }



Tape split size

A reasonable rule of thumb for the tape_splitsize value is 1/10 of the size of one tape.

Relationship between chunksize and tape_splitsize parameters:

chunksize is a holding disk parameter mainly to overcome filesize limitations on certain filesystems. One additional benefit is that when using many holdingdisk areas, one dump one holdingdisk can be spread over all these disks, even if each of them would be too small to hold one complete image.

tape_splitsize is the size of chunk on tape. When writing such a chunk to tape, and the tape bumps into EOT, the next tape is loaded, and the complete chunk is rewritten again. Compare this to the alternative to restart the complete dump image on that tape: it avoids wasting too much tape (and time writing it).

Note also that tape_splitsize is a dumptype parameter: you may specify which DLE's should be split, and which not (e.g. not splitting the DLE's that contain the amanda software makes restores easier, when that disk itself was lost).

disklist configuration file changes

Now, in your disklist file, just invoke that dumptype:

nutdumpling /export/home/building/amanda/dumpdata user-tar-span

For more extensive description of configuration options, see the page on amanda.conf(5), specifically the runtapes, tape_splitsize, fallback_splitsize, and split_diskbuffer options.

Restoring

amfetchdump

This utility was written specifically to restore spanning dumps from the command line. It is also useful in general, as a "smart" amrestore which knows how to locate dumps and manage tape changers on its own. See amfetchdump(8) for a complete description of options and behavior.

Usage: amfetchdump [options] config hostname [diskname [datestamp [level ... ]]]

amrestore

You can, technically, use amrestore(8) to restore each individual "split chunk" of a spanning dump (they are, after all effectively just regular AMANDA dumps with strange incomplete data in them). However, amrestore has no capability for reassembling split dumps. Should you be in a pinch, you can still use it to restore each individual piece, then do something akin to:

for i in `ls -1 my_host.my_dle.20021231.0.*`; do dd if=$i >> wholedump.0; done

but this assumes amrestore has stripped off amanda headers. If not, try adding bs=32k skip=1 to that invocation of dd. This is also useful if you're restoring "bare metal," pulling images straight from tape with no AMANDA utilities.

amrecover

amrecover(8) understands tape spanning, and should not require any more work than any other multi-tape restore. You can mix and match old and new clients, though an old server doesn't understand split dumps.