Page last modified 19:20, 8 May 2006 by Ppragin?

How to enable tape spanning in case the data you are backing up is larger then a single tape

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:

 ppragin  /home  lev 0  STRANGE 
 ppragin  /home  lev 0  FAILED [out of tape]
 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 {
    tape_splitsize 1 Gb
    comment "tape-spanning user partitions dumped with tar"

Choosing a proper 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.


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.