Showing results for 
Search instead for 
Did you mean: 

Same problem here

Same problem here guys.

Someone know when Symantec plan to solve it? It's a big issue that compromise all the company backup strategy

Us too

We too are having the same issue! Waiting for an update/fix

Us too

We too are having the same issue! Waiting for an update/fix. Sorry not sure why it duplicated my message

Hi, we are having the same

Hi, we are having the same issue this week. 


Is it possible to set a full backup with GRT and incremental without in Backup Exec 2012. 

Can anyone confirm if this is working as instructed by Colin Weaver here:


Back to your original problem.

Symantec are aware of an issue where the updating catalogs phase can take extended periods to run and are working to try an minimize the effect.
In the meantime the options are run your Exchange Full backups slightly more often (which you already know works from your accidental fix) or setup your Incremental template with GRT not enabled - but leave GRT enabled on the full template and then make sure that your Exchange deleted message retention (Microsoft setting not a Backup Exec setting) is longer than the interval between your full backups so that your restore options are
1) Use the full set with GRT
2) Use the Outlook mechanism, to restore deleted message for the incremental dates
3) Use an RSG process if the above 2 options can't be used
4) Just restore the full and incrementals without using Granular Recovery if you have a disaster that affects the whole server.

Still no update from

Still no update from Symantec.

Latest update not working either.

Will keep updating as soon as I have an update.

I solved my issue (at least

I solved my issue (at least for now). For the past few weeks I did not tuch the backup exec. Everything is backing up smoothly. 


First I defragmented the mail database since it had 50% white space.

The support team advised me to take the following steps in reagrds to the Backup Exec and Exchange 2010:


- full backup should be scheduled every week

- incremental backup throughout the week (every day currently)

- system state and Microsoft information store should be run in separate jobs and should not overlap

- full and incremental backup should be targeted on the same storage 

- in Backup Exec under 'Advanced Open File' - everythins switched off

- under 'Microsoft Exchange' - everything switched on

- install EMC on BE Server

- the circular logging for the databases should be disabled 

- maintenance for exchange databases should run at a different schedule from the Backup Exec jobs


Hope this helps anyone.

I just face with same

I just face with same issue.

VMware backup using SAN connection to Dedupe storage.

The guest is file server with 1.2TB sized and many files in it.

The backup is still updating catalog more than one days.

I just cancel it but it's still updating catalog and status is cancel pending.


Same issue here after

Same issue here after installing latest hot fixes except we're still on BE2010. Full Exchange backup at the weekend backed up 65GB @ 908MB/min. Incremental backup last night backed up just 1.7GB at 9MB/min. It's always the incremental backups that sit at the updating catalogs prompt for hours & hours.

Counting down the days until our new non-Symantec backup system goes live...


Accepted Solution!

We finaly have a temporary

We finaly have a temporary solution from Symantec.

It seems that there is a problem with a dll (pdvfsprotocol.dll) they installed a new dll and now the speed is to an acceptable 3.5GB/min backup to de-dupe (still not the 6GB/min I used to have but a lot better) They said they are still finalising the dll for general public and I'm not allowed to install any Symantec updates untill they bring out the final update and contact me again.

So for anyone out there with this issue I would advise to create a ticket with Symantec and let it roll from there.

Lets hope the final fix takes it back to original speeds and it won't take to long to get it.

Hope the rest of you get there as well.


View solution in original post

I am experiencing the exact

I am experiencing the exact same issue.


Any word on when this fix will be included an update?




Hi, Same issue here! did


Same issue here! did anyone get the fix?


Carlos Franco

HI, We are also experiencing


We are also experiencing this exact issue (extremely slow "updating catalogs" on GRT based backups on fileservers).

Are there any news of availability of this hotfix or who to contact to get the updated DLL?


Mikkel Andreasen

Hello, We need a solution


We need a solution from Symantec. 

now We are reinstalling VMware tools and Symantec Agent, then we´ll try to do backup job again. 

let's see what happen.. 

please, if anyone have a solution let my know. 

thanls in advance,



Addendum for other users

Addendum for other users experiencing slow backups.

I have noticed slow backups with BE2010sp3 combined with (backups of) servers with databases (SQL, Exchange) and/or Active Directory, usually in combination with deduplication. After a long analysis, logging and such, I noticed that the BE server had rather long wait periods, in which it would wait for responses from the client. Some further googling led me to the culprit: Microsoft Forefront Endpoint Protection. You would expect them to know how to get the exclusions right on their own anti virus software, but forget it. The on-access scan engine slows backups to a crawl. 

The following article finally put me on the right path:


Add the following exclusions to your antivirus. I found that it works for FEP, but it might well also work for Sophos, NOD32, Norman, Panda, F-Secure, Kaspersky, Symantec and others. 

Add Low Risk Processes policies and exclusions for Backup Exec.

Step 1 - Add exclusions to AV on your Backup Exec Server

  1. Open your antivirus scanner and go to the Exclusions part of the settings.
  2. Add exclusions for the following processes:

    C:\Program Files\Symantec\Backup Exec\beremote.exe 
    C:\Program Files\Symantec\Backup Exec\beserver.exe 
    C:\Program Files\Symantec\Backup Exec\bengine.exe 
    C:\Program Files\Symantec\Backup Exec\benetns.exe  
    C:\Program Files\Symantec\Backup Exec\pvlsvr.exe 
    C:\Program Files\Symantec\Backup Exec\BkUpexec.exe

    NOTE: Change the path as appropriate, depending on which root volume the Media Server or Remote Agent has been installed to.

Step 2 - Exclude Backup Exec paths from scanning

  1. Open your antivirus scanner and add the following path to the Exclusions (including subfolders):

    C:\Program Files\Symantec\Backup Exec\
    C:\Program Files (x86)\Symantec\Backup Exec\

When configuring your settings, keep your eye open for other settings that could complement the exclusions. For example, McAfee has an option to ignore files that are opened for backup.

Step 3 - Add exclusions based on the used product

Active Directory, Exchange, SQL - they all have their own required exclusions. Configure these exclusions using the following articles:

Once you've set these, there's a good chance things will improve drastically.

Symantec, you would do well to make a dedicated article explaining what exclusions to add - not just for your own products, but also other products that BackupExec has to work with. 

I also have McAfee and my

I also have McAfee and my google searches lead me to the same KB articule. I would not know if that solved the problem as I also did a clean installation on my backup media and afterwards I finally got the backup jobs running well again.


Tried the AV exceptions

Tried the AV exceptions (Avira), but to no avail :(



  In our case, antivirus is


In our case, antivirus is fully disabled.

Deduplication backup’s delays more than 48 hours, the same backups to normal disk or tape takes no more than 10 hous.

Symantec recommended me to disable GRT ( but what we really need is to have fast restore from disk.

Hope to have a solution soon!


Any help?

Hi csotoc,   we've had the

Hi csotoc,


we've had the same problem and gave up after 5 month of timewasting with symantecsupport.

They all tried to explain, that slow duplicate FROM a dedup folder or restore from the same folder is not a problem - it's the way it's designed.

I've got the impression that Symantec is no longer recommending dedup storage as a primary backuptarget - only as the second or third stage.


So we changed back to 1. stage backup2disk and we are duplicating from there to tape or other external media.


I'm totally disappointed from the quality of the dedup and even more from the support.