Restore a farm (SharePoint Foundation 2010)
Applies to: SharePoint Foundation 2010
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.
In this article:
Considerations when recovering a farm
To restore a farm by using Windows PowerShell
To restore a farm by using Central Administration
To restore a farm by using SQL Server tools
Considerations when recovering a farm
When you prepare to recover a farm, be aware of the following issues:
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.
For more information, see Exchange trust certificates between farms (SharePoint Foundation 2010).
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).
Additional steps are required when you restore a farm that contains a Web application that is configured to use forms-based authentication. For more information, see Restore a Web application (SharePoint Foundation 2010).
Use Windows PowerShell to restore a farm
You can use Windows PowerShell to restore a farm.
To restore a farm by using Windows PowerShell
Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
On the Start menu, click All Programs.
Click Microsoft SharePoint 2010 Products.
Click SharePoint 2010 Management Shell.
At the Windows PowerShell command prompt, type the following command:
Restore-SPFarm -Directory <BackupFolder> -RestoreMethod Overwrite [-BackupId <GUID>]Where:
<BackupFolder> is the path of the folder you use for storing backup files.
<GUID> is the identifier of the backup to restore from.
Note
If you are not logged on as the Farm account, you are prompted for the Farm account’s credentials.
If you do not specify the
BackupId, the most recent backup will be used. To view the backups for the farm, type the following command:Get-SPBackupHistory -Directory <BackupFolder> -ShowBackup [-Verbose]Where:
- <BackupFolder> is the path of the folder you use for storing backup files.
You cannot use a configuration-only backup to restore content databases together with the configuration.
To restart a service application, type the following command:
Start-SPServiceInstance -Identity <ServiceApplicationID>Where:
- <ServiceApplicationID> is the GUID of the service application.
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.
Use Central Administration to restore a farm
You can use the Central Administration Web site to restore a farm.
To restore a farm by using Central Administration
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.
Re-establish any trust relationships. For more information, see Exchange trust certificates between farms (SharePoint Foundation 2010).
Use SQL Server tools to restore a farm
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.
Start SQL Server Management Studio and connect to the database server.
In Object Explorer, expand Databases.
Right-click the database that you want to restore, point to Tasks, point to Restore, and then click Database.
The database is automatically taken offline during the recovery operation and cannot be accessed by other processes.
In the Restore Database dialog box, specify the destination and the source, and then select the backup set or sets that you want to restore.
The default values for destination and source are appropriate for most recovery scenarios.
In the Select a page pane, click Options.
In the Restore options section, select only Overwrite the existing database. Unless your environment or policies require otherwise, do not select the other options in this section.
In the Recovery state section:
If you have included all the transaction logs that you must restore, select RECOVER WITH RECOVERY.
If you must restore additional transaction logs, select RECOVER WITH NORECOVERY.
The third option, RECOVER WITH STANDBY is not used in this scenario.
Note
For more information about these recovery options, see Restore Database (Options Page) (https://go.microsoft.com/fwlink/p/?LinkId=114420).
Click OK to complete the recovery operation.
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).
Start the Windows SharePoint Services Timer service.
Related content
Resource Centers |
Business Continuity Management for SharePoint Foundation 2010 (https://go.microsoft.com/fwlink/p/?LinkId=201997) |
IT Pro content |
Back up a farm (SharePoint Foundation 2010) Restore a farm configuration (SharePoint Foundation 2010) |
See Also
Other Resources
Resource Center: Business Continuity Management for SharePoint Foundation 2010