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.