When the worst happens: SharePoint recovery

Current Job Listings

SharePoint has become vital to the business infrastructure and, in many companies, it's even used as the company's face to the world: its public facing website. Because of this dependency and high visibility, a well-thought-out disaster recovery strategy for SharePoint is imperative.

Three types of disasters can impact SharePoint:

• Content deletion -- the most likely type of disaster to occur; happens when a user simply deletes some content that they, or someone else, needs.

REVIEW: 10 things we love about SharePoint 2010

• Machine failure -- when farm and environment are working and stable, but a single machine has failed. Machine failure disasters (unlike content deletion) affect the entire SharePoint user base.

• SharePoint farm failure -- the worst type of SharePoint disaster; takes the whole facility hosting your SharePoint farm offline. The cause could be anything from a lost Internet connection to a natural disaster, but the result is that SharePoint is unavailable to everyone, which directly affects the business.

The impact of each type of disaster can differ significantly. A content deletion disaster usually is a localized event that doesn't affect business continuity. Machine failure disasters may or may not have a noticeable impact on business continuity, depending on which server failed and how its services are used, so it's important to know how your company uses SharePoint when planning your disaster recovery strategy.

The loss of the entire SharePoint farm is disastrous for almost all companies. Farm loss can cost the organization thousands of dollars an hour in lost wages and revenue, so keeping SharePoint properly protected is paramount to keeping the business running.

Developing a DR plan

Before you develop your DR plan, make sure your service level agreement covers two aspects of disaster recovery: the Recovery Point Objective (RPO) and the Recovery Time Objective (RTO). The RPO defines the amount of data that acceptably can be lost, from a certain point in time. The RTO, on the other hand, defines how long it will take to get recovered content back to the user. The RTO is separate from the RPO, but both affect the end user.

A backup strategy is the foundation for any DR plan, and should start with a method for backing up your content databases. If you also have external SharePoint content, backing up your content databases alone won't be sufficient. SharePoint 2010 supports two methods for storing binary content in locations outside of SQL: the older External Blob Store (EBS) and the newer Remote Blob Store (RBS).

EBS support in SharePoint really only affects upgrades from SharePoint 2007, while RBS is the method SharePoint 2010 administrators use on new farms. Hooks built into SharePoint support the RBS functionality, but the product itself doesn't do it. You will need a third-party RBS solution if you want that functionality.

Besides backing up content, you also need to be able to recover that content when it's needed. Practice your recovery routine periodically to make sure it's solid and all the moving pieces work correctly. This gives you a heads up if any of the process has broken, and makes an actual disaster seem less disastrous when it actually happens.

What your SharePoint recovery tool should include

Once you have a good SharePoint disaster recovery plan, the next step is to determine the tool you need to facilitate the plan. SharePoint includes several out-of-the box DR options, but you will quickly outgrow them as your farm grows.

SharePoint enables you to export the content of individual sites, which can be helpful for content disasters, but is not enough to address other types of disasters. SharePoint 2010 also has native support for backing up site collections, which will protect content and some settings, but does nothing to protect against machine or farm failure.

SharePoint includes the ability to do full farm-level backups for things like content, configuration, solutions and service application information. These backups can be coupled with another feature -- unattached content database recovery -- to recover content down to the individual list or library, and can be used to restore an entire farm.

Since this approach backs up entire databases and service applications, it can be used to restore individual components if a machine or drive fails, and could potentially be used to recover a farm in a different location if the primary facility goes down. But, because an entire restore is required after the primary fails, bringing the recovery farm online takes a long time. Plus, the farm-level backups don't back up 100% of a farm's settings, so some extra work is still needed to complete a restore.

To top it all off, none of the out-of-the-box SharePoint backup solutions have native support for scheduling or monitoring. They may work for small farms, but aren't robust enough for mission-critical SharePoint installations. For those, you will need a third-party tool to protect your farm.

How do you choose? When you consider prospective software for your DR plan, focus on your restore strategy, not your backup strategy. Every company's needs are different, but some considerations for evaluating third-party backup and restore software include:

* Does your current backup vendor have a SharePoint solution? If you already use a third-party product to back up Exchange, SQL Server or file servers, that vendor may also offer a capable SharePoint aware backup product. Running all your backups in one console reduces the chance something will be overlooked, and configuring the SharePoint backups will be easier because you're already familiar with the backup software. It will be easier to perform a recovery, and, if you bundle your licenses, this may be the least expensive approach.

* Can the recovery tool use your existing backups? A third-party product shouldn't require duplication of your backup activities; one backup of SharePoint should meet all of your disaster recovery needs. Besides ensuring the tool can use your existing backups, learn whether it also can schedule your existing backup tools to run.

* Does the recovery tool index and search your backups? Make sure the recovery tool you choose provides indexing and search capabilities that enable a quick search based on full or partial file names, file extensions and backup times. A really good recovery tool also will save the indexed backups so you can offload older backups to tape drives and cheaper storage, and still identify the backup containing the item you need.

* Does the tool provide preview functionality? In the case of content deletion, or to quickly restore a single item when SharePoint is offline, your tool should allow you to preview the document before you restore so you can avoid performing the same restore over and over again. You should to be able to find the document, preview it, and perform the restore function just once.

* Does the tool do full farm restores? Content recovery is the most likely disaster scenario, but, at some point, you may need to restore your entire farm. Your tool should offer high-fidelity farm-level restores of content, services and configuration settings, and should restore the farm from the same content and configuration database backups made by your existing backup tools.

* Does the tool allow you to restore the content anywhere? A good third-party SharePoint recovery tool should allow you to restore your documents and lists to any place you choose, free of the constraints of SharePoint. It should allow you to restore items to a new site, your desktop or a file share. Many third-party products bolt into SharePoint directly, and have their own complicated servers and databases. Evaluate how much infrastructure is required to recover content. You should be able to quickly recover important documents without having to completely rebuild SharePoint, then install and configure the third-party product. Ideally, your tool should recover data quickly with SharePoint offline, directly from your backups.

Even though SharePoint is a superstar Web application, it still needs help to keep running and, sometimes, to bring it back from the dead. Armed with the knowledge of disasters that may befall your environment, you can plan your defense against them. With a good disaster recovery plan in place, you can protect your users from unforeseen disasters that may hurt your organization's productivity.

Klindt, of SharePoint911, is a consultant to Quest Software and Microsoft MVP. He has worked in the IT industry for 15 years, and specialized in SharePoint for the last six. He has written several magazine articles and books on SharePoint, including his latest book, "Professional SharePoint 2010 Administration." He chronicles his SharePoint adventures on his blog, http://www.toddklindt.com/blog.

Read more about data center in Network World's Data Center section.

This story, "When the worst happens: SharePoint recovery" was originally published by Network World.

5 collaboration tools that enhance Microsoft Office
Shop Tech Products at Amazon