SharePoint 2010-Backup and Recovery Guidelines

Introduction
This blog post 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
Backup strategy
There are two different approaches for backup and restore

• Content/Config Database Backup using SQL Server
• Backup using SharePoint Server

Lets look at each approach in details
1) Content/Config Database Backup using SQL Server
Approach one is to use SQL Server backup to back content DBs and Configuration DBs with a complete script for deployment of Web application, Site Collection, Service Provisioning.

Backup Method
a. Create Deployment script of entire Farm. This will include below components of SharePoint

i. Web Application Creation

ii. Site Collection Creation

iii. Service Application Creation and Provisioning

iv. Association of Service Application with Web Application

v. Deployment of Custom Code (WSP)

b. Use SQL Server Backup for backing up all Content Database & Configuration Database
c. Backup the entire 12 hive (c:\program files\common files\microsoft shared\web server extensions\12). This is because, frequently you will deploy code to your SharePoint farm, and you will need to restore the supporting physical files for the site to work properly.
d. You need to keep monitoring the size of your content databases. If you start hitting the 50GB mark, think of splitting them up, so the backups are done overnight before users start hitting the database in the morning.
e. Backup the entire INETPUB directory.

Restore Method
In case of disaster we need to follow below steps to recover/restore content for approach 1

a. Create Web Application and Site collection using the deployment script

b. Attach/de-attach Content database for new created Site collection

Protecting customizations
Customizations to SharePoint sites can include the following:

a. Master pages, page layouts and cascading style sheets. These objects are stored in the content database for a Web application.

b. Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, coded workflows, or workflow activities and conditions.

c. Third-party solutions and their associated binary files and registry keys, such as IFilters.

d. Changes to standard XML files.

e. Custom site definitions (Webtemp.xml).

f. Changes to the Web.config file.

How customizations are deployed, and how changes are made to the Web.config file, have a significant effect on which tools can be used to back up and recover customizations. To provide the greatest opportunity for recovery, we recommend that you deploy customizations by using solution packages and configure the Web.config file by using Central Administration or the SharePoint APIs and object model.
Advantages:

1) it is easy to maintain and backup/restore over many SharePoint farms.

2) It needs little administrative work when moving site collection from one farm to another or one web application to another web application

3) Takes less time to backup and restore.

4) Unattached Content Database Recovery allows you to browse through the content database using SharePoint, navigate to a list or document library and save the list or library into .cmp file which can easily be moved between sites

Disadvantage

1) When restoring, web application or Site collection has be created using Central admin or PowerShell before restore

2) SQL Server does not provide SharePoint Farm backup

2) Backup using SharePoint Server:
Approach two is to use SharePoint Server backup to backup Farm, Web application, content DBs and Configuration DBs
Backup Method
a. Create backup script of entire Farm. This will include below components of SharePoint

i. Web Application backup

ii. Site Collection backup

iii. Service Application backup

Restore Method
In case of disaster we need to follow below steps to recover/restore content for approach 1

a. Restore entire farm or restore individual Web application or site collection separately

Advantages:

a. Web interface for backup and restore within Central Admin Site

b. SharePoint backup provides granular level backup for Site Collection and Web

c. SharePoint backup provides Entire Farm Level backup

Disadvantage

a. High restore time

b. No back up directly to tape

c. no custom solution files backup

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

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.