Restore a farm (SharePoint Foundation 2010)

SharePoint 2010

Applies to: SharePoint Foundation 2010

Topic Last Modified: 2012-11-08

This article describes how to restore a Microsoft SharePoint Foundation 2010 farm. Farm-level recovery is usually performed only after a failure that involves the complete farm, or where partial recovery of part of the farm is not possible. If you only have to restore part of the farm, a specific database, a service application, a list, or document library, or a specific document, use another recovery method. For more information about alternate forms of recovery, see Related content.

Farm recovery is usually performed for any of the following reasons:

Restoring a farm after a fire, disaster, equipment failure, or other data-loss event.

Restoring farm configuration settings and data to a specific previous time and date.

Moving a SharePoint Foundation 2010 deployment from one farm to another farm.

You cannot restore a multiple-server farm to a stand-alone farm or a stand-alone farm to a multiple-server farm.

You cannot back up from one version of Microsoft SharePoint Foundation and restore to another version of SharePoint Foundation.

Backing up the farm will back up the configuration and Central Administration content databases, but these cannot be restored using Microsoft SharePoint Foundation 2010 tools. For more information about backing up and restoring all the farm databases, see Move all databases (SharePoint Foundation 2010).

When you restore the farm by using Microsoft SharePoint Foundation 2010, the restore process will not automatically start all of the service applications. You must manually start them by using Central Administration or Windows PowerShell. Do not use SharePoint Products Configuration Wizard to start the services because doing so will also re-provision the services and service proxies.

The identifier (ID) of each content database is retained when you restore or reattach a database by using built-in tools. Default change log retention behavior when using built-in tools is as follows:

The change logs for all databases are retained when you restore a farm.

The change log for content databases is retained when you reattach or restore a database.

When a database ID and change log are retained, the search system continues crawling based on the regular schedule that is defined by crawl rules.

When you restore an existing database and do not use the overwrite option, a new ID is assigned to the restored database, and the database change log is not preserved. The next crawl of the database will add data from the content database to the index.

If a restore is performed and the ID in the backup package is already being used in the farm, a new ID is assigned to the restored database and a warning is added to the restore log. The ability to perform an incremental crawl instead of a full crawl depends on the content database ID being the same as before and the change log token that is used by the search system being valid for the current change log in the content database. If the change log is not preserved, the token is not valid and the search system has to perform a full crawl.

SharePoint Foundation 2010 backup backs up the Business Data Connectivity service external content type definitions but does not back up the data source itself. To protect the data, you should back up the data source when you back up the Business Data Connectivity service or the farm.

If you restore the Business Data Connectivity service or the farm and then restore the data source to a different location, you must change the location information in the external content type definition. If you do not, the Business Data Connectivity service might be unable to locate the data source.

SharePoint Foundation 2010 restores remote Binary Large Objects (BLOB) stores only if you are using the FILESTREAM remote BLOB store provider to put data in remote BLOB stores.

If you are using another provider, you must manually restore the remote BLOB stores.

If a user has taken copies of content for off-line editing in Microsoft SharePoint Workspace 2010 and the content is restored from a backup on the server, when the user re-connects, the server automatically synchronizes the off-line content with the restored content. This might result in data loss on the user's copies of the content.

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 your certificate store separately or retain 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.

After a Web application that is configured to use claims-based authentication has been restored, duplicate or additional claims providers are often visible. If duplicates appear, you must then manually save each Web application zone to remove them. For more information, see Restore a Web application (SharePoint Foundation 2010).

Start-SPServiceInstance For more information about restarting service applications by using Windows PowerShell, see Start-SPServiceInstance.

For more information about restoring the farm by using Windows PowerShell, see Restore-SPFarm.

Note

We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

In Central Administration, on the Home page, in the Backup and Restore section, click Restore from a backup.

On the Restore from Backup — Step 1 of 3: Select Backup to Restore page, from the list of backups, select the backup job that contains the farm backup, and then click Next. You can view more details about each backup by clicking the (+) next to the backup.

Note

If the correct backup job does not appear, in the Backup Directory Location text box, type the Universal Naming Convention (UNC) path of the correct backup folder, and then click Refresh.
You cannot use a configuration-only backup to restore the farm.

On the Restore from Backup — Step 2 of 3: Select Component to Restore page, select the check box that is next to the farm, and then click Next.

On the Restore from Backup — Step 3 of 3: Select Restore Options page, in the Restore Component section, ensure that Farm appears in the Restore the following component list.

In the Restore Only Configuration Settings section, ensure that the Restore content and configuration settings option is selected.

In the Restore Options section, under Type of Restore, select the Same configuration option. A dialog box will appear that asks you to confirm the operation. Click OK.

Note

If the Restore Only Configuration Settings section does not appear, the backup that you selected is a configuration-only backup. You must select another backup.

Click Start Restore.

You can view the general status of all recovery jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current recovery job in the lower part of the page in the Restore section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the recovery to start.

If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified in step 3.

When the restore process has completed, you may need to restart one or more service applications. In Central Administration, on the Home page, in the Application Management section, click Manage services on server.

On the Services on Server page, start any services related to service applications that you want to run by clicking Start in the Actions column next to the service application.

Although you cannot restore the complete farm by using SQL Server tools, you can restore most of the farm databases. If you restore the databases by using SQL Server tools, you must restore the farm configuration by using Central Administration or Windows PowerShell. For more information about how to restore the farm’s configuration settings, see Restore a farm configuration (SharePoint Foundation 2010).

Note

The search index is not stored in SQL Server. If you use SQL Server tools to back up and restore search, you must perform a full crawl after you restore the content database.

Before you restore SharePoint Foundation 2010, we recommend that you configure a recovery farm for site and item recovery.

Restore the databases by following these steps:

If possible, back up the live transaction log of the current database to protect any changes that were made after the last full backup.

Restore the last full database backup.

Restore the most recent differential database backup that occurred after the most recent full database backup.

Restore all transaction log backups that occurred after the most recent full or differential database backup.

To restore a farm by using SQL Server tools

Verify that the user account that is performing this procedure is a member of the sysadmin fixed server role.

If the Windows SharePoint Services Timer service is running, stop the service and wait for several minutes for any currently running stored procedures to finish. Do not restart the service until after you restore all the databases that you have to restore.

Except for the configuration database, repeat steps 4 through 9 for each database that you are restoring.

To restore the configuration settings, you must use the existing configuration database or manually create a new database and restore the configuration to that database. For more information about restoring the farm configuration, see Restore a farm configuration (SharePoint Foundation 2010).