Showing results for 
Search instead for 
Did you mean: 

Exchange 2010 Differential backup runs very slow when GRT is enabled and Destination Folder is on Dedupe


We have been running through this very slow backup problem on Exchange Differential for 6 weeks already. We are using Symantec Backup Exec 2010 R3 SP2 and Hotfix 180429 & 176937 installed. Our first setup was Weekly Full (GRT enabled) + Daily Differential (GRT Disabled) and it was running smoothly, the job rate of differential backup runs at 1,500MB/min and it completes successfully at about 15 minutes only. On July 29, 2012, we decided to create new backup templates for Exchange inside a policy so that we could also enable GRT on Differential. After we have successfully enabled GRT on Differential, we ran the Differential backup on July 2, 2012 and we observed a tremendous effect in job rate, it went down from 1,500MB/min to 22MB/min. In addition to this slow job rate, we are also experiencing a failure on our Wednesday(3rd day) differential backup with the following error message:



Backup- \\\Microsoft Information Store\DATABASE01
V-79-57344-759 - Unable to complete the operation for the selected resource using the specified opti...


Backup- \\\Microsoft Information Store\DATABASE02
V-79-57344-759 - Unable to complete the operation for the selected resource using the specified opti...



We have several discussions with Symantec engineers but we are still unable to fix this problem. If we look into the situation, we can easily solve the issue on job rate by just disabling the GRT feature but we would want to keep this as we are looking forward on using granular restore in the future.

We are stuck in this situation are any suggestions or recommendations that would solve the issue would be greatly appreciated. We hope to solve this very soon as we are already running through this problem for 6 weeks already.

Thanks in advance!

6 Replies

Hi,   Your VFF error was



Your VFF error was resolved by SP2 which you're already running...

Did you push-install your RAWS agent out to any remote servers after you upgraded to SP2?


EDIT: Also check:

Hi Craig, If we are now

Hi Craig,

If we are now running on SP2, then why are we still experiencing this VFF failure? We have also re-deployed the RAWS on the remote agent and we have also tried to restart both Backup media server and Exchange server.

With regards to the article TECH130046, we have already applied those steps and our Backup server is also running on 64-bit Windows Server 2008 R2 Standard with 12GB RAM.

Are there any other steps we need to take to resolve this VFF error and low job rate?



Harold: might be worth your

Harold: might be worth your while to check the Known Issues section above to see if anybody else is experiencing this issue after applying SP2. If so, click the button that alerts Symantec to someone else experiencing this issue.

Also, if you have a support contract in place with Symantec, open up a case with them around this. When/IF they help you in finding a solution, post back here...

I also take it that you're up-to-date with any patches subsequent to SP2?

Hi haroldadalia   Please




Hi Craig/TheResolver,   As of

Hi Craig/TheResolver,


As of now, we changed our destination folder from Dedupe to B2D storage and the Exchange differential backup is working fine now. The job rate is somehow much faster and we are not seeing the VFF error for now. As per Symantec engineer, they are still investigating on this and they have just developed another debugging fix that will allow them to gather logs deeper and would allow them to further investigate on this issue. 


Thanks for all your replies. I will reply back once the issue has finally get resolved on our end. Thanks!




We also have been

We also have been experiencing the same problem for the same amount of time.  Our Daily Diff had been running at an astounding rate until we upgraded to 2012.  Now we are seeing the exact same performance issues.  The only difference is I have been unable to convince Symantec that it is an issue they should look further into.

I would be very curious to konw if you've had any updates from Symantec regarding this issue.  I understand this thread is quite old but hoping someone has further information on the issue.