Amanda-Users

Re: [Amanda-users] amcheckdump output - questions :)

2008-11-05 15:46:14
Subject: Re: [Amanda-users] amcheckdump output - questions :)
From: Paul Bijnens <paul.bijnens AT xplanation DOT com>
To: amanda-users AT amanda DOT org
Date: Wed, 05 Nov 2008 21:43:39 +0100
rory_f wrote:
Paul Bijnens wrote:
These two concepts are orthogonal:
- Amanda can use multiple tapes for one backup run.
- Amanda can split one backup image over multiple tapes.

It is only the second feature using the "tape_splitsize" parameter that makes
restores more difficult.
See: http://wiki.zmanda.com/index.php/How_To:Split_Dumps_Across_Tapes

But instead of dumping one enourmous DLE in one backup image, you can use
the include/exclude options with gnutar to split the DLE into smaller ones,
each fitting on a tape.
See: http://wiki.zmanda.com/index.php/How_To:Split_DLEs_With_Exclude_Lists

Figuring out tapecapacity and optimizing tape usage is handled with the
parameter "taperalgo largestfit", as explained here:
http://wiki.zmanda.com/index.php/How_To:Fill_tapes_to_100%25


ok,
smaller DLEs is fine. we have been doing this. i just thought using
span was the only way for amanda to intelligently change tapes when a
tape got full. we use a changer script. is that all we need to ensure it
will change tapes when a tape gets full? for instance, we just want to
make sure amanda will look at the size of the next dump, and move onto a
new tape if needed. right? we use a holding disk also, which im sure
makes it easier for amanda to know when to change tapes.

ultimately we want to setup the right DLEs, and archive a whole
proejct, around 6tb at at time. no interaction in this process is key.

Indeed, use a changer and set "runtapes" to something greater than 1.
Amanda will write a tape until she hits End Of Tape (signaled by a write
error actually), and then move to a new tape. The whole backup image will be restarted on the next tape. (With using "tape_splitsize" you
avoid starting the whole image, but start only the last chunk again)

When using a holdingdisk, the dumps are collected in the holdingdisk
unless the estimated backup image is larger than the holdingdisk.
When one complete backup image is finished, Amanda start to put it on tape.
Because many dumps can be collected simultaneously to holdingdisk,
several of them may be waiting to be written to tape. If there are several to choose from, then the "taperalgo" setting decides which one will get tried first. A good setting is "largestfit" (see the wiki url above). If no backupimage that is ready will fit in the estimated
available tapespace, then amanda will try the smallest, which has
the largest chance of fitting in the unknown free space.

The free space at the end of a tape is indeed unknown, because
tapes do not always have exactly the same length; and when using
software compression, the remaining space is even more uncertain, because it depends on the compressability of the previous tape images.