Preparing for Your Worst Nightmare: Disaster Recovery for Sharepoint 2010

SharePoint 2010 is the newest version of Microsoft's popular business collaboration platform. Its many new features and capabilities make upgrading to SharePoint 2010 a must for organizations that need to publish content, facilitate collaboration and manage project workflows.

But before you take the leap, you need to know what you're getting into: As your business grows, your SharePoint infrastructure will grow with it, and many organizations that deploy SharePoint see their business processes become dependent upon it. For that reason, you want to be thoroughly prepared for disaster recovery. Besides the usual business continuity best practices, such as storing backups offsite and keeping documentation up to date, here are seven tips you should follow when planning a disaster recovery strategy for SharePoint 2010.

Start with Redundancy

The more redundancy you build into your SharePoint infrastructure, the less worry you'll have when a disaster occurs. You should begin planning for redundancy before you install SharePoint — or better, before you even purchase the servers you'll install SharePoint on. For example, always buy servers with redundant power supplies, hot-swappable hard drives, and other high-end features. Then use failover clustering to make critical servers highly available. Use SQL Server database mirroring to maintain identical copies of SharePoint databases on different servers. Deploy multiple web front-end servers so users can access content if one server goes down.

Set Priorities

In a SharePoint farm, some things are more important than others. For example, in addition to the content on your sites, most SharePoint configuration settings are stored in SQL Server databases, so backing up your SQL servers should be your No. 1 disaster recovery priority. If your organization has a separate database administrator, you'll need to coordinate backup of the SQL instances that host your SharePoint content. Second on the list of backup priorities is the server hosting your Central Administration Web application; if a service outage takes down your entire farm, that's the server you'll need to bring online first. Once you have this server back online, you can use it to reconnect to your SQL Server database instances and continue the restore.

Leverage Granular Backups

A new feature of SharePoint 2010, granular backups, allows you to create backups of individual site collections, sites, libraries and lists; for example, you can use the Central Administration interface to back up a specific SharePoint site collection (see Figure 1). This capability to perform granular backups in addition to the regular full and differential backups of your entire farm provides you with additional flexibility in designing your SharePoint backup and restore strategy.

Figure 1: Backing up a site collection using the Central Administration interface

Switch to Windows PowerShell

You can still schedule regular backups by using the STSADM command, familiar from previous versions of SharePoint. New in SharePoint 2010, however, is a SharePoint PowerShell provider that gives you hundreds of Windows PowerShell cmdlets specifically designed for managing virtually every aspect of a SharePoint infrastructure. Using the SharePoint 2010 Management Shell, you can run PowerShell scripts that back up your entire farm, your farm configuration only, or individual site collections. You can also export individual sites, subsites, libraries and lists; restore backups; and import exported items. For example, the command BACKUP-SPFARM –DIRECTORY UNC_PATH –BACKUPMETHOD FULL can be used to perform a full backup of your entire farm to a network share, while appending the –ITEM parameter to this command lets you back up individual portions of your farm such as content databases or web applications. Once you've learned to manage SharePoint using PowerShell, you'll never go back to STSADM again.

Recycle Bin Squared

Disasters come in all sizes. To an administrator, a server going down is a headache that needs to be dealt with immediately. To users, however, accidentally deleting a file can be a disaster that involves hours of lost work. Previous versions of SharePoint, going back to Windows SharePoint Services 3.0, have included a Recycle Bin that allowed both users and administrators to quickly recover deleted items. New in SharePoint 2010 is a two-stage Recycle Bin which stores files that have been emptied from users' recycle bins. This provides administrators with a quick way of recovering files that users have "permanently" deleted without the need of performing a complex restore-from-backup operation. By default, when a user empties items from their own Recycle Bin, the items are moved to the second-stage Recycle Bin and stored there for 30 days longer (see Figure 2). To keep the second-stage Recycle Bin from growing too large, you can change this retention setting and the amount of disk space reserved for deleted files.

Figure 2: Configuring the two-stage Recycle Bin in SharePoint 2010

Don't Forget the Other Stuff

Don't be deceived into thinking that by using the Central Administration interface or PowerShell to perform a full backup of your entire farm that you can rest easy at night. That's because typical SharePoint environments are customized over time in different ways. For example, you may need to add an additional host header to Internet Information Services (IIS) on your web front-end servers. If you do so, you'll need to start backing up your IIS configuration on these servers, which are XML files found in the %WINDIR%\SYSTEM32\INETSRV\CONFIG folder on these servers. And if you install any custom code or third-party web parts on your web front-end servers, then you should back these up as well because this stuff is not included when you perform a full backup in SharePoint.

Look but Don't Touch

Read-only content databases, another new feature of SharePoint 2010, can take some of the pain out of recovering from a disaster. Using SQL Server Management Studio or the ALTER DATABASE command of T-SQL, you can configure a SharePoint content database so that users can access it online, but can't modify any of the content stored in it. You can even create an entire copy of your farm that's read-only and maintain it as a kind of hot-spare farm so that when your main production farm is being updated users can access the read-only copy. Just be sure not to make your Central Administration database read-only.