Paul Bijnens wrote:
>
> 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.
backup image, meaning DLE? so if it runs out of space, it will right, for
instance, 35% of the DLE to the last bit of the tpae, then start again on the
new tape, thus meaning all data, in teh end, will get written to tape. and we
can use amadmin <conf> find to see what tape the whole DLE was dumped to, right?
we currently have our runtapes to 28. as that is what our library can hold.
it all seems a lot clearer now. thanks
+----------------------------------------------------------------------
|This was sent by rory AT mrxfx DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
|
