Udostępnij za pośrednictwem

Tips for improving backup and recovery performance (Office SharePoint Server)

  • Artykuł

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

Use the tips in this article to help you decrease the effect on performance of backup and recovery operations.

By design, most backup jobs consume as many I/O resources as they can to finish the job in the available time for maintenance. Therefore, you might see disk queuing, and you might see that all I/O requests come back more slowly than usual. This is typical and should not be considered a problem.

Select tools for backing up site collections based on size

If the business requires site collection backups in addition to farm-level or database-level backups, select the tools that you will use based on the site collection size.

  • Less than 15 gigabytes (GB): Use Stsadm site collection backup.

    Note

    You should lock the site collection before you use Stsadm site collection backup. To do this, set a Read-Only lock by using the following operation: Setsitelock: Stsadm operation (Office SharePoint Server).

  • 15-100 GB: Use a SharePoint Products and Technologies tool, a SQL Server tool, or other database backup tool to protect the content database that contains the site collection.

  • Larger than 100 GB: Use a differential backup solution, such as Microsoft SQL Server 2005 or Microsoft System Center Data Protection Manager 2007, instead of the built-in backup and recovery tools.

Minimize latency between SQL Server and the backup location

In general, it is best to use a local disk, not a network drive, for backups. If you are backing up multiple servers, you may want to have a directly connected computer that both servers can write to. Network drives with 1 millisecond or less latency between them and the computers that are running SQL Server will perform well.

Avoid processing conflicts

Do not run backup jobs during times in which users require access to the system.

To avoid I/O bottlenecks, perform the main backup to a separate disk, and only then copy to tape.

Consider staggering backups so that not all databases are backed up at the same time.

SharePoint backups use SQL Server backups. When using compression with your backups, be mindful not to overwhelm SQL Server. For example, some third-party backup tools compress during backup which can disrupt SQL Server performance. There are tools available to throttle the compression processes and control the impact on SQL Server.

Consider database size when determining the tools to use

Consider the information in the following table when you select a backup and recovery tool. For large databases, we recommend that you rely on incremental backup tools. For more information, see Choose backup and recovery tools (Office SharePoint Server).

Tool Maximum backup size supported

System Center Data Protection Manager

32-bit systems: 150 data sources

64-bit systems: 300 data sources

For more information, see Data Protection Manager 2007 Frequently Asked Questions (https://go.microsoft.com/fwlink/?LinkId=126629).

SharePoint farm backup and recovery

< 200 GB

VSS Writer

No known limit

SQL Server

Content databases > 200 GB  may require additional management

Stsadm site collection backup and recovery

15 GB

Stsadm import and export

100 GB

SharePoint Designer backup

24 MB

MSIT Site Delete Capture tool

15 GB

Follow SQL Server backup and restore optimization recommendations

If you are using SQL Server backups, use a combination of full, differential, and transaction log backups (for the full or bulk-logged recovery model) to minimize recovery time. Differential database backups are usually faster to create than full database backups and reduce the amount of transaction log required to recover the database.

If you are using the full recovery model in SQL Server 2005, we recommend that you periodically truncate the transaction log files to avoid maintenance issues.

For detailed recommendations about how to optimize SQL Server backup and restore performance, see Optimizing Backup and Restore Performance in SQL Server (https://go.microsoft.com/fwlink/?LinkId=126630).

Use RAID 10 if you are going to use RAID

Carefully consider whether to use redundant array of independent disks (RAID) on your disk backup device. For example, RAID 5 has low write performance, approximately the same speed as for a single disk. (This is because RAID 5 has to maintain parity information.) Using RAID 10 for a backup device may provide faster backups. For more information about how to use RAID with backups, see Configure RAID for maximum SQL Server I/O throughput (https://go.microsoft.com/fwlink/?LinkId=126632).