Split dumps


Traditionally, Amanda will write one complete backup image as a single file on a single tape. This makes for a relatively painless recovery using native tools (that is, without Amanda), but presents the serious limitation that no dump can be larger than a single tape.

Amanda enterprise edition does not have this limitation.

When to use

All of the concerns here apply regardless of the tape technology; that is, these apply the same if you are using virtual tapes, RAIT, real tapes, or something else.

Large dumps

Any time you have a dump larger than the tape (or virtual tape) size, you must use tape splitting for at least that dump. You can tell that the size of a dump has exceeded the tape space available if you get the message "dump larger than available tape space" (followed by some other more detailed explanation) in the mailed report.

Dumps to multiple tapes

If you are using multiple tapes, then it may be wise to enable tape spanning even if no disk is larger than a single tape. This gives the driver more flexibility in flushing to tape, and may improve performance and reliability.

How to use

All you have to do to enable tape spanning is set the tape_splitsize option in the dumptype:

define dumptype user-tar-span {
    tape_splitsize 1 Gb
    comment "tape-spanning user partitions dumped with tar"


The best general guideline is to set tape_splitsize to 10% of the tape size. This works well for most cases.

The tradeoff with tape_splitsize is as follows: On average, Amanda will waste 50% of the tape_splitsize on every tape. However, a larger tape_splitsize will write fewer filemarks to tape -- making for an easier manual restore, and potentially saving space).

Thus, if you have a tape device with a very small filemark (as specified in the tapetype), and don't plan to do manual restores, then you should set the tape_splitsize to something very small -- perhaps 10 M. On the other hand, if you plan to do manual restores, but tape usage is not such a great concern, then you might set the tape_splitsize to something larger -- perhaps 20% of the tape length.


This option is only relevant if you are dumping without a holding disk. In this case, tape chunks will be buffered in memory. This option has all the caveats of tape_splitsize above, with the added constraint that a larger fallback_splitsize will consume more memory. If you anticipate making split dumps without a holding disk, and you have plenty of RAM, then generally set this option to something large.

For more information, See Amanda wiki