The general feeling of the responses was that the DLT tape drives
incorporate maximum compression by default, thus the reason I am getting
120-125GB on a 20/40 Gb DLT tape. I'm only getting 21-23 GB per Unix File
System DLT tape though becaues apparently the information isn't very
compressible. One suggestion was to possibly 'fool' the application into
using the high compression by making that the standard '/dev/rmt/0' device,
though now I don't that would work because we're getting maximum
compression as it is. Any software-based compression (it seems from the
responses) would not be worth the time it would take. It could
significantly increase the backup time and only slightly (if at all)
increase the compression.
And to answer the other question as to data integrity: The one response I
received concerning this was that there should be no issues regarding data
integrity if the higher compression (h instead of m) is used.
Many thanks to the following people who responded (Hope I didn't miss
anybody):
Greg Sawicki <sawicki@interlog.com>
klfergason@amoco.com (Kelly Fergason)
blymn@baea.com.au (Brett Lymn)
Rachel Polanskis <r.polanskis@nepean.uws.edu.au>
===================================================
ORIGINAL POST:
Our current Legato Networker setup references our DLT drives as
/dev/rmt/1mbn and /dev/rmt/2mbn. Since we are using DLT IV type
tapes, (20/40 Gb) would I gain any added compression by using
/dev/rmt/1hbn and /dev/rmt/2hbn respectively? Does it matter if it
is a single or jukebox DLT drive? The reason I am asking is that we
are storing approximately 120-125GB per tape on the tapes in the
jukebox that are Database backups, but the Unix file system back
tapes in the same jukebox only store about 22-23 Gb. I was hoping to
get more compression on the Unix side. If it is possible to use
"hbn" for higher compression, are there any risks involved in data
integrity?
Thanks for any ideas! Will summarize immediately.
Damon
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:53 CDT