Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Data Compression.... LTO4

Created: 06 Jan 2014 | 27 comments

Morning all.

I am currently running Backup Exec 2010 R3 (Rev. 5204) on a Win 2008 Server.  Attached to this I have a fibre HP MSL2024 Tape library with an Ultrium 1840 LTO4 drive.  Our full backup currently runs at about 5TB

Recently I've noticed our backups failing to complete over 5 LTO4 tapes.  Digging further I noticed all of the LTO's only show 1:1 compression.  This only appears to happen with new tapes.  Using my usual routines the older sets of 5 tapes still are able to fit all the data.

I've read through various topics on here and tried all of the solutions I could see including;

Run HP L&TT compression test - This showed as passed with errors, claiming that another program was switching off compression so it had to switch it on to test.

Updated library and drive firmware

Ran L&TT compression test again - This time it passed with no errors.

Removed the device from Backup Exec and reconfigured it.

I'm still only getting 1:1 compression on new tapes.

Any ideas?

Operating Systems:

Comments 27 CommentsJump to latest comment

Jaydeep S's picture

Try the steps mentioned in this technote to verify that the compression is enabled when BE starts the backup job

http://www.symantec.com/docs/TECH50960

What is different with the new tapes that you have?

CraigV's picture

...have you tried to erase the tapes using HP LTT before being used by Backup Exec?

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

MichaelMoran's picture

Jaydeep - Thanks, will try those steps now.  Nothing is different with the tapes.  Same HP LTO4's that I always use.

CraigV - No, they were brand new tapes when I first used them and they got no compression.  I then used backup exec to erase them before trying again.  Still no joy.  Would it be worth trying the HP erase then?

CraigV's picture

Personally, I would just to rule every option out. Did you perhaps run a cleaning tape too?

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

MichaelMoran's picture

Yes, ran a cleaning tape a couple of times.  As I said though the HP LTT compression test was passed using one of the tapes that backup exec refused to compress on, so I'd assume the hardware is functioning correctly?

CraigV's picture

...I would say so, but stranger things have happened. As long as the BE services were all stopped during the time you were doing this LTT test it should be fine.

The other thing...did you perhaps remove the library completely from within Windows as well as BE before restart the server and re-adding it back?

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

MichaelMoran's picture

No I didn't do that CraigV.  I might give that a go later today.

Jaydeep - I've ran through that technote and noticed that Backup Exec is doing something strange with the compression.

The last MODE_SELECT6 before the write shows that it has switched compression on (1.jpg)

The MODE_SENSE6 after the above doesn't show compression on (2.jpg)

The only MODE_SENSE6 that does show compression as being on is the one prior to MODE_SELECT6 (3.jpg).

I'm not sure where to go from here?

1.jpg 2.jpg 3.jpg
Moe Howard's picture

The MODE_SENSE6 in the second screen shot is the wrong one.

The Raw CDB should look like this:

1A 08 0F 00 14 00

The 0F hex value is the page we need to see, which is the Data Compression Mode Page

The Raw CDB one you posted in the second screen shot is:

1A 00 00 00 C0 00

Look for another MODE_SENSE6 prior to the first WRITE6 is issued and ensure the Raw CDB is for 0F and post a screen shot of that.

MichaelMoran's picture

That's just it, there isn't one.  The 3 MODE_SENSE6's prior to the WRITE and after the MODE_SELECT6 are all the same (2.jpg).  

3.jpg is the only one near there with the 0F hex value and that's before the MODE_SELECT6

pkh's picture

Do the following simple test.  Create a small directory with some text files.  Run a backup job with hardware compression to the tapes that you said gives you compression.  You should get compression.  If you do get compression, it means that there is nothing wrong with the tape drive.

Run the same backup job using the new tapes.  If there is no compression that there is something wrong with the new tapes and you should get them changed.

Moe Howard's picture

I see...that is strange.

Erase an old tape and start tracer.exe. Create a small backup and ensure the compression method for the job is set to Hardware, otherwise none. Save the output to a .bin file by pressing the diskette icon in the tools ui. (name it old.bin)

Follow the same steps using a new tape and attach the .bin file (name it new.bin)

Attach both traces and I will take a look at them for you.

MichaelMoran's picture

I ran my Friday backup routine last night using old tapes and low and behold I got compression.  Not much compression, but compression all the same

Tape 1 - 1.3:1

Tape 2 - 1:1

Tape 3 - 1.2:1

Tape 4 - 1.1:1

Tape 5 - 1.2:1

However when I ran that routine using new tapes I only get 1:1 compression.  I have bought 30 new LTO4's and this happens with them all, yet the old tapes compress....

I'm baffled.

Moe Howard's picture

Out of curiosity...what's the brand of the new and old tapes?

Also, please post the .bin files when you get a chance. I'd like to see the sequence of commands when using an old and new tape.

MichaelMoran's picture

They are all HP Ultrium LTO4's....  Will attempt .bin files this afternoon.

MichaelMoran's picture

See attached tracer.zip file for old.bin and new.bin

AttachmentSize
tracer.zip 9.58 KB
Moe Howard's picture

Thanks for capturing the information.

I've looked at both logs and have good news and bad news. I'll explain in general terms first then go in to more detail later on.

The good news is that BE is issuing the same sequence of commands pertaining to DCE (Data Compression Enable), regardless that old or new media is in the drive. In other words it's turning compression on when it's supposed to before data start writing to tape.

The bad news is that you are obviously not getting compression with the new media. For this exercise...if you backed up the same exact data for the old.bin and new.bin traces and only swapped the media (old and new) then I can only conclude the new media may be faulty.

Below is a detailed explanation of the sequence of commands for each trace. Bear in mind I only honed in on the areas relative to enable/disable data compression and data being written to the tape. Hopefully this will provide you with a better understanding of what is going on behind the scenes when a backup runs.

OLD.BIN

Event 314

BE issues MODE_SENSE6 to check the condition of DCE. Compression on the tape drive is off as indicated by the hex value 40h in bold.

Data
13 00 10 00 0F 0E 40 80 00 00 00 01 00 00 00 01

Event 315

BE issues MODE_SELECT6 to request DCE is turned on as indicated by the hex value C0h in bold.

Data
00 00 10 00 0F 0E C0 80 00 00 00 01 00 00 00 01

Event 318

BE issues MODE_SENSE6 to verify DCE=1 (on)...and it is.

Data
13 00 10 00 0F 0E C0 80 00 00 00 01 00 00 00 01

Event 323

BE Issues the first WRITE6 (data starts writing to tape)

Event 341

The last WRITE6 is issued  (no more data to write to tape)

Event 344

BE issues MODE_SENSE6 to verify data compression is still a true condition. It's the same data return as Event 318 before data started writing to the tape.

Data
13 00 10 00 0F 0E C0 80 00 00 00 01 00 00 00 01

Event 345

BE issues MODE_SELECT6 to request DCE is turned off, to put the tape drive back in to the condition is was before the backup started.

Data
00 00 10 00 0F 0E 40 80 00 00 00 01 00 00 00 01

Event 348

BE issues MODE_SENSE6 to verify DCE=0 (off)...and compression is indeed turned off.

Data
13 00 10 00 0F 0E C0 80 00 00 00 01 00 00 00 01

NEW.BIN

Event 417

BE issues MODE_SENSE6 to check the condition of DCE. Compression on the tape drive is off as indicated by the hex value 40h in bold.

Data
13 00 10 00 0F 0E 40 80 00 00 00 01 00 00 00 01

Event 418

BE issues MODE_SELECT6 to request DCE is turned on as indicated by the hex value C0h in bold.

Data
00 00 10 00 0F 0E C0 80 00 00 00 01 00 00 00 01

Event 421

BE issues MODE_SENSE6 to verify DCE=1 (on)...and it is.

Data
13 00 10 00 0F 0E C0 80 00 00 00 01 00 00 00 01

Event 426

BE Issues the first WRITE6 (data starts writing to tape)

Event 444

The last WRITE6 is issued  (no more data to write to tape)

Event 447

BE issues MODE_SENSE6 to verify data compression is still a true condition. It's the same data return as Event 318 before data started writing to the tape.

Data
13 00 10 00 0F 0E C0 80 00 00 00 01 00 00 00 01

Event 448

BE issues MODE_SELECT6 to request DCE is turned off, to put the tape drive back in to the condition is was before the backup started.

Data
00 00 10 00 0F 0E 40 80 00 00 00 01 00 00 00 01

Event 451

BE issues MODE_SENSE6 to verify DCE=0 (off)...and compression is indeed turned off.

Data
13 00 10 00 0F 0E C0 80 00 00 00 01 00 00 00 01

For your convenience, I took the liberty to pipe the .bin files to text format so that you could easily read the events I've pasted above in greater detail. They are old.txt & new.txt respectively. Let me know what your thoughts are about my findings.

AttachmentSize
old.txt 302.7 KB
new.txt 392.02 KB
pkh's picture

The simple test I proposed earlier would have arrived at the same conclusion

MichaelMoran's picture

Thanks for both of your help.

So this conclusion indicates that every single LTO4 I have bought over the past 2 months is faulty?

I have purchased over 40 tapes as I want to swap out last years ones and have used almost 20 of them for these tests.  None of them are giving compression.  Seems a little far fetched to suggest that they're all faulty surely?

pkh's picture

It is definitely not BE's fault.

MichaelMoran's picture

Well I've ordered 5 quantum branded tapes to do a test with.  They should be here tomorrow.

Moe Howard's picture

Michael,

I agree this seems to be a bit strange that all of your new tapes are not providing compression but at least we've proved BE is doing the right thing behind the scenes. It's curious to know whether the Quantum tapes will solve the problem.

MichaelMoran's picture

Ok, I've just ran the exact same, 3 text file backup using a new quantum tape rather than the usual HP ones.  Attached is quantum.bin (in a .zip file).

Looking at the tracer results with my untrained eye, it doesn't appear to be giving any different of a result to a new HP tape.  Am I correct?

If this is the case, could backupexec be 'tagging' the tapes as uncompressionable somehow?  Would it be worth me erasing every new tape using backup exec or some other tool?

AttachmentSize
quantum.zip 5.86 KB
MichaelMoran's picture

Anyone got any ideas?

Using Backup Exec

Tests with old tapes result in compression.

Tests with 20+ new tapes, both HP and Quantum brand get no compression.

Using HP LTT

Compression tests pass on both old and new tapes.

CraigV's picture

Hi Michael,

Did you perhaps try to erase the tape using HP LTT? If not, do so and then report back.

If you have then I'd recommend opening a support query with both Symantec and HP (to definitely rule out possible hardware issues).

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

MichaelMoran's picture

I didn't.  I'll do that now and test the same 3 text files with both the HP and Quantum tapes

MichaelMoran's picture

Same result after erasing using the HP LTT as when they were brand new out of the box....

CraigV's picture

...might be time to log those 2 support calls then, and update the query once you've been assisted.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...