Table of contents
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:
FAILURE AND STRANGE DUMP SUMMARY: ppragin /home lev 0 STRANGE ppragin /home lev 0 FAILED [out of tape] NOTES: planner: Forcing full dump of ppragin:/home as directed. taper: tape DailyTape-06 kb 81888 fm 1 writing file: Input/output error driver: Taper error: "[writing file: Input/output error]" driver: going into degraded mode because of taper component error.
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 {
user-tar
tape_splitsize 1 Gb
comment "tape-spanning user partitions dumped with tar"
}
Choosing a proper splitsize:
tape_splitsize
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.
fallback_splitsize
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.