Backup and recovery overview (SharePoint Foundation 2010)

 

Applies to: SharePoint Foundation 2010

This article describes the backup architecture and recovery processes that are available in Microsoft SharePoint Foundation 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

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

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

Farm backup architecture

The farm backup architecture in SharePoint Foundation 2010 starts a Microsoft SQL Server database backup of content and service application databases and also writes configuration content to files.

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 (SharePoint Foundation 2010).

• 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 Foundation 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.

Note

Some settings in the SharePoint Foundation environment are not included in a farm backup. They include the following settings that are stored on Web servers:

• Application pool account passwords

• HTTP compression settings

• Time-out settings

• Custom Internet Server Application Programming Interface (ISAPI) filters

• Computer domain membership

• Internet Protocol security (IPsec) settings

• Network Load Balancing settings

• Secure Sockets Layer (SSL) certificates

• Dedicated IP address settings

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 (SharePoint Foundation 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 (SharePoint Foundation 2010).

Note

Web application and service application settings are not included in a configuration backup. You can use Windows PowerShell cmdlets to document and copy settings for service applications. For more information, see Document farm configuration settings (SharePoint Foundation 2010) and Copy configuration settings from one farm to another (SharePoint Foundation 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 Foundation 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 Foundation 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 Foundation 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 Foundation 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 Foundation 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 (SharePoint Foundation 2010), Plan authentication methods (SharePoint Foundation 2010) and Configure claims authentication (SharePoint Foundation 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.

Note

Workflows are not included in exports of sites or lists.

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

Note

If the RBS provider that you are using does not support snapshots, you cannot use snapshots for content deployment or backup. For example, the SQL FILESTREAM provider does not support snapshots.

Note

We do not recommend that you use SharePoint Foundation 2010 site collection backup for site collections larger than 85 GB.

The following illustration shows the granular backup and export system.

Recovery processes

SharePoint Foundation 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 Foundation 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 specific information about the operations involved in restoring specific service applications, see Restore a service application (SharePoint Foundation 2010).

• 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 Foundation 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 Foundation 2010 recovery only restores the Default zone of the Web application.

  • 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 Foundation 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.

Restoring from a site collection backup

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

Recovering from an unattached content database

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

Resource center	Business Continuity Management for SharePoint Foundation 2010 (https://go.microsoft.com/fwlink/p/?LinkID=201997)
IT pro content	Plan for backup and recovery (SharePoint Foundation 2010) Backup and recovery (SharePoint Foundation 2010)
Developer content	Data Protection and Recovery (https://go.microsoft.com/fwlink/p/?LinkID=199237)

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010