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.

SharePoint Data Protection

If you have already deployed SharePoint, it's not too late—just make sure you take action as soon as possible, because your SharePoint data is only as good as your most recent backup. Out of the box, SharePoint includes a couple of options for protecting the data. The first method is a three-step process:

1. Back up the SQL Content databases regularly. You can use native SQL tools or your SQL backup software of choice to perform regular backups of the content databases.
2. Restore the databases. When data loss occurs, the restore process involves first restoring the content databases onto the SQL Servers, and then recreating your SharePoint web applications with the same settings that were configured when the database backup was taken.
3. Re-associate databases with applications. Finally, you will need to associate the restored content database with the newly-created SharePoint web applications.

If you decide to use this backup method, you must make sure to document your SharePoint configuration thoroughly. It’s also important to include IIS configuration information in your SharePoint documentation.

The second built-in backup method involves using SharePoint's native backup tools. You'll find these tools in a "Backup" section within the Central Admin application, and there are also some command line utilities that you can script. The primary advantage of using the native SharePoint backup tools is that you they can backup and restore your entire SharePoint farm configuration. When you need to restore of the farm, you can perform a fresh install of SharePoint, and then restore data and configuration information straight from Central Admin or a script.

The native tools let you backup things you might miss using SQL backups, such as Shared Service Providers (SSPs) and search configurations. They also make it easy to choose which web applications, content databases, and configurations you want to backup.

Regardless of which method you select, you should perform regular restores to a test environment to check the backup plan. If you can’t restore the data, backups are useless. As you do so, document the entire recovery process, so that when a real emergency restore situation occurs, you won't have to guess which step to perform next. The SharePoint restore process is also a great way to build test and dev environments that mimic your production deployment. You can quickly configure and perform a backup of your entire farm or individual components by performing the following steps:

1. Log onto one of your web front-end servers.
2. Open Central Admin and select the Operations tab.
3. Click the "Perform a Backup" link (see Figure 2).
4. Select the components or databases you wish to backup. Then click the "Continue backup options" link.
5. Choose the backup type and location. Select a full backup to back up all of the selected components. Select a differential backup if you want to back up only the data that has changed since the last full backup was performed.
6. Choose a file share where you want to save the backup, and then click OK.

You can monitor the backup progress in the Central Admin console. After the backup completes, verify there were no errors.

Increase Safety with Offsite Data Replication

If your organization has a formal disaster recovery plan, you may replicate critical applications to a secondary data center. In the event of a disaster such as a flood or fire at the primary data center, you would fail-over to your secondary data center. You may want to include SharePoint in the list of applications to replicate to the secondary data center.

You can accomplish this using SQL log shipping to send the SQL transactions logs from the production SQL server to a stand-by SQL server in your secondary data center. Log shipping is a SQL server technology that copies transaction logs from one server to another—either on a local network or over wide area network (WAN) links. Log shipping is supported only for the content databases; therefore, in the event of a disaster, you will need to have a SharePoint farm set up in the secondary data center and manually configured to match the primary data center. Like your backup plan, you should thoroughly test and document the procedures as part of your SharePoint deployment. To setup SQL Log Shipping to provide disaster recovery, perform the following:

1. Setup a duplicate copy of your SharePoint farm at the disaster recovery (DR) site. Be sure to duplicate any customizations you might have made to your farm's configuration.
2. Take a backup of your content databases from your production environment and restore them to the DR site.
3. Setup SQL Log Shipping on content databases to send transaction logs from your primary SharePoint farm to the DR SharePoint farm. Keep in mind that the content databases in the DR farm are in read-only mode while logs are being shipped.

In the event of a disaster you would need to bring the databases out of standby/read-only mode and update your DNS records to point to the new SharePoint farm.

Planning for backups, availability, and disaster recovery is a critical step in deploying SharePoint. It’s also important to test and document these processes on a regular basis. You will sleep better at night knowing you have a well-tested SharePoint protection plan in place.

Useful Links

• Microsoft Office SharePoint Server 2007 Best Practices, by Bill English and Ben Curry, Microsoft Press, 2008.