Showing results for 
Search instead for 
Did you mean: 

Sharepoint 2007 Backup W/ Deduplication Very Slow


My organization has just transitioned from Backup Exec 12.5 with all tape backups to Backup Exec 2010 R3. Since the changeover, our sharepoint backup has become incredibly slow. On the older system, the nightly full backup of sharepoint would take roughly 8 hours. Currently, we are doing a full backup of our sharepoint farm nightly, and it is backing up to a dedup folder which resides on 7200RPM drives. The most current backup took 23 hours, 30 minutes.

Our sharepoint farm is around 700GB.

A couple issues that I think could be an issue are the following:

  1. 1. Our front end Sharepoint server resides on a virtual machine, whereas the database server containing all of the databases are on a physical machine. Both   are 2003R2.
  2. 2. The size of the sharepoint farm and the databases which make up the farm. The farm itself is 700GB, and most of the databases are over 100GB a piece
  3. 3. Network throughput. Both the database server and the front end server are operating on a 1GB pipe. The backup server has a 2GB pipe

On a side note, we are doing a media side backup, we have tried client side but it is even slower.


Has anyone heard of any issues occuring between Sharepoint and dedup backups? Any suggestions on troubleshooting the issue?




4 Replies

Have you tried doing the same

Have you tried doing the same backup to a normal B2D folder?  Doing this would isolate whether it is dedupe that is slowing things down or the backup itself.

I would stick with the media

I would stick with the media server side dedupe and add the advanced open file backup in order to take a vss snap of the databases.

I am surprised that you are

I am surprised that you are asking the user to use AOFO for his database backup.  This is contrary to what is stated in the Admin Guide which is NOT to use AOFO when backing up databases.

AOFO probably won't help with a throughput issue but can be used

There is no problem using AOFO/VSS with any Sharepoint 2003 or later backup, but with it enabled the amount of data backed up will be more than what a non-AOFO backup would be (a VSS backup gets snapshots of each of the database files rather than a streamed composite dump of the DB). 

More than likely the culprit is the larger number of GRT objects supported for restore in Backup Exec 2010 R3 Sharepoint agent vs. 12.5 causing the 'updating catalog' phase to be longer for each content DB.  There is a known issue with the updating catalogs phase taking excessively long that is in line for a hotfix-

Note that depending on the size of the content database and the number of objects within it,  the 'updating catalogs' phase can take a long time to complete.