cancel
Showing results for 
Search instead for 
Did you mean: 

HF 14 speed issue *consolidated thread*

Allen_K
Level 6
We will be consolidating all the speed issues created by HF 14 into this thread.
 
We ask for your help. 
  • First, when posting on this issue, please place the post in this thread.
  • Second, If you locate an existing thread, or have previously posted on this issue, please click the 'report abuse to moderator' link anywhere in that thread and flag it as a 'HF14 Speed thread' so that we can move those posts to this thread. 

 



Message Edited by LakeRat on 09-11-2007 03:27 PM
16 REPLIES 16

Gunther_Vanwael
Level 3
 
Our jobs are configured to backup directly to tape and have the same issue.
 
Openend a ticket 2 weeks ago to investigate and we have also started an escalation for the case so workaround mentioned in the document is not working as we had the issue with backups directly to tape and it is also occuring with small databaes. Our backups are running +17hours to backup 115Gb.
 
Is this really a screenshot from 11d Rev. 7170 in the document?
 
Regards

Scott_Straub
Level 4
I have a 16 gb Exchange store that takes 15 minutes to backup to disk and 17 hours to backup to tape (duplicate job).

I don't think that qualifies as a "large" information store.

Alex_Pooley
Level 3
I take it this problem is still outstanding?  I am a bit stuck now, if I backup my exchnage data direct to tape it messes up the state of the VSS Writer as per https://forums.symantec.com/syment/board/message?board.id=115&thread.id=11921 and now if I back it up to disk then tape it takes all night to duplicate 15Gb to tape! 

Gunther_Vanwael
Level 3
Hello all,
 
I have provided a lot of info to Symantec, worked together and pushed to have it solved. I have received orphan files to test and the results were good. Pre-processing and time between the snapshots when writing to disk are not loosing time anymore. The backups were very fast and did not run for more than 17hours anymore.
We are not using the orphan files at it is not supported, we are waiting for the official fix.
They are doing final tests and they hope to release the files with hotfix 22.
 
Regards,
 
 

Gunther_Vanwael
Level 3
small correction -> Writing to TAPE

usn_ncdoc
Level 2
This thread has a few issues going on in it...
 
Speed of the duplicate to tape
Duplicate to tape never finishes
 
Any news on either of these?

Allen_K
Level 6
Please note that this is a peer-to-peer discussion forum and not technical support.

Usually customers come to the rescue. Other times, when they are available, a Symantec employee will volunteer his/her time to find and help solve issues just like any other member of the community.

However, in this case, it looks like you might be better off contacting Symantec Support Services for 24/7 access to technical support professionals. You can also try using our Knowledge Base Search.

Hope that helps!

usn_ncdoc
Level 2
Well it's apparent that this is a KNOWN issue and has been such for awhile now. So what is contacting suppport services going to do for anyone at this point other than justify some level 1 tech's job? I was asking if there was any news from the OTHER people that have posted in the various treads concerning this. Why have this thread if we can't ask for assistance in it?

Gunther_Vanwael
Level 3
Hello @,
 
Hotfix 22 is now available and should fix the issue.
 
We still need to implement this fix on our environment to test but the tests with the orphan files were successfull and reduced the backup timewindow drastically .
 
Here you have the links :
 
For the 32-bit version of hotfix 22:
http://support.veritas.com/docs/292781
 
 
For the 64-bit version of hotfix 22:
http://support.veritas.com/docs/292782
 
Regards

Alex_Pooley
Level 3
Thanks Gunther, I have applied this to the media server and also updated the agent on the Exchange servers so we'll see how it goes tonight!

Alex_Pooley
Level 3
I applied the update and now have the problem as found by another user in this thread...
 

Gunther_Vanwael
Level 3
We have planned to perform some tests today. I have asked Symantec to keep our case open.
 
If we encounter also this issus after applying HF22, we will inform Symantec about that.
 
Regards,
Gunther
 

Gunther_Vanwael
Level 3
We have the same issue reported by Alex Pooley.
 
I have informed Symantec and have asked to have a look asap as we will escalate it on very high level.
 
This is unaccepable!!
 
The tests with the orphan files were ok and we had some hope. Now they combined the fix with other fixes and now the result is much worse that the original problem.
 
Gunther

Jeff1981
Level 4
Using Exchange 2003, Hotfix 22 finally does what it promises: duplication of the Information Store goes at expected speeds of over 1 GB/min. However, since we're planning to upgrade to Exchange 2007 next month, we're very worried about the findings described above... we knew SOMEthing had to be wrong with this hotfix (pardon the pun)

Gunther_Vanwael
Level 3
I think it is safer to postpone your upgrade.
 
There is something wrong with the Exchange2007ServerComponent (BEExch2007Component.dll) when upgrading to HF22.
 
Found this in the SGMon log :
 
BEREMOTE: [10/16/07 11:37:34] [1296] Managed Dll Name is Exchange2007.Exchange2007ServerComponent, BEExch2007Component, Version=11.0.7170, Culture=neutral, PublicKeyToken=34de206216e19b30
BEREMOTE: [10/16/07 11:37:34] [1296] Could not init Exchange2007ServerComponent
 
Symantec is checking for the root cause.
 
Gunther

JRink
Level 3
Interesting.
 
I just installed two new installations at clients within the last week.  I've been finding B2D and D2T backups since then.  I found this thread while on the phone with Symantec tech support.  I've now updated my servers with Hotfix22 (which for some reason is NOT yet available via LiveUpdate) and will check tonight to see if the problem still persists.
 
I was experiencing slowness on the D2T backups and repeated crashes of the beremote.exe on the media server.  I'll report back with how things work over the weekend.
 
FWIW, tech support on my call was very good and they acknowledged the problem right away.  My case is still opened until I see the result (Exchange 2003).
 
JR