This is interesting. I looked up the native capacities for all types of DLT.
Since you say 35GB, I assume you have DLT7000. If not, that may be you problem
:-) Native capacities are below:
DLT4000 - 20GB - DLTtape IV
DLT7000 - 35GB - DLTtape IV
DLT8000 - 40GB - DLTtape IV
I would say: check you have indeed DLT7000 and you are using IV tapes. If you
have older (III and IIIxt) you'll get less capacity.
Also: check the density used by the drives. This can be read on the frontpanel
of the drives if you insert such a tape. It should say "35GB" but the drive can
be selecting a lower density for various reasons.
What I don's grok is that you say 31GB per tape (sounds reasonable) AND that
backup already used 80 tapes: 80 x 30 = 2400GB ?
Also: What is the device file used to write to the tape drives? If you use
compression on the drive (/dev/rmt/Xcbn), it could be that the compression
algorithm in the drive chokes on "already compressed audio" and actually
increases the amount of data although I doubt that this would double it.
As a last possibility: These tape drives do their best to keep streaming
("running"). If you are feeding them not enough data, the drive will start to
write less tracks on the tape in order to keep running. This will reduce tape
capacity. If the data rate is falling below a certain (secret I think) limit,
the drive will do start/stop mode.
Keep us posted!,
>I'm trying to do a backup, and it seems to be taking more tapes than I
>expect it should.
>Here are the details:
>NetBackup Data Center 3.4.1
>Solaris 8 master and media servers and clients
>DLT tapes, 35GB capacity
>I'm backing up this client:
>[12:07:49]root AT cdl0 DOT prod:/root$ df -k
>Filesystem 1k-blocks Used Available Use% Mounted on
>/dev/md/dsk/d0 15334747 3440095 11741305 23% /
>swap 2269672 16 2269656 0% /var/run
>swap 2293432 23776 2269656 1% /tmp
>/dev/md/dsk/d10 17413250 2829368 14409750 16% /opt/apache
>/dev/md/dsk/d30 121878754 90953189 29706778 75% /audiblewords/downloads
>/dev/md/dsk/d50 818335041 788567840 21583851 97% /cdl0/bk
>/dev/md/dsk/d60 400461265 330097552 66359101 83% /cdl0/content
>/dev/md/dsk/d20 34820241 239462 34232577 1% /opt/apache/logs
>auspex:/auspex/content 20965708 123653 20632397 1% /auspex/content
>auspex:/auspex/vol02 501558096 375170952 121371563 76% /auspex/vol02
>auspex:/auspex/vol00 501558096 449135476 47407039 90% /auspex/vol00
>auspex:/auspex/tmp 225766096 2592 223505843 0% /auspex/tmp
>auspex:/auspex/vol04 501558096 5324 496537191 0% /auspex/vol04
>auspex:/auspex/vol03 501558096 6696 496535819 0% /auspex/vol03
>auspex:/auspex/vol01 501558096 448260064 48282451 90% /auspex/vol01
>[09:47:06]root AT cdl0 DOT prod:/root$
>I've got the class set up as follows:
>"Active" and "Follow NFS" are checked, all other choices (compression,
>cross mount points, etc) are unchecked.
>The file list to back up is:
>By my calculations, those filesystems total 1,279,211,090k, which is
>1,219 GB / 30 GB per tape = 40.63 tapes. (bpmedialist is reporting I'm
>getting roughly 31GB per tape for those big "volxx" volumes -- it's already
>compressed audio data).
>However, I've used over 80 tapes already, and the backup isn't finished
>yet. I don't understand why it's taking so many tapes. These are fresh
>Thanks very much,
>Adam Levin, Senior Unix Systems Administrator | http://www.audible.com/
>Wayne, NJ, 07470 Quis custodiet ipsos custodes?
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
Long may you run.