Best Practices for performance in SharePoint

Performance best practices

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

1. 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.

2. 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.

3. 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

1. 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

1. 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

1. 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

Use compression during backup

1. 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

Follow SQL Server backup and restore optimization recommendations

1. 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

Configure SharePoint settings for better backup or restore performance

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

2. 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.

3. 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

4. If you are using the Backup-SPFarm cmdlet, you can use theBackupThreads 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

1. 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

a. Less than 15 gigabytes (GB): Use the Windows PowerShell command Backup-SPSite.

b. 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.

c. 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

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

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

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.