Backup and recovery best practices (SharePoint Server 2010)

Applies to: SharePoint Server 2010, SharePoint Foundation 2010

This article describes best practices that you can use to help ensure that backup and recovery operations in Microsoft SharePoint Server 2010 are successful and that the environment is protected against data loss or continuity gaps. The article includes best practices for performance, quality assurance, security, and operational excellence.

In this article:

• Performance best practices

• Quality assurance best practices

• Procedural best practices

Performance best practices for Sharepoint backup and recovery

Backup and restore operations can consume server resources and limit server performance while the operations are running. By following these best practices, you can reduce resource usage and increase the performance of servers and the backup or restore operation.

Minimize latency between SQL Server and the backup location

In general, it is best to use a local disk on the database server, not a network drive, for backups, and then copy the data later to a shared folder on the network. Network drives with 1 millisecond or less latency between them and the database server will perform well.

To avoid I/O bottlenecks, perform the main backup to a separate disk from the disk running Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2.

By design, most backup jobs consume all available I/O resources to complete the job. Therefore, you might see disk queuing, which can result in greater than usual I/O request latency. This is typical and should not be considered a problem.

Avoid processing conflicts

Do not run backup jobs during times when users require access to the system. Consider staggering backups so that not all databases are backed up at the same time.

Keep databases small for faster recovery times

Keep databases small to speed both backup and recovery. You can do this by using multiple content databases for a Web application instead of one large content database.

Use incremental backups for large databases

Use incremental backups for large database such as those available with DPM 2010. Incremental backups can be restored faster and more efficiently than full backups for larger databases. For more information about backup types, see Backup Overview (SQL Server) (https://go.microsoft.com/fwlink/p/?LinkId=203863).

Use compression during backup

In some circumstances, you can use compression to improve backup size (30% decrease) and times (25% decrease). Backup compression has been in introduced in SQL Server 2008 Enterprise. For more information about how backup compression affects performance in SQL Server, see Backup Compression (SQL Server) (https://go.microsoft.com/fwlink/p/?LinkID=129381).

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, 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/p/?LinkId=126630).

Use RAID 10 if you are going to use RAID

Carefully consider whether to use redundant array of independent disks (RAID) on the 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/p/?LinkId=126632).

Configure SharePoint settings for better backup or restore performance

You can configure settings in both Central Administration and Windows PowerShell to increase backup or restore efficiency and performance.

If you are using the Export-SPWeb Windows PowerShell cmdlet, you can use the NoFileCompression parameter. By default, SharePoint Server 2010 uses file compression while exporting Web applications, site collection, lists, or document libraries. You can use this parameter to suppress file compression while exporting and importing. File compression can use up to 30% more resources, but the exported file will use approximately 25% less disk space. If you use the NoFileCompression parameter when exporting, you must also use it when you import the same content.

You can also use the NoLogFile parameter. By default, SharePoint Server 2010 always creates a log file when you export content. You can use this parameter to suppress log file creation to save resources. However, we recommend that you always create logs. This is because logs can be used in troubleshooting. Moreover, log creation does not use many resources.

If you are using the Backup-SPFarm cmdlet, you can use the BackupThreads parameter to specify how many threads SharePoint Server 2010 will use during the backup process. The more threads you specify, the more resources that backup operation will take, but the faster that it will finish, if sufficient resources are available. However, each thread is reported individually in the log files, so using fewer threads makes interpreting the log files easier. By default, three threads are used. The maximum number of threads available is 10.

Consider site collection size when determining the tools to use

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 the Windows PowerShell command Backup-SPSite. For more information, see Back up a site collection in SharePoint Server 2010.

• 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. For more information, see Back up a site collection in SharePoint Server 2010.

• Larger than 100 GB: Use a differential backup solution, such as Microsoft SQL Server 2005 or DPM 2010, instead of the built-in backup and recovery tools.

Quality assurance best practices when backing up a Sharepoint farm

You can follow these best practices to help ensure the quality of the backups of the farm environment and reduce the chances of data loss.

Ensure you have adequate storage space

Be certain that the system has adequate disk space to accommodate the backup.

Routinely test backup quality

Routinely test backups and validate their consistency. Run practice recovery operations to validate the contents of the backup and to ensure that you can restore the entire environment. For geographically dispersed environments, prepare for disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Periodically perform a trial data recovery operation to verify that the files are correctly backed up. A trial restoration can expose hardware problems that do not show up with software verifications.

Back up ULS trace logs

The SharePoint Server 2010 tools do not back up the ULS trace logs. Data in ULS trace logs can be useful for performance analysis, troubleshooting, monitoring compliance with service-level agreements, and legal, regulatory, or business reasons. Therefore, protect this data as part of the routine maintenance. For more information about backing up the ULS logs, see Back up or archive logs in SharePoint Server 2010.

Store a copy of backup files off-site

To safeguard against loss from a catastrophic event, such as a fire or earthquake, maintain duplicate copies of backups in a separate location from the servers. Doing so can help protect you against the loss of critical data. As a best practice, keep three copies of the backup media, and keep at least one copy offsite in a controlled environment. This should include all backup and recovery materials, documents, database and transaction log backups, and usage and trace log backups.

Procedural best practices when backing up and restoring SharePoint

You can use these procedural best practices to help plan and perform backup and restore operations with better documentation, more ease, and greater assurance.

Use FQDN server names

When referring to servers in a different domain, always use fully qualified domain names (FQDN).

Keep accurate records

When you deploy SharePoint Server 2010, record the accounts that you create, and the computer names, passwords, and setup options that you choose. Keep this information in a safe place.

Have a recovery environment ready

Prepare for restore testing and disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Similarly, you can set up a standby environment running the same version of software as the production environment so that you can restore the databases and recover documents quickly.

Schedule backup operations

If you want to schedule backups, you can use the Windows Task Scheduler to run them by using a Windows PowerShell script file (*.ps1).

Use the SQL FILESTREAM provider with BLOB storage

If you are using BLOB storage using the SQL FILESTREAM provider and you back up the content database with that Remote BLOB Store (RBS) defined, both the RBS and the content database will be backed up and restored when you use SharePoint tools or SQL Server tools. We do not recommend that you use RBS with other restore methods.