Compression Ratio too High 1

[babaton]

Hello,

I'm running Backup Exec 9.1
evry now and then one of my Super DLT 1 220gb - 320gb tapes reports strange compression results.

On Friday compression was reported as 116:1, on Thursday 57:1.

My average compression is about 1.5:1

The backup seems to have completed ok and checking the restore dialog shows everything that should be backed up in the catalog.

Does this sort of behaviour indicate a faulty tape?

 

[babaton]

Has no one seen this before?

Its straneg as I can restore data but i'd just like to see exactly how much room I have left on the tape.

Its a bit worrying.

Please someone help........

 

[kmcferrin]

Compression level is going to vary with the redundancy of data to be backed up. The more often particular pattens of data repeat within a group of files to be compressed, the higher the potential level of compression. If you are backing up highly repetitive data (text files often meet this criteria) then you will get much higher compression levels than if you are backing up data with more randomness.

That being said, 116:1 seems ridiculously high. But with the right set of data it certainly would be possible. If you were doing incremental backups and most of the changed files were plaintext system logs that basically repeated the same information every 5 seconds, you could expect to see some amazing numbers.

Or it could just be a bug. Do you run a full verify on the tape after the backup to ensure that the data is good?

 

[babaton]

Thanks for the reply.

We're a publishers so the data is pretty mixed, but mainly word,excel and image files.

We're running also running a full backup with verification.

When I restore files everything works just fine, it's just a bit strange the compression is so high.

Last night I got a ratio of 71.3:1
bytes written - 57.3gb
used capacity - 827mb!!!

If this is true then i now know how to backup my mp3s at home!

I'm starting to wonder if its the drive itselfe since we're using hardware compression.

 

[kmcferrin]

While hardware compression may help with compression speed or CPU utilization it's not going to dramatically affect compression ratios. Some compression algorithms are more efficient than others, but what will make the biggest difference is the repetitiveness of the data.

You indicate that you're a publisher, so presumably you have a large number of files that are mostly text. You probably have multiple revisions of a single file that differ only slightly from copy to copy. Those sorts of situations would be conducive to higher compression ratios.

In my experience, data that is mostly text compresses very well. The more text there is, the better. Databases also compress pretty well if they hold mainly text data. Binary files compress less well, but still do pretty good. Images and MP3 files typically will barely compress at all because their file formats are already compressed by desgin.

If you're really curious do some testing. Load up a copy of PKZip or WinZip and try zipping up a collection of files with the highest compression settings available. At the very least you'll be able to see what sort of ratios to expect.

My other thought on the issue is that your software is incorrectly reporting the amount of data backed up. Did it really compress 57.3 GB of data into an 827 MB backup? Or did it do an incremental backup of 57.3 GB of source data, but only find 827 MB of changes?