DLT capacity

[Dave Chamberlin]

I am confused about DLT capacity. I have a DLT4000 drive on my K460 10.2 box. We use omniback for our Oracle backups, getting about 70G on a tape (DLT type IV). I know the backups are good because I sometimes use one to update the database on our development box. When I initialize media, I let it determine capacity. My (maybe stupid) question is why does the DLT tape box indicate the max capacity I should get is 20G uncompressed/40G compressed when I clearly get 70G (and I don't see any compression boxes checked in omniback)?

[Dan Hetzel]

Hi Dave,

You shouldn't worry too much about that.
The nominal capacity of a DLT 4000 is 20GB uncompressed or 40GB compressed.
To compute the compressed capacity, an estimation is made about the compression rate.
They take a 2:1 ratio, which is why you double the capacity compressed versus uncompressed.

But not all files compress equally, text files will compress at 10:1 or even more, while gzipped archive will compress very little or not at all.

A database file has typically a lot of 'gaps' filled with null characters. Those gaps compress a lot.

Best regards,

Dan

[Frederic Soriano · Accepted solution]

On a DLT 4000, you can store minimum 20G and maximum 40G assuming a 2:1 compression ratio. What is certainly happening in your case is that your files have a better compression ratio than 2:1 (70 GB is 3.5:1). But remeber, this is an AVERAGE compression ratio : depending on the type of files your are backing up, compression ratio can be really high, above all on text files or databases such as Oracle (if your database is not compacted, then you probably have lots of gaps).

If you are storing only binaries, then you wouldn't be able to store a lot more than 20GB, even if compression is activated. I used to backup my ClearCase views on a DLT 4000 (using DLT type IV tapes), and I often overcome the 40GB specified limit. Views consist above all of source files, highly compressible.

If in OmniBack no compression checkbox is checked, then maybe your DLT4000 has hardware compression enabled, thus bypassing OmniBack configuration (have a look at the compress indicator on your DLT drive : it should be lit steadily).

I hope this can help a bit.

Regards.

[Stefan Farrelly]

We backup nightly just oracle db's+indexes to a DLT4000 using Type IV tapes and regularly backup just over 50Gb successfully. However, just the other day it started maxing out so we had to replace it with a DLT8000. The 20/40Gb is only a typically conservative compression ration - to protect the vendor from being sued! If youre getting 70Gb on a Type IV thats great, but I suspect your very near the maximum you will fit on a single tape.

[Dave Chamberlin]

Mystery explained! My DLT has the compress light on, so that is where the compression is occurring. I had noticed that the Oracle datafiles could be compressed with gzip by a factor of almost 10, which is why I get so much on there - it also tells me my idea of zipping the files before putting on tape would not get me any higher storage density...Thanks

[Dave Wherry]

The key is to remember, those are just marketing numbers. Usually do not come close to real world numbers.
As was said, databases usually compress very well. We get 130GB on a DLT IV using DLT8000 drives for our Oracle database.
I've typically found using DAT drives that the opposite of this is true. They rarely approach their marketing numbers. In a perfect/lab scenario a DAT drive will aproach its marketing number. I've used a DAT drive and tape that had marketing numbers of 4GB. It could not completely back up a 2GB drive. DLT's seem to hold a much higher density.
Also, keep in mind that tape quality and how clean the tape drive head is greatly affects your compression ratio. New tapes are typically dirty with residue from the factory. A used tape will usually perform better until it becomes a worn tape. If you have a static database, shutdown, and backed it up twice you would likely get different compression ratios on each tape you use.

[Carlos Fernandez Riera]

Some thinks:

- if are doing compression both by software (gzip) and by software ( compression enable) note that hardware must expent time trying compress, with no result. In facts, you are lossing time, because it is much probable that tape must be stoping and repositioning (streaming).

- Both compression use DCLZ algorimths, so it might be faster by hardware.

- Compression ratios of driver depends on block length and speed transfer, as well as data type. A common error is to use a sort block length i.e dd if.... bs=512( by default) . These drivers need great blocks of data dd ... bs=64k.

- Use Stm, or xstm better, to get statistics of compression, and timex dd (or cpio... tar ..) to see time statistics.

-About 10:1 compression ratio... it seems your database is not very full of data. A typical compression for databases is 4:1 ( 3:1 for me).