Skip Links

When the worst happens: SharePoint recovery

By Todd Klindt, SharePoint911/consultant to Quest Software, special to Network World
June 07, 2011 12:13 PM ET

Network World - 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.

Our Commenting Policies
Latest News
rssRss Feed
View more Latest News