http://wiki.zmanda.com/index.php/How_To:Fill_tapes_to_100%25


Wayne Thorpe wrote:
> *Questions: How can I get all 33.9 GB of data on my 40GB tape media?
> How can I get as much data as possible on first tape before moving to
> second tape?*
>
>
> Hello,
> Summary or problem is as follows,
> *-OS*: Solaris 9
> *-Version #:* AMANDA 2.5.1p2
> *-TapeInfo:* Quantum DLT4000, 40GB Native, 80GB,
> *-Driver Info:* /dev/rmt/0n (no hardware compression)
> *-Problem:* I have 33.9 GB of comressed data spread accoss 14 different
> partitions that are scheduled for backup to tape at level 0
> weekly. After software compression, each partition dump size range
> between 2.3MB and 7.8GB.
> The problem is that I getting a lot of wasted space on the tape
> writes. Runtapes in amanda.conf = 2. The first fills up to only 33.4%
> and then AMANDA moves job to a second tape filling up to 45.6%.
> In previous backups a ?ran out of tape? error appeared after using both
> tapes at under 50% and I would be forced to do a amflushed the next
> morning to a 3^rd tape.
>
> **
> *Detail of Settings in amanda.conf:*
> inparallel 4
> dumporder "sSsS"
> taperalgo firstfit

Make those:

dumporder "SSSS"
taperalg largestfit


>
> runtapes 2
> tpchanger "chg-zd-mtx"
> tapedev "/dev/rmt/0n"
> tapetype QUANTUM-DLT4000
>
> define tapetype QUANTUM-DLT4000 {
> comment "Quantum DLT4000 (hardware compression disabled)"
> length 39936 mbytes
> filemark 4 kbytes
> speed 1008 kps
> }

Was this entry created by amtapetype?
Or did a human add those misleading comments?

This is the entry in tapetypes in the above wiki:
http://wiki.zmanda.com/index.php/Tapetype_definitions#Quantum_DLT4000

define tapetype QUANTUM-DLT4000 {
comment "Quantum DLT4000 (hardware compression disabled)"
length 19534 mbytes
filemark 4 kbytes
speed 1096 kps
}

And with hardware compression enabled, together with software
compression, you probably get around 17541 mbytes on a tape.

http://wiki.zmanda.com/index.php/FAQ:Should_I_use_software_or_hardware_compression%3F


> define dumptype comp-root-tar {
> root-tar
> comment "Root partitions with compression"
> compress client fast
> tape_splitsize 3994 mbytes
>
> **
> *Output from Mail Report:*
> These dumps were to tapes tapebac07, tapebac08.
> The next 2 tapes Amanda expects to use are: 2 new tapes.
> The next 2 new tapes already labelled are: tapebac09, tapebac10.
>
>
> STATISTICS:
> Total Full Incr.
> -------- -------- --------
> Estimate Time (hrs:min) 0:09
> Run Time (hrs:min) 8:38
> Dump Time (hrs:min) 6:16 6:16 0:00
> Output Size (meg) 33944.8 33944.8 0.0
> Original Size (meg) 84163.4 84163.4 0.0
> Avg Compressed Size (%) 40.3 40.3 --
> Filesystems Dumped 14 14 0
> Avg Dump Rate (k/s) 1539.6 1539.6 --
>
> Tape Time (hrs:min) 6:44 6:44 0:00
> Tape Size (meg) 33945.6 33945.6 0.0
> Tape Used (%) 85.0 85.0 0.0
> Filesystems Taped 14 14 0
>
> Chunks Taped 19 19 0
> Avg Tp Write Rate (k/s) 1434.7 1434.7 --
>
> USAGE BY TAPE:
> Label Time Size % Nb Nc
> tapebac07 3:07 15724M 39.4 11 13
> tapebac08 3:37 18222M 45.6 3 6

Just a few lines further in the report in the "Notes"
section Amanda indicates the place where it ran into EOT.
If that amount is sufficiently near your stated amount, then
you better lower the tapecapacity in the tapetype a little
bit. That is because not all tapes are equal length, and
the penalty of not fitting an image to tape is to restart the
image ALL OVER again on the next tape.