Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Backup Exec 2012 not compressing LT05 Tapes

Created: 04 May 2012 • Updated: 18 Jul 2012 | 42 comments
This issue has been solved. See solution.

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

Comments 42 CommentsJump to latest comment

CraigV's picture

Hi Jordan,

Check that the tape drive has Compression enabled on it within BE. If it is a library/autoloader, log onto the web front-end and then make sure compression is enabled there too.

Thanks!

Alternative ways to access Backup Exec Technical Support:

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

JordanCSH's picture

Sorry if im being a bit new ive had a look through and cant see where i would check if this enabled. I can see I have set it in the job is there any where else to check?

 

I have checked the tabe drive itsself outside of BE and compression is enabled here.

 

Thanks,

Sush...'s picture

In BE 2012 console go to Storage tab and go to the details of the Tape drive (under Robotic Library) and then in the Properties screen you will see the option of Compression. Ensure that Compression is enabled.

 

Thanks,

-Sush...

Hope this piece of Information Helps you... and if it does then mark this response as Solution....!!!

JordanCSH's picture

Apologies I have found it and it is set to enebled. 

JordanCSH's picture

Hi Sush,

That is all set to enabled and correct.

Thanks,

Jord

Larry Fine's picture

Is the data compressible?  What type of data is it?

 

Does your job log show that compression was used/enabled?

Backup started on 5/2/2012 at 4:16:03 PM.
Backup completed on 5/2/2012 at 4:31:37 PM.
Backup Set Summary
Backed up 10 files in 2 directories.
Processed 10,737,420,400 bytes in  15 minutes and  34 seconds.
Throughput rate: 658 MB/min
Compression Type: Hardware

 

this should help with further troubleshooting

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

If you find this is a solution for the thread, please mark it as such.

pkh's picture

If you suspect that there is something wrong with your hardware compression, use software compression instead.  The compression ratio for the same set of data for both hardware and software compression should be about the same.

Towing's picture

I am also having the same problems.

I upgraded from BE 2010 and immediately disliked the new interface.  Too maany clicks to get to the same information, and it is spreadout over too many screens. Give me back th job view screen, but I digress....

I am using two LTO3 Ultrim 960 tape drives.  With BE 2010 and before I was getting compression ratios of 2.1:1 and 1.6:1 on the drives, because of the types of data being backed up, and only using one tape per drive per night.  Since the upgrade to BE 2012 I am unable to get anything other than 1:1, and the backups are running to more than 1 tape per drive.

I re-created all of the backup jobs from scratch to fit the new paradigm.  I have set the compression to in the job to "Hardware (if available otherwise software)" and checked the Compression option within the device and set to Enabled and applied the setting.

I have checked, and the tape drives are running the current firmware, and the HP Tape Tools tell me that the compression is working using their tests. Still no joy.

I have placed a call with Symantec support to see if they can help resolve the problem.  They suggested that I contact HP to see if they know why, but the engineer I spoke to agreed with me that as the only change was the upgrade to BE2012, that is more than likely the problem.

I am going to try software compression tonight to see if this helps, but I would prefer to use the hardware option

If I get a resolution I will let you know.

Towing's picture

After doing the testing in the cocument given by Larry Fine (Thanks for this) I have determined that even though the Job is set to "Hardware Compression" and the tape device has the compression "Enabled" on it, the tape drive is being set with the compression to Off

This was taken from the Tracer log.  It is the last Mode_Select6 prior to the writing starting.  There is a Mode_Sense6 after this one that confirms the settings

--------------------------------------------------------------------------------
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                                     ....

According to the document, the value of 40 I have highlighted is compression disabled.  This appears about 6 times through the log, and they are all the same.  The value should be 80 or C0 for compression to be on.

After discussing this witht he support tech, some other logs have been gathered and the case has been referred to a higher level support tech.  I will keep you informed.

JordanCSH's picture

Thank you,

 

Towing I have exactly the same issue as yourself as for the tracer and compression being set correctly but the job being sent with no compression switches.

I have also logged this with support and If I receive any further information I will let you know.

Thanks,

MagnarE's picture

Started after upgrading to BE 2012 from BE 2010. I am using one LTO3 Ultrim 960 tape drives and one LT05 Ultrium 3000 drives.

JordanCSH's picture

Just a quick update.

I have spent alot of today on the telephone to support with Symantec but dont seem to be making any progress. All of the Tracers have completed and we can see the commands are not there for data compression to the tape drive.

I have two tape drives of different models connected to two different servers both running backup exec 2012 and have the same issue on both.

Interestingly the compression when selected software only worked last night for one of the backups but this doesnt really help me I wont get enough compression required out of the LT05 tape.

I have spoken to my hardware vendor for the tape drives who has advised they have the latest firmware updates and there are no issues with the tape drives. I do understand what Symantec are advising that backup exec doesnt handle the hardware compression this is all completed by the tape device itsself. But i feel it may get to the point where i downgrade the licences on the server and re-install backup Exec 2010 and I believe i wont have this issue.

Jordan

CraigV's picture

...and if you do that and it works, you need to raise that with support!

Alternative ways to access Backup Exec Technical Support:

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

Ken Putnam's picture

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

 

If this response answers your concern, please mark it as a "solution"

Towing's picture

I have just heard from Symantec support.

This issue has been raised as a defect and forwarded to the Engineering team.

A technote will be issued soon hopefully by Monday.  When I have the reference I will post it here.

Hopefully we will have a hotfix patch released soon to fix the problem.

Judh's picture

I just upgraded a server to 2012 (Dat72 drive) and Compression went to 1:1
Hardware Compression was Enabled, Backup Job was set to Hardware (software if not available)
Recreated Jobs, Reinstalled from scratch, Updated all drivers and firmware, and Hardware Compression remained 1:1

Just set Backup job to Software Compression, and Compression seems to be working, and throughput on the job nearly doubled.

previous software, Backup Exec 2010, using Hardware Compression, getting 1.3 to 1.6:1 Compression using Hardware (software if hardware not available).

I imagine there have been bigger coincidences in the world than upgrading a software package and breaking something that has always worked, although I do know that new software sometimes is incompatible with old drivers *shrug*

Rod7424's picture

I've got the same problem after upgrade BEX 2010 r3 to BEX2012

I have a rebotic tape librairies, and there are the differents test :

1) only 1 full backup a server Windows Server 2008 x64 -> OK hardware compression (2:1)
2) full bakup only a windows server 2003 x64 -> OK hardware compression (2.2:1)
3) Full backup 2 servers one as a result of another without scheduled departure -> Compression hardware OK
4) Full Backup 2 servers one after the other with scheduled departure -> NOK Compression equipment

I supect the problem when the tape return on the slot and a other job begin directly without pause between each jobs   

Wath do you think ?

 

 

 

 

 

digone52's picture

Same issue.

Upgraded from 2010R3 to 2012. No hardware compression.

Is it worth phoning support, or is there a technote now / hotfix imminently? Don't want to bother phoning if I don't have to.

Ta.

JordanCSH's picture

You can try support you may get further than I did!

I havent had time to roll my version back to 2010 and test yet as its my sharepoint environment and would be out OOH downtime. 

Looking at this thread though it seems pretty oobvious all of these people cant have faulty Tape drives.......

If anyone does get anyway with support please let me know, and likewise I will post when I have rolled back to 2010 later on this week.

 

Jord

Colin Weaver's picture

As an update Symantec have found two conditions relating to compression in BE 2012

1) is Do not use the compression setting "Hardware if Available otherwise Software" which is already mentioned in this thread. We are working on a fix for this but for now use "Hardware if available otherwise none"

2) is the Admin console displays the compression as 1:1 - this appears to be a cosmetic/display issue a full backup of a known set of datat to tape as an overwrite and then compare byte count of data set with amount used on tape youw ill find compression has taken place. Agsin we are working on a solution to this.

Of course there may still be an unidentified cause out there so please log cases if the above information does not solve your issue

 

digone52's picture

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's picture

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's picture

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's picture

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's picture

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

digone52's picture

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's picture

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's picture

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's picture

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's picture

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's picture

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's picture

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's picture

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's picture

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!

Alternative ways to access Backup Exec Technical Support:

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

Sush...'s picture

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...

Hope this piece of Information Helps you... and if it does then mark this response as Solution....!!!

Rick_Okla's picture

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.

RBT510's picture

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?

Sys@dmin's picture

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/job...)

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's picture

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!

Alternative ways to access Backup Exec Technical Support:

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

Sys@dmin's picture

After seeing what at Symantec is viewed as "ready for release"-versions I'm no way interested in any beta. Just to afraid it will eat my system.

 

For other poor suckers who found this threat, looking for a solution to their issue ==>  Solution: https://www-secure.symantec.com/connect/forums/end...

Thanks for the link Sys - np

Sys@dmin

 

CraigV's picture

...OK then...

Alternative ways to access Backup Exec Technical Support:

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

Rick_Okla's picture

The latest Hot Fix Dated July 3 I believe, fixed this issue for my Dell PE124T.  Just in time because I was going to go back to BE2010

SOLUTION