I'm not sure the hardware compression is working

[wingene]

Hi


I'm using a HP Storage Works Ultrium 215 with HP LTO-tapes (C7971A) to backup. This tapes have a raw capacity of 100 GB and are able to backup up 200 GB when using a compressionratio 2:1 (that's pretty logic hein).
But I'm not sure this compression is working well.

In the device properties => tab 'configuration', hardware compression is enabled and I'm using the default settings.
In the job properties hardware compression is enabled (Hardware [if available, otherwise none])

When I look to the statistics of a media I see
that 132 GB of data has been backed up, but the compressratio is 1:1.
A bit weird for tapes that have a raw capacitiy of 100 GB

When I use HP Storageworks Library & Tape Tools; I get this info. It says "L&TT determined that your hardware compression algorithm is switched off"

"|__ Analysis Results
    ||__ Compression test started
    ||__ Testing the Ultrium 1-SCSI
    ||__ Before running this test, L&TT determined that your hardware compression algorithm is switched off.
    ||__ This was probably set by your backup software or by other software utility.
    ||__ L&TT will enable the drive hardware compression for the test.
    ||__ On completion, it will revert the drive setting.
    ||__ Compressed write transfer rate = 13.48 Mb/sec (I/O path, not backup data rate)
    ||__ Compressed read transfer rate = 14.63 Mb/sec (I/O path, not backup data rate)
    ||__ Read compression ratio is: 2.62 : 1
    ||__ Write compression ratio is: 2.62 : 1
    ||__ Total MB sent to host: 1199"

Any ideas what is wrong?

I'm working on this because alerts indicate that BE is asking for a new tape during the night.  So there is not enough space on the tape.

Best regards

Tom

[pkh]

You should ask HP why your hardware compression algorithm is switched off.

You can also try using software compression.

[wingene]

Ok Pkh, I've posted this question also on the HP forum.

But it stays weird that BE mentions in the medastatics that a compression rate 1:1 has been used and that there is 132 GB backed up to tape.  This would be 1,32:1, because the tapes are 100 GB big.

[Colin_Weaver · Accepted solution]

A couple of points

Historically some some drives have a small bank of smwicthes (possible under a flap)  that can didsbale hardware compression - I suspect this is less common know than it used to be as firmware can now be used to do the same thing with a software tool to change the settings.

I thought the L&TT tool had a way to a) test compression and b) turn compression on

At the start of a backup job to a tape device, Backup Exec will always turn the compression off and then turn it back on again if the job is configured for hardware compression. This process can be seen in our debug logs (usually with few other lines of debugging between the off and the on entries.)

We have seen it where a firmware version change on a tape device has caused the off command to work, but the on command to fail. The L&TT tool should be able to be used to set the Compression on (and confirm it) and then check the same setting after a backup job.

Also if you know this used to work then the obvious fix is then try the older firmware version.  Unfortunately solving this properly (or where it never worked) might be the responsibilitty of the hardware vendor - to correct the firmware and / or drivers, or the software vendor - to recode the application and / or driver to catch up with the firmware differences.  This might then need a formal support case with one or other of the vendors to solve instead of community postings



With regards the statsical information that is odd but might be an indication that you rhardware is compressing, but an interaxction to display the statitics correctly is not working.

[wingene]

Hi Colin

I think you're right that BE is enabling and disabling hardware compression on the device at the beginning and the end of the backupjob.
I manually enabled it using L&TT, but the next day it was again switched off.
I guess statistics are not working as they should be.

Best regards

Tom