Backup and recovery overview (SharePoint Server 2010)

Applies to: SharePoint Server 2010, SharePoint Foundation 2010

This article describes the backup architecture and recovery processes that are available in Microsoft SharePoint Server 2010, including farm and granular backup and recovery, and recovery from an unattached content database. Backup and recovery operations can be performed through the user interface or through Windows PowerShell cmdlets. Built-in backup and recovery tools may not meet all the needs of your organization.

In this article:

• Backup and recovery scenarios

• Backup architecture

• Recovery processes

Sharepoint backup and recovery scenarios

Backing up and recovering data supports many business scenarios, including the following:

• Recovering unintentionally deleted content that is not protected by the Recycle Bin or versioning.

• Moving data between installations as part of a hardware or software upgrade.

• Recovering from an unexpected failure.

Backup architecture in SharePoint

SharePoint Server 2010 provides two backup systems: farm and granular.

Farm backup architecture in SharePoint

The farm backup architecture in SharePoint Server 2010 starts a Microsoft SQL Server backup of content and service application databases, writes configuration content to files, and also backs up the Search index files and synchronizes them with the Search database backups.

The following illustration shows the farm backup system.

Both full and differential backups are supported. Full backups create a new backup of the complete system. Differential backups create a backup of all the data that is stored in databases that has changed since the last full backup.

The farm backup system is organized hierarchically. The components in a farm that can be selected for backup include the following:

• Farm   The farm is the highest-level object. You can select from the following options when you perform a farm backup:

  • Content and configuration data (default)

    The whole server farm is backed up. This includes settings from the configuration database.

  • Configuration-only

    Configuration database settings are backed up so that you can apply configurations across farms. For more information, see Configuration-only backup use and benefits later in this article.

• Web application   Within a Web application, you can select one or more of the content databases to back up.

  A Web application backup includes the following:

  • Application pool name and application pool account

  • Authentication settings

  • General Web application settings such as alerts and managed paths

  • Internet Information Services (IIS) binding information, such as the protocol type, host header, and port number

  • Changes to the Web.config file that have been made through the object model or Central Administration

    Note

    Changes to the Web.config file that have been made to support claims-based application that uses forms-based authentication are not included in backups, because those changes are made manually. For more information, see Considerations for using farm backups later in this article.

  • Sandboxed solutions

  For recommendations about how to protect these settings, see Plan for backup and recovery in SharePoint Server 2010.

• Services and service applications (not shared)   An example of a service that is not shared is the State Service. Service and service application backups contain the settings for a service or service application and any databases associated with it.

  Important

  Backups of service applications do not include the related proxy. To back up both the service application and the service application proxy, you must either back up the farm or perform two consecutive backups, selecting the service application in one backup, and selecting the associated service application proxy in the second backup.

  Many service application databases cannot be backed up individually from SharePoint Server 2010. To back up service application databases only, you must use SQL Server backup.

• Proxies for service applications that are not shared

• Shared Services   Shared services require both a service application and a service application proxy to run. If you select the Shared Services node, all of the service applications and the related service application proxies on the farm will be backed up.

  Note

  The backup hierarchy enables you to select individual service applications and service application proxies to back up. However, when you select one or all service applications, or one or all proxies, the related objects are not backed up by default. To back up both parts of a specific service, you must either select the Shared Services node or perform two consecutive backups, selecting the service application in one backup, and selecting the associated service application proxy in the second backup.

Search service application backup process

Backing up and recovering the Search service application is a special case because of the complexity of interactions between the components of the application.

When a backup of the Search service application is started, SharePoint Server 2010 starts a SQL Server backup of the Search administration database, crawl databases, and property databases, and also backs up the index partition files in parallel.

Consider how the backup and recovery processes for the Search service application affect your service-level agreement. For example, consider how pausing all crawls might affect the freshness of search results.

The backup process is as follows:

1. Master merges are paused to preserve the master index.

2. A full database backup starts.

3. The master index is backed up.

4. Crawls are paused. The pause in crawling is much shorter than during a backup of Microsoft Office SharePoint Server 2007 search, and does not last the full duration of the backup process.

5. All shadow indexes are backed up.

6. An incremental database backup starts.

7. Crawls are resumed.

8. Master merges are resumed.

Configuration-only backup use and benefits

A configuration-only backup extracts and backs up the configuration settings from a configuration database. By using built-in tools, you can back up the configuration of any configuration database, whether it is currently attached to a farm or not. For detailed information about how to back up a configuration, see Back up a farm configuration in SharePoint Server 2010.

A configuration backup can be restored to the same — or any other — server farm. When a configuration is restored, it will overwrite any settings present in the farm that have values that are set in the configuration backup. If any settings present in the farm are not contained in the configuration backup, they will not be changed. For detailed information about how to restore a farm configuration, see Restore a farm configuration in SharePoint Server 2010.

Situations in which you might want to restore a configuration from one farm to another farm include the following:

• Replicating a standardized farm configuration to be used throughout an environment.

• Moving configurations from a development or test environment to a production environment.

• Moving configurations from a stand-alone installation to a farm environment.

• Configuring a farm to serve as part of a standby environment.

SharePoint Server stores the following kinds of settings in the configuration-only backup:

• Antivirus

• Information rights management (IRM)

• Outbound e-mail settings (only restored when you perform an overwrite).

• Customizations deployed as trusted solutions

• Diagnostic logging

Considerations for using farm backups

Consider the following before you use farm backups:

• There is no built-in scheduling system for backups. To schedule a backup, we recommend that you create a backup script by using Windows PowerShell, and then use Windows Task Scheduler to run the backup script on a regular basis.

• We do not recommend that you use IIS metabase backup to protect IIS settings. Instead, document all IIS configurations for each Web server by using a tool that provides the configuration monitoring you want, such asMicrosoft System Center Configuration Manager 2007.

• SharePoint Server 2010 backup and recovery can be run together with SQL Server Enterprise features such as backup compression and transparent data encryption.

  If you are running SQL Server Enterprise, we strongly recommend that you use backup compression. For more information about backup compression, see Backup Compression (SQL Server) https://go.microsoft.com/fwlink/p/?LinkID=129381).

  If you decide to run databases with transparent data encryption, you must manually back up the key and restore the key — SharePoint Server 2010 backup and restore will not remind you about the key. For more information about transparent data encryption, see Understanding Transparent Data Encryption (TDE) (https://go.microsoft.com/fwlink/p/?LinkID=129384).

• If a content database is set to use the SQL FILESTREAM remote BLOB storage (RBS) provider, the RBS provider must be installed both on the database server that is being backed up and on the database server that is being recovered to.

• SharePoint Server 2010 backup does not protect:

  • Changes to the Web.config file on Web servers that are not made through Central Administration or the object model.

  • Customizations to a site that are not deployed as part of a trusted or sandboxed solution.

• If you are sharing service applications across farms, be aware that trust certificates that have been exchanged are not included in farm backups. You must back up the certificate store separately or keep the certificates in a separate location. When you restore a farm that shares a service application, you must import and redeploy the certificates and then re-establish any inter-farm trusts.

  For more information, see Exchange trust certificates between farms (SharePoint Server 2010).

• When you restore a farm or Web application that is configured to use any kind of claims-based authentication, duplicate or additional providers may appear to be enabled. If duplicates appear, you must manually save each Web application zone to remove them.

• Additional steps are required when you restore a farm that contains a Web application that is configured to use forms-based authentication. You must re-register the membership and role providers in the Web.config file, and then redeploy the providers. You must perform these steps whether you are restoring at the Web application level or at the farm level.

  For more information, see Back up a Web application in SharePoint Server 2010, Plan authentication methods (SharePoint Server 2010) and Configure claims authentication (SharePoint Server 2010).

Granular backup and export architecture

The granular backup and export architecture uses Transact-SQL queries and export calls. Granular backup and export is a more read-intensive and processing-intensive operation than farm backup.

From the granular backup system, a user can back up a site collection, or export a site or list.

If you are running SQL Server Enterprise, the granular backup system can optionally use SQL Server database snapshots to ensure that data remains consistent while the backup or export is in progress. When a snapshot is requested, a SQL Server database snapshot of the appropriate content database is taken, SharePoint Server uses it to create the backup or export package, and then the snapshot is deleted. Database snapshots are linked to the source database where they originated. If the source database goes offline for any reason, the snapshot will be unavailable. For more information about database snapshots, see Database Snapshots (https://go.microsoft.com/fwlink/p/?LinkId=166158).

Benefits of backing up a site collection by using a snapshot include the following:

• The snapshot ensures that the data that is being read remains consistent while the operation is being performed.

• Users can continue to interact with the site collection while it is being backed up from the database snapshot. This includes adding, editing, and deleting content. However, the changes that users make to the live site will not be included in the site collection backup because the backup is based on the database snapshot.

However, database snapshots can adversely affect performance. For more information about database snapshots and performance, see Limitations and Requirements of Database Snapshots (https://go.microsoft.com/fwlink/p/?LinkId=166159).

You can use granular backup and export for content that is stored in a database that is configured to use the SQL FILESTREAM RBS provider.

The following illustration shows the granular backup and export system.

Recovery processes in SharePoint

SharePoint Server 2010 supports the following primary, built-in recovery options:

• Restore from a farm backup that was created by using built-in tools, or restore from the backup of a component taken by using the farm backup system.

• Restore from a site collection backup.

• Connect to a content database by using the unattached content database feature, back up or export data from it, and then restore or import the data.

Restoring from a farm backup

Items that can be recovered from a farm backup include the following:

• Farm

  • Content and configuration data (default)

    The whole server farm is restored. This includes settings from the configuration database, and trusted solution packages.

  • Configuration-only

    Only the configuration data is restored. This overwrites any settings in the farm that have values that are set within the configuration-only backup.

• Web applications

  Restores Web applications.

• Service applications

  Restores service applications. Service application recovery can be complex because SharePoint Server 2010 cannot fully reconfigure service application proxies during the restore process. Service application proxies are restored, but are not put in proxy groups. Therefore, they are not associated with any Web applications. For more information about how to restore a Search service application, see Search service application recovery process. For specific information about the operations involved in restoring specific service applications, see Restore a service application in SharePoint 2010 Products.

• Content databases

  When content databases are restored, the sandboxed solutions associated with the related site collections are also restored.

Restoring as new versus restoring as overwrite

By default, SharePoint Server 2010 recovery restores any object as a new instance of the object, instead of overwriting any existing instances with the same name.

When you restore a farm or object as new, the following objects will not work without adjustments, because all GUIDs for objects are assigned new values:

• Farm.   When you restore a farm as new, you must do the following:

  • Re-create alternate access mapping settings. SharePoint Server 2010 recovery only restores the Default zone of the Web application.

  • Reconfigure settings for any Business Connectivity Services and Managed Metadata service application external sources.

  • Re-associate service application proxies with proxy groups because service application proxies are not assigned to proxy groups when restored. All Web applications will be associated with the default proxy group. You must associate Web applications with other proxy groups if you want to do that.

• Web application.

  • If the Web application name and URL that you provide match a Web application name and URL that already exist in the farm, SharePoint Server 2010 recovery combines them.

  • If you do not want to combine Web applications, you must rename the Web application when you restore it as new.

  • When you restore a Web application as new in the same environment but do not combine Web applications, many other parameters and objects must also be changed. For example, you may have to provide different database file paths and different database names.

• Service applications and service application proxies

  • If you recover a service application and also recover the related service application proxy, you must associate the service application proxy with a proxy group.

  • If you recover a service application and do not also recover the related service application proxy, you must re-create the service application proxy.

  Note

  You cannot restore a service application as new in the same farm. You can restore a service application as new in another farm.

When you restore an object and overwrite the existing object, no changes are necessary.

Search service application recovery process

The recovery process for the Search service application varies depending on whether you are restoring as new or restoring as overwrite. When you restore as overwrite, no additional steps are necessary.

The restore as new process is as follows:

1. Restore the service application as new, and specify the new farm topology information as you restore.

2. Restore the service application proxy as new. If you did not restore the service application proxy, you must create a new service application proxy and associate it with the Search service application.

3. Associate the service application proxy with the appropriate proxy group and associate the proxy group (if it is not the default proxy group) with the appropriate Web application.

4. For least-privilege deployments, start the Search service and the Search admin query Web service with the appropriate account.

For more information about how to recover the Search service application, see Restore search in SharePoint Server 2010.

Restoring from a site collection backup

Only site collections can be recovered from a site collection backup.

Recovering from an unattached content database

SharePoint Server 2010 provides the ability to connect to, and back up from, a content database that is attached to an instance of SQL Server but is not associated with a local SharePoint Web application. Unattached databases that you can connect to include read-only content databases that have been restored from any supported backup technology and SQL Server database snapshots of content databases.

Recovery is the following two-stage process:

1. Back up or export the object from the unattached content database.

2. Restore or import the output of the prior step into SharePoint Server 2010.

The following items can be backed up or exported from an unattached database by using granular backup and export, and then restored:

• Site collection

  Back up by using site collection backup, and then recover by using a site collection restore.

• Site

  Export, and then import.

• Lists and libraries

  Export, and then import.

You can use import to recover content that you backed up from a database configured to use the SQL FILESTREAM RBS provider. The recovered content will be stored by SharePoint Server 2010 using the currently defined storage provider for that content database — that is, if the content database is not set to use RBS, the data will be stored in the content database; if the content database is set to use RBS, the data will be stored in RBS.

Related content

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Server 2010