Plan for disaster recovery (SharePoint Foundation 2010)
Updated: July 29, 2011
This article describes key decisions in choosing disaster recovery strategies for a Microsoft SharePoint Foundation 2010 environment.
In this article:
Disaster recovery overview
For the purposes of this article, we define disaster recovery as the ability to recover from a situation in which a data center that hosts SharePoint Foundation becomes unavailable.
The disaster recovery strategy that you use for SharePoint Foundation must be coordinated with the disaster recovery strategy for the related infrastructure, including Active Directory domains, Exchange Server, and Microsoft SQL Server. Work with the administrators of the infrastructure that you rely on to design a coordinated disaster recovery strategy and plan.
The time and immediate effort to get another farm up and running in a different location is often referred to as a hot, warm, or cold standby. Our definitions for these terms are as follows:
Hot standby A second data center that can provide availability within seconds or minutes.
Warm standby A second data center that can provide availability within minutes or hours.
Cold standby A second data center that can provide availability within hours or days.
Disaster recovery can be one of the more expensive requirements for a system. The shorter the interval between failure and availability and the more systems you protect, the more complex and costly a disaster recovery solution is likely to be. When you invest in hot or warm standby data centers, costs include:
Additional hardware and software, which often increase the complexity of operations between software applications, such as custom scripts for failover and recovery.
Additional operational complexity.
The costs of maintaining hot or warm standby data centers should be evaluated based on your business needs. Not all solutions within an organization are likely to require the same level of availability after a disaster. You can offer different levels of disaster recovery for different content, services, or farms — for example, content that has high impact on your business, or search services, or an Internet publishing farm.
Disaster recovery is a key area in which information technology (IT) groups offer service level agreements (SLAs) to set expectations with customer groups. Many IT organizations offer a variety of SLAs that are associated with different chargeback levels.
When you implement failover between server farms, we recommend that you first deploy and tune the core solution within a farm, and then implement and test disaster recovery.
Choose a disaster recovery strategy
You can choose among many approaches to provide disaster recovery for a SharePoint Foundation environment, depending on your business needs. The following examples show why companies might choose cold, warm, or hot standby disaster recovery strategies.
Cold standby disaster recovery strategy: A business ships backups to support bare metal recovery to local and regional offsite storage on a regular basis, and has contracts in place for emergency server rentals in another region.
Often the cheapest option to maintain, operationally.
Often an expensive option to recover, because it requires that physical servers be configured correctly after a disaster has occurred.
Cons: The slowest option to recover.
Warm standby disaster recovery strategy: A business ships virtual server images to local and regional disaster recovery farms.
Pros: Often relatively inexpensive to recover, because a virtual server farm can require little configuration upon recovery.
Cons: Can be very expensive and time consuming to maintain.
Hot standby disaster recovery strategy: A business runs multiple data centers, but serves content and services through only one data center.
Pros: Often relatively fast to recover.
Cons: Can be quite expensive to configure and maintain.
No matter which disaster recovery solution you decide to implement for your environment, you are likely to incur some data loss.
Planning for cold standby data centers
In a cold standby disaster recovery scenario, you can recover by setting up a new farm in a new location, (preferably by using a scripted deployment), and restoring backups. Or, you can recover by restoring a farm from a backup solution such as Microsoft System Center Data Protection Manager 2007 that protects your data at the computer level and lets you restore each server individually. This article does not contain detailed instructions for how to create and recover in cold standby scenarios. For more information, see:
Planning for warm standby data centers
In a warm standby disaster recovery scenario, you can create a warm standby solution by making sure that you consistently and frequently create virtual images of the servers in your farm that you ship to a secondary location. At the secondary location, you must have an environment available in which you can easily configure and connect the images to re-create your farm environment.
This article does not contain detailed instructions for creating warm standby solutions. For more information about how to plan to deploy farms by using virtual solutions, see Plan for virtualization (SharePoint Foundation 2010).
Planning for hot standby data centers
In a hot standby disaster recovery scenario, you can set up a failover farm to provide disaster recovery in a separate data center from the primary farm. An environment that has a separate failover farm has the following characteristics:
A separate configuration database and Central Administration content database must be maintained on the failover farm.
All customizations must be deployed on both farms.
We recommend that you use scripted deployment to create the primary and failover farm by using the same configuration settings and customizations.
Updates must be applied to both farms, individually.
SharePoint Foundation content databases can be successfully asynchronously mirrored or log-shipped to the failover farm.
SQL Server mirroring can only be used to copy databases to a single mirror server, but you can log-ship to multiple secondary servers.
Service applications vary in whether they can be log-shipped to a farm. For more information, see Service application redundancy across data centers later in this article.
This topology can be repeated across many data centers, if you configure SQL Server log shipping to one or more additional data centers.
Consult with your SAN vendor to determine whether you can use SAN replication or another supported mechanism to provide availability across data centers.
The following illustration shows primary and failover farms before failover.
Primary and failover farms before failover
Service application redundancy across data centers
To provide availability across data centers for service applications, we recommend that for the services that can be run cross-farm, you run a separate services farm that can be accessed from both the primary and the secondary data centers.
For services that cannot be run cross-farm, and to provide availability for the services farm itself, the strategy for providing redundancy across data centers for a service application varies. The strategy employed depends on whether:
There is business value in running the service application in the disaster recovery farm when it is not in use.
The databases associated with the service application can be log-shipped or asynchronously mirrored.
The service application can run against read-only databases.
The following sections describe the disaster recovery strategies that we recommend for each service application. The service applications are grouped by strategy.
Databases that can be log-shipped or asynchronously mirrored
After a service application has been initially deployed on a secondary farm, the databases that support the following service applications can be asynchronously mirrored or log-shipped across farms:
Usage and Health Data Collection service application
It is possible to log-ship or mirror the Logging database. However, we recommend that you do not run the Usage and Health Data Collection service on the disaster recovery farm, and that you do not mirror nor log-ship the Logging database.
Service applications and databases that cannot be log-shipped or asynchronously mirrored
The following service applications must be deployed on both the primary and failover farms, and cannot be log-shipped or asynchronously mirrored. For most of these service applications, we recommend that you deploy them and then verify that the failover farm has the same configuration settings as the primary farm. If configuration changes that affect the service are made on the primary farm, you must update the failover farm.
Application Registry service application
Databases: Application Registry service
Log-shipping the Application Registry service database is not supported.
Business Data Connectivity service application
Databases: Business Data Connectivity
Microsoft SharePoint Foundation Subscription Settings service application
Database: Subscription Settings
Log-shipping the Subscription Settings database is not supported.
System requirements for disaster recovery
In an ideal scenario, the failover components and systems match the primary components and systems in all ways: platform, hardware, and number of servers. At a minimum, the failover environment must be able to handle the traffic that you expect during a failover. Keep in mind that only a subset of users may be served by the failover site. The systems must match in at least the following:
Operating system version and all updates
SQL Server versions and all updates
SharePoint 2010 Products versions and all updates
Although this article primarily discusses the availability of SharePoint 2010 Products, the system uptime will also be affected by the other components in the system. In particular, make sure that you do the following:
Ensure that infrastructure dependencies such as power, cooling, network, directory, and SMTP are fully redundant.
Choose a switching mechanism, whether DNS or hardware load balancing, that meets your needs.
July 29, 2011
Corrected information about the Application Registry service application.
March 3, 2011
Updated to clarify that we do not support asynchronous mirroring or log-shipping for the Business Data Connectivity database.
May 12, 2010