SharePoint Protection: From High Availability to Disaster Recovery

If you have deployed SharePoint or are still in the planning phases, you probably have an ideal SharePoint scenario in mind, one where your intranet becomes useful again; your end users collaborate using team sites; and information is both organized and searchable. Now imagine your phone ringing at 2 A.M. with a voice on the other end saying, “SharePoint is down.” You rush to the office to discover that your SharePoint server has suffered a massive hardware failure. Your SharePoint dreams may have just turned into a massive nightmare. As you get this sinking feeling, you’re asking yourself one question, “Did we back up SharePoint?”

Backups are a fundamental operational activity for any organization, and backing up SharePoint is no exception. Unfortunately, backup planning and implementation are often overlooked. This article explains how to protect your SharePoint environment and the data it contains. Even though you can’t always prevent disasters from occurring, you can take steps to ensure your data is protected and can be restored if a disaster does occur. Before jumping into setting up and configuring backups, it's worth reviewing some SharePoint protection options.

High Availability Options

Your first impulse may be to consider the options for high availability. But before listing the technical aspects of these options, you should understand that high availability protects you only against service disruptions due to server or application failures. High availability does not protect you from data loss. For example, if you choose to implement high availability for your SharePoint farm, a server failure would have little if any impact on your end users, who could continue working uninterrupted. In other words, high availability options keep SharePoint online when a server fails, with little or no disruption in service. But you will still need to implement a method to protect the data.

The Microsoft-supported way to ensure SharePoint high availability is to create a SQL cluster to host the SharePoint databases and create multiple load-balanced front-end web servers. Microsoft Clustering Services use an Active/Passive technology to provide high availability to applications such as SQL Server and Exchange Server. Microsoft Clustering Services requires at least two servers and shared storage such as a Storage Area Network (SAN) as shown in the bottom box in Figure 1. One server acts as the active node performing all the processing for the application. The other server acts as a passive server, simply standing by in case the primary server fails. If that happens, the passive or fail-over server immediately takes over processing.

After clustering your SQL Server, you will more than likely want to set up network load balancing between two or more web front-ends. After all, what good is a highly available database if the application on the front-end isn’t online? You can use a hardware load balancer or the Microsoft Network Load Balancing Service (NLBS) to provide high availability and load balancing between multiple web front-ends as shown in the top box in Figure 1. The NLBS option balances traffic between the multiple front-end SharePoint servers during normal operations. When servers go offline, all traffic is diverted to the server(s) still online.

The top box in Figure 1 depicts two web front-end servers set up with network load balancing. This scenario balances all web traffic between the two front-end servers. If one server fails, traffic would continue to be routed through the still-active web server.

With high availability in place, you can turn your attention to putting a solid data backup plan in place.