While we hope you will never have to do a farm restore, you should know the steps to be able to perform one with confidence. There are many situations where you need to rely on a farm restore to bring your environment back online. These include:
- Loss or major corruption of one or more databases or database servers
- Accidental or malicious removal of data at the farm level (i.e., using Central Administration or PowerShell)—for example, deleting a web application
On the other hand, a farm restore is not always needed. Here are two situations where you do not need to do a farm restore:
- Loss of a WFE or application server. In many cases, you can remove the old server from the farm, install SharePoint on a new server, join it to the farm, and configure the services that should be running on it. Depending on your environment, however, there may be additional third-party software that needs installation, or other custom changes that you need to apply.
- You need to restore data from within a content database (e.g., restore a website or file). For this type of restore, see “Recover Data from an Unattached Content Database,” later in this chapter.
A farm restore can be done with Central Administration or PowerShell, but since restores are usually done ad hoc when needed, we will detail these steps using Central Administration only. Furthermore, performing a restore from the command line is much more difficult, and there is a higher probability of making a typo, causing the restore to fail.
Understanding Farm Restore
Just like a backup, when doing a farm restore, you have the option of restoring the complete farm, just its configuration, or a single farm component. If you did a complete farm backup, you are not required to do a complete restore. You can do a component restore from a complete farm backup. For example, you can restore a single content database or service application from your complete farm backup.
When doing a farm restore, you have the following choices:
Restore to the Same Configuration SharePoint replaces the existing component when doing the restore.
Restore to a New Configuration You can rename the component during the restore. A common example of using a new configuration is when you are restoring a content database—you can restore the database to a different server or as a different database name.
SharePoint does not store managed account passwords in any backup. Consequently, when you restore a web application or service application, you will need to know the application’s managed account password. If you don’t know the password, you will need to reset it within Active Directory prior to starting the restore. When starting the restore, SharePoint will prompt you for all the passwords needed, as covered in the next section.
If you have a major farm failure and the configuration database is unavailable, you will first need to create a new farm before doing a restore. SharePoint’s farm restore can only be run when the farm is online.
Using Central Administration to Restore the Farm
Using Central Administration to perform a farm restore is the recommended approach. It is the easiest approach since you have a graphical interface when reviewing and adjusting the configuration settings, including when you’re entering the managed account passwords.
Here’s how to restore the farm:
1. Click Backup And Restore, and then select Restore From A Backup.
2. For Backup Directory Location, the most recent backup path is shown with the backup sets found. If you have moved your backup files to an alternate path, change it here and click the Refresh button.
3. Select the backup set that you wish to restore. These are pulled from the spbrtoc.xml file that is processed from this directory location.
4. Click Next.
5. SharePoint displays a tree view of all components. Check boxes are listed next to those components that are available for restore from this backup set. Select the component that you wish to restore. Just with the backup, you can restore only one component at a time, and any subcomponents are automatically included.
6. Click Next.
7. This page’s contents will vary depending on what you selected for restore on the previous page. If you are performing a farm restore, you must choose Restore Content And Configuration Settings or Restore Only Configuration Settings.
8. Under Restore Options, you are asked what type of restore you want to perform. Your choices are New Configuration or Same Configuration (see Figure 16.3).
Figure 16.3: Restoring a web application
9. If a web application or service application is included in the restore, the Login Names And Passwords section contains all the managed accounts that SharePoint will re-create when performing the restore. You must provide the current password for each account. If you do not know the password, you will need to reset it in AD.
10. If you are restoring to a new configuration and are restoring content databases, then in the New Names section you must provide the new directory name for the database files, the new database name for the database to restore, and the new database server name. You have these three options for each content and service application database. If you are restoring to the same configuration, the information in this section cannot be changed.
11. Depending on the components you selected for restore, other names such as web application URLs and service application names may be listed.
CAUTION Before clicking Start Restore, double- and triple-check your settings! The restore may take hours, and it will be frustrating to have to do it again because you had one setting wrong.
12. Click the Start Restore button to begin the restore. A timer job is created and you are redirected to the backup and restore status page.
If you are doing a complete farm restore, you will find there is more work that needs to be done to finalize the environment. Tasks include:
- Reapplying manual IIS configuration changes, such as SSL certificate bindings
- Restarting services on the correct servers
- Reconfiguring service application associations
- Reapplying manual changes made to web.config files
- Redeploying any DLL files (assemblies) that were manually deployed into the GAC
- Reapplying any manual changes to the SharePoint Root (14 Hive)
- Reestablishing any cross-farm trust relationships
- Testing each essential SharePoint function to be sure it is working correctly
To perform a farm restore using PowerShell, use the Restore-SPFarm cmdlet. For more information, see the article “Restore a Farm (SharePoint Foundation 2010)” at http://technet.microsoft.com/en-us/library/ee428311.aspx.