Backup Exec 2012 not compressing LT05 Tapes

[JordanCSH]

Hi,

I have recently installed Backup Exec 2012 on two of my media servers and I have come across an issue when trying to compress data onto LT05 tapes. 

My backups are structured to complete a full backup every evening of the local media server and then 4 remote machines are selected to include into this backup also. I want to back up all these servers onto one tape and I realise in BE2012 you have to create seperate jobs to run over one tape and you cant put them all into one job like you where able to in 2010.

So my first job of the evening is set to overwrite and then each job following is set to append. 

I can see the compression rate is set to 1.0:1 which I dont think is right. The compression on each of the jobs is set to hardware and then software if no hardware is available. 

These jobs have now been imported from BE2010 and have been set up from scratch when the software was installed.

Any help would be great.

Thank you

[Ken_Putnam]

but this doesnt really help me I wont get enough compression required out of the LT05 tape.

While HW and SW compression aren't identical, they ARE very close, so as a work-around, you should be able to use SW compression for now

[digone52]

We are using LTO4 tapes.

Definately DO have "Hardware if available otherwise none" selected, and the tape switches after 745GB of backup - i.e. there is definately no compression.

[Moe_Howard]

It's worth noting that the trigger is setting the job's compresison method to hardware else software.  Leaving it at the defualt o hardware else none enabled the DCE (Data Compression Enable) bit set to true.

Before the data starts writing to the tape instead of seeing this:

--------------------------------------------------------------------------------
Event: 262 Start: 15:48:33.637 Stop: 15:48:33.641 Duration: 0.003906
SCSI Address: 05:00:03:00
Function SRB_FUNCTION_EXECUTE_SCSI
SCSI Status SCSISTAT_GOOD
Sense Length 0
Data Length 20
Driver Result STATUS_SUCCESS

Raw CDB
15 10 00 00 14 00 ......

CDB Operation MODE_SELECT6
LUN 0
PF True
SP False
Parameter List Length 20
Control 0x00
Data
00 00 10 00 0F 0E 40 80 00 00 00 01 00 00 00 01 ......@.........
00 00 00 00

You will see this:

--------------------------------------------------------------------------------
Event: 262 Start: 15:48:33.637 Stop: 15:48:33.641 Duration: 0.003906
SCSI Address: 05:00:03:00
Function SRB_FUNCTION_EXECUTE_SCSI
SCSI Status SCSISTAT_GOOD
Sense Length 0
Data Length 20
Driver Result STATUS_SUCCESS

Raw CDB
15 10 00 00 14 00 ......

CDB Operation MODE_SELECT6
LUN 0
PF True
SP False
Parameter List Length 20
Control 0x00
Data
00 00 10 00 0F 0E C0 80 00 00 00 01 00 00 00 01 ......@.........
00 00 00 00

Take note of the C0 instead of 40.

Hope this helps...

[Colin_Weaver]

As well as my presvious update abouth the two known issues, anyone who continues to think compression is not working should also review (which has been mentioend previously in this thread)

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

And if both the mode_select6 and mode_sense6 commands do show the 7th byte setting compression then you are either backing up data that can't be compressed, or your hardware vendor may need to look at the problem

[Bross]

I have been fighting with Symantec tech support for days trying to resolve the same issue.  Again last night the 2nd level tech support sent me back saying it was a hardware issue.  Today, she finally concurs it is an issue and needs to be passed up the chain.

My tracer output confirms what was posted earlier in the difference in values for the 7th byte based on the compression setting in the job.  For hardware then software it is a 40.  For hardware then none it is a C0.  My test job shows I have a 1:1 compression ratio, but the amount of space on the tape used for a 2GB text file of 0's is 45MB with hardware only instead of the 3.6GB it was doing with hardware than software.

I am going to edit all my jobs to use hardware only and hopefully stop using a ton of tapes.  If it still won't compress reliably I have no choice but to uninstall.

I would recommend holding off on the upgrade unitl Symantec gets this resolved if you still use tapes as part of yoru backup strategy.

[John_Lanka]

Bross - If you need help escalating this issue - please send me an email and I will do whatever I can.

[digone52]

I ran a trace yesterday on a job for hardware compression only and hardware then software encryption, and I definately got a C0 in the mode select data in the correct field.

When a full backup runs, it is definately not compressing whereas before it did on 2010 R3.

I have checked firmware on drive and library - the drive was up-to-date, but I have updated the library, although I can't see how this could affect?

I have also added a driver for the library under Windows which was missing before, but Backup Exec was absolutely happy without this driver previously.

As I got a C0 in the correct place during a small test, I suppose it will be safe to do a trace at the start of our weekend backups to see if there is something related to the job, as that's where I notice the failure?

As an aside, and this was sort of mentioned above, while I can see advantages in the new paradigm of a server centric world, if I want to make a change to the full backups throughout, I now need to edit about 15 jobs instead of one, which is a pain, but unless I'm missing something (and I hope that I am), the real problem for me with Backup Exec 2012 is the more restrictive schedule. On BE 2010 my full backup jobs did a monthly encrypted backup on the first Friday of the month (easy to schedule in BE 2012), but then do a weekly backup on every other Friday. This involves too much complexity to acheive, although possible, as I believe this involves setting up individual  full weekend backup jobs per server for the 2nd, 3rd, 4th, 5th Fridays, so we go from defining 1 backup job to about 60.

[Bross]

I ran my incremental jobs last night to tape to test the hardware then none option.  The tape media continues to report a 1:1 compression ratio, but if I compare the amount of data backed up in the jobs with the actual amount of data written to the tape, I am seeing the data is being compressed.  The compression ratios do not seem as high as I was getting with the older versions, but that may just be an anomaly with the current data set. I was seeing a high of 1.32:1 compression ratio with the current version, where I was getting 2:1 with previous versions of Backup Exec.  I'll have to see what I get with a full backup this weekend.

I did get an updated note from Symantec Tech Support that stated the case has been escalated.

[Colin_Weaver]

Just to clarify the TECH article content  

You need to see the correct 7th byte settinsg on both a MODE_SELECT6 command (which is the command to enable compression being sent), and the MODE_SENSE6 command (which verifies it is set)

Also looks like (pending more testing) that Bross has just comfirmed he is seeing the GUI displaying incorrect information  which we have aknwowledged is one of the known problems.

[Bross]

After changing all my jobs to use hardware and then none for the comrepssion type, I ran my full backups this weekend.  As I watched the jobs throughout the weekend, I was glad to see it used only 16 full and 4 partial LTO-3 tapes instead of the 25 and 4 it was using after the upgrade to BE 2012 and before I made the change to hardware then none.  The home tab dashboard shows I backed up 9.84TB.  Considering I used only 6.24TB of tape capacity, that gives me a compression ratio of 1.58:1.

Of course, BE 2012 still says I only got a 1:1 compression ratio, but I would imagine that is the 2nd bug mentioned above.  It is purely my conjecture, but it seems as if BE is using the amount of data written to tape instead of the amount of data read from the source device to determine the divisor in the ratio.

Thanks to all who helpd shed light on the issue with the MODE commands.  I needed that to convince Symantec tech support that it was a BE issue and not one with the hardware.

On a side note, I think I found some additional, but unrelated "bugs" that I'll need to research further.

[Gace]

Im having the same issues, im running BE 2010 R3 with HP LTO Ultrium 4. When i backup testfile.txt compression works. When i backup Word files compression fails.

I have check hardware compression is on, and set hardware compression only on BE.

I have updated my firmware on my HP drive, called HP Support. Got them to replace my drive. Still no go.

Called Symantec, been trying to troubleshoot the issues for weeks.

Need HELP 

[SuperBrain]

If you're facing one of these issues, subscribe to the articles and Symantec will keep you updated on these issues:

http://www.symantec.com/docs/TECH189476 - Compression to tape is disabled when the option 'Hardware (if available, otherwise software)' is selected in the backup job's Compression settings in Backup Exec 2012

http://www.symantec.com/docs/TECH189307 - Backup Exec 2012 incorrectly reports a compression ratio of 1:1 (or 1.0) in the GUI when compression is working correctly.

To subscribe click on the 'Subscribe via email' link on the top right corner of the article.

[Rick_Okla]

Upgraded from BE 2010 and started having the same issue as most here, the cpmpression is enabled for the drive, the management console showed compression enabled, then a few days later, the compression was disabled even thought BE shows enabled.  we replaced the tape drive since the dell eng thought it was a hardware issue, but after running tests again, the compression was not enabling. 

[Biker_Dude]

When Backup Exec services start, BE issues a MODE_SELECT command to disabled the DCE (Data Compression Enable) bit on the tape drives, which support hardware compression.  When a backup job configured to use hardware compression starts, the same SCSI command will enable the DCE bit.  When the backup completes, the DCE bit will be disabled.  This behavior is from the days of old when most tape drives did not support hardware compression...hence the default for disabling the DCE bit.

There is a known issue with BE2012 where hardware compression is not being enabled if the compression method for the backup job is hardware else software.  If it's set to hardware else none (default) then hardware compression is enabled.

I suspect when you looked at the drive from the management console, the BE services were not running, which means the DCE bit was set to on.  When you noticed it was disabled, I'll be the BE services were running AND there were no backups running.  Hardware compression was shown to be supported because BE determines that when it discovers the device via the MODE_SENSE command.

I feel you are running in to the known issue with BE2012.  The workaround is to configure your jobs with the compression method set to hardware else none and you'll start getting compression.  You may run in to a second issue, which is cosmetic.  If you see 1:1 compression appearing in the UI, this is a GUI issue.  If you have data that is known to compress then compare the data backed up to the data written to tape and you should be able to determine the compression ratio.

[CraigV]

Biker_Dude: Does SP1a resolve this issue? If so, the OP and all other guys should be advised to upgrade to that to fix their problem!

[Rick_Okla]

SP1a was released, installed the fix, rebooted server, checked all options again, Hardware compression only, ran a backup with trace.exe watching, and it didn't change any compression settings through out the job.  It's still doesn't work.  I'm going back to 2010 since it works.

[Sush---]

No. SP1a does not resolve this issue about compression. Please check the SP1a release notes to confirm the same.

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

Backup Exec 2012 revision 1798 Service Pack 1a Release notes

Thanks,

-Sush...

[RBT510]

I am running BE 2010 R3,(Ver 13.0 Rev 5204)

If I introduce a new tape to the media set, it will not compress at all, and is less than 1:1 in fact.

Have tried all the options mentioned about with no difference.

Has anyone seen this and have been able to correct it?

[Sys2]

A month ago since last post in this threat i wonder what the status of this issue is.

No need to say I suffer from this issue as well. No need to say a lot of other rather unfriendly things, but still (very much annoyed), just that you know:

Migration from BE2010 to BE 2012 turned so much into a disaster that last week I removed all, uninstalled and started with a fresh install and recreated all jobs (for the second time). I would have turned back to version 2010, if my (new) licenses were compatible with that version. Wtf, license not compatible with previous version. It should have been made compatible. With renewing my licenses I didn't have any choice but to migrate.

Some of the problems I encountered after migration:

- Migration of jobs was a mess. Some (but not all) differential backups turned into full backups. As a result backup to disk completely flooded my harddisk(s).

- Buggy interface not capable of showing long lists of backup sets

- At some point all of my jobs disappeared. But not really. Creating new jobs with same names gave me an error that that job already existed. But I couldn't find it anywhere, so no way to view or edit them. (https://www-secure.symantec.com/connect/issues/jobs-disappeared-be-2012-console-and-warning-noticed-towards-bottom-left-hand-corner-console-)

Those three problems seem to be under control after complete uninstall / re-install.

I will not complain for long about the GUI, which in my opinion is a big step backward. Very user unfriendly if you ask me.

Let me finnish with two question to Symantec (not that I expect any serious answer): Do you have any idea how much trouble you caused by releasing a product that was not nearly thoroughly enough tested ? This is not what I would expect from a company like Symantec, and as we speek I am already looking for alternatives, for this really is not the way to go about things.

Second: Why BE 2012 (and the choices that have been made) ? What has improved ? Why should any company choose BE 2012 over BE2010 (or any other product) ?

Just needed to get this major annoyance out of my system.

Sys@dmin

[CraigV]

1. I think they do realise how much trouble was caused...there is a VERY long discussion around this on the forums. Check it out. They have also had sessions to chat to backup admins around this and seem to be making some steps towards fixing a lot of the issues. Check out the forum for the Beta announcement, or PM James McKey.

2. As per above, check out the Beta for BE 2012 R2. Some people like BE 2012, others don't. Like I said to the person doing the usability study, people used to how BE used to work would struggle, while people new to the software would have no prior experience, and would get used to it a lot easier.

Thanks!