Backup Exec 2010 R2 and Sharepoint 2010 GRT backup to Tape says "Updating Catalogs"

[chuck_]

Hi Guys,

We recently upgraded to sharepoint 2010. And now we are having GRT backup issues only to tape.

The sharepoint backup to B2D takes 1hr 20 minutes for 150GB content database which is normal. The back to tape goes on for 5 to 6 hrs saying "updating Catalogs". It does not hang at Updating catalog like the symantec article mentions, but goes through the files really slowly  http://www.symantec.com/business/support/index?page=content&id=TECH68615 I end up cancelling the job.

The tape library driver are up to date symantec driver like they recommend.

My Backup Exec 2010 R2 media server is fully patched with SP1 and all hotfixes. My remote agents are up to date with version 13.0.4164.109.

Anybody know of a fix for this. Please help.

Kind Regards,

Charles

[ZeRoC00L]

Do you have this hotfix installed?

http://www.symantec.com/business/support/index?page=content&id=TECH155288

[chuck_]

Yes, Hotfix 148347 is installed. But still the same.

I've uninstalled and re-installed the remote agents on the sharepoint and slw servers too.

[btenney]

I am having the same issue and I am running the same versions. If anyone has been able to fix this, any help would be appreciated.

[ZeRoC00L]

BTenny:

You can try to install BE 2010R3:

https://www-secure.symantec.com/connect/blogs/get-new-backup-exec-version-ga-general-availability

If you register you can download it, and you will have all available updates for BE2010R2 directly installed.

And then give it another try.

[btenney]

I have a non-public hotfix installed for another problem regarding GRT duplicate jobs, so therefore I can't upgrade until the public fix becomes available. The orphan file was built for R2 and I am not going to risk using it on R3.

http://www.symantec.com/business/support/index?page=content&id=TECH155880

I will try reinstalling the remote agent and creating a new B2D folder, selection list, job policy for SharePoint and if that doesn't fix it, I will probably end up creating seperate backup jobs that go directly to tape instead of relying on duplicate jobs for SharePoint.

Edit: I just noticed that this fix has been included in R3. I will upgrade when I get the chance.

[Dataway]

Was it the first ever backup job which was going to disk? I assume its not deduplicating?

[Simon_B_]

You should really let the backup run through and see how long it takes to completely catalog the backup.

As the technote you've linked describes: NOTE: Because of the large increase in GRT items that restorable with 12.5, the 'updating catalogs' stage of a duplicate to tape or direct to tape backup may be significant.

Also look at these two technotes: http://www.symantec.com/business/support/index?page=content&id=TECH87326

http://www.symantec.com/business/support/index?page=content&id=TECH87518

The same should apply for all versions following 12.5. So best would be to just let the backup perform to get an idea how long it will take to do a complete backup to tape. After that you got 3 options:

• Disabling GRT for the Sharepoint backup
• Backup Sharepoint to a Backup 2 Disk folder instead of to tape
• Give BE the time it needs to build the catalogs from tape

[chuck_]

So i have a case open with symantec for almost two months. Still no update from symantec.

I've downloaded R3, but a little worried about upgrading. I have a dedup folder and i've heard that the upgrade affects the performance.

Has anybody upgraded to R3?

I was iniatially having issues with Sharepoint grt backup to tape, but now the same issue happens with B2D folders too.

A workaround i tried was to uninstall and reinstall the remote agent. I worked for a few days and went back.

Chuck_

[Sergey_Khalimov]

To improve "Updating Catalogs" performance, I've created the index:

USE [WSS_Content_InfoCentre]
GO
CREATE NONCLUSTERED INDEX [BE_AllDocs_IDDirDelTran]
ON [dbo].[AllDocs] ([SiteId],[DirName],[DeleteTransactionId])
INCLUDE ([WebId])
GO

[chuck_]

Ok, Went ahead with the upgrade to R3. The upgrade was sucessful.

Now my sharepoint\sql database grt backups take 6 hours to complete to my Dedup folder.

It used to take 2 hrs with MOSS 2007 and Backup exec 2010 R3. After upgrade to MOSS 2010, it would vary from 2 hr to 4 hrs. Mostly at the updating catalog stage.

Now with MOSS 2010 and Backup exec 2010 R3 it takes 6 hrs.

Anybody having similar issues? It could be a problem with my content database.

Chuck_

[Russ_Perry]

Hi Chuck,

When backing up Sharepoint content DBs to tape, the cataloging is done on the Sharepoint SQL server with the Remote Agent querying the content DB within SQL to enumerate the structure and content of that DB.  If it takes longer than what you get when backing up to disk, I'd recommend checking resource usage on the Sharepoint SQL server.  Backup Exec doesn't have a lot of control over issues in this area.

If you're seeing the 'updating catalogs' phase take a long time backing up to disk or dedup, then the culprit could be the complexity and number of objects contained within the content DB.  When the backup completes the database is browsed for structure (sites/subsites/document libraries/lists/etc.).  If there are a large number of objects and a complex structure this can take a long time.  There is presently a known issue being worked that should be fixed in a hotfix sometime soon.

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

Russ