SharePoint Server 2010 – 10 Steps to Disaster Recovery

This article aims to help anyone creating a Disaster Recovery (DR) design/strategy for SharePoint Server 2010. This advice will be based on my experience of designing a DR model and after conversations with experts such as Spencer Harbar, Microsoft IT and SharePoint Online.

Step 1. Do Some Research

Read articles like this. It will only take you 10 minutes but should provide a good background to DR in SharePoint 2010.

Step 2. Define What DR Means

Agree with your stakeholders what is meant by “DR”. For example, does it mean making all content databases available when an entire sever farm goes down? If so, make this explicit and get people to agree to it. Call out things like one WFE server dying as NOT DR, but instead something else such as a “critical failure”. You then know what you’re actually trying to design for.

Step 3. Define Recovery Point Objective (RPO) and Recovery Time Objective (RTO)

RPO refers to acceptable amount of data loss measured in time. As an example, your customer may want “to only lose the last 1 hour’s worth of data in the event of a disaster”.

RTO refers to the duration of time and a service level within which a service must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. As an example, a customer may ask for “the service must be up and running within the DR environment within 8 hours”.

Step 4. Prioritise Your SharePoint Data in DR Terms

This is where it gets interesting. You should be able to download this spreadsheet I created. Within the spreadsheet I’ve tried to capture all of the different types of content that would exist within a SharePoint Server 2010 farm. You’ll notice, there is potentially a lot of different types of data to DR and I’d wager you won’t DR all of it. Therefore, I would advise categorising this in accordance with what your customer deems as High/Medium/Low importance. There is a column in the spreadsheet to allow you to enter this info. It is based on this you will later decide what to DR. This may also influence your logical and physical drive designs (i.e. you may split content out depending on if it’s going to be recovered or not).

Step 5. Work Out the Size of Your Data.

The spreadsheet I created also consolidates this list of SharePoint 2010 databases and sizes (an excellent article). I’d advise modifying my spreadsheet inline with what your customer will have. For example, the size of the content databases will obviously vary between customers which in turn will impact log sizes etc. Same goes for things like User Profiles etc.

Step 6. Work Out the Bandwidth and Latency of Your Network Connections

As articles such as this note, the typical options for DR is to use log shipping or asynchronous mirroring, both of which require data to be sent over the network from your “live farm” to your “DR farm”. So, it’s a good idea to work out the bandwidth of your network connections and the latency. This will inform decisions on what data you can actually send.

Step 7. Realise What’s Supported and Not Supported in Terms of Data Replication

My spreadsheet tries to show what the Microsoft stance is on replicating SharePoint Server 2010 data. You’ll notice that for some db’s Log Shipping is supported, but asynchronous mirroring isn’t (and vice versa). Therefore, you probably can’t just use one replication technology. Worth keeping this in mind.

Step 8. Learn from MSIT, SharePoint Online and Others

Before finalising on a DR strategy it’s probably worth taking a minute to ask “Well, what do Microsoft do then?”. It doesn’t mean you have to copy what they do, as it’s not going to be applicable in every scenario, but it should be a useful reference point. After speaking to some guys in SharePoint Online and Microsoft IT, I learned that:

· Both have a “live farm” and “DR farm”

· Both only send Content Databases over the wire from the “live farm” to the “DR farm”

· Both use DFSR in combination with log shipping to send data over the wire. This reduces the size of files sent and gives flexibility in terms of when data is replicated

· Powershell scripts are used to automate configuration of Service Applications. This means that the “live farm” and “DR farm” are always matching in terms of configuration. It also avoids sending service application data over the network

Step 9. Decide What to DR and How to DR

This is where it should all come together. By now you should know what data is important, how big the data is likely to be, how big your network connections are and what replication options are available etc. You should now be able to start designing a DR model. An example model, is below (it’s also in a zip file attached to this post):


Step 10. Test, Deploy, Monitor and Re-design accordingly

As we all know, the lazy option is to do the design, give it to someone else and then not worry about it. However, it’s probably a better idea to test the DR model you’re proposing and once it’s deployed keep an eye on it and re-design where need be. As an example, if the content databases grow five times larger than you anticipated then you may want to re-evaluate things.

I hope the above provides some interesting food for thought!

This article was authored by:


James Kemp
Microsoft Consulting Services UK

Click here to see my bio page

DR Diagram –

Comments (16)

  1. Steven Andrews says:

    Thanks for posting this article, it's a great help with some work I've got lined up with my internal SharePoint deployment.

  2. Aryan Nava says:

    This is a great post. This helps me to update/modify my current SharePoint 2010 Disaster Recovery document.

    Thank You .

  3. Aryan Nava says:

    This is a great post. This helps me to update/modify my current SharePoint 2010 Disaster Recovery document.

    Thank You .

  4. Russell Swainston says:

    Thank you for this post, I am currently using Sharepoint 2007 but will be moving to 2010 as soon as i'v had some training and this DR doc will be great.

  5. Sean McDonough says:

    Fantastic post, James; thank you for sharing it! I liked that you managed to hit so many of the important points in such a succinct fashion. As a quick "DR tour" goes, I'll definitely be bookmarking this page and referring others to it  🙂

  6. Terry Cornwell says:

    Nice article James. Always useful to read up on this stuff. One thing I would ask though. Many clients I am talking to these days are looking to SCDPM for their DR requirements. With regards to SCDPM what sort of impact would this have on your planning article?


  7. Hi James, great post and thanks for sharing. It's always good to have quick and clear reference guides for such complex subjects. Many Thanks

  8. Yousef Omar says:

    This is SharePoint DR in a nutshell. Useful information and the DR components sheet is handy. Thanks

  9. Madison says:

    Thanks for taking the time to discuss this, I feel strongly about it and love learning more on this topic. If possible, as you gain knowledge, would you mind updating your blog with extra information? It is extremely helpful for me.

    <a href=""><b>Sharepoint Consulting</b></a>

  10. Kanwal says:

    Thanks James. .Your DR model is a really useful way to ensure all data items are considered at the design stage rather than when its too late during a test.  

  11. Sal says:

    Thank you!


    <a href=""&gt; Salaudeen Rajack's SharePoint Diary </a>

  12. Hilton Giesenow says:

    Hi James,

    This is a great overview – I often refer back to it when I want to check something quick on DR, especially the Excel doc. Any chance you're going to update it for SQL 2012 AlwaysOn :-)?

  13. Marek Samaj says:

    Hi Hilton, glad to hear you like the article! We plan to update it for SharePoint 2013 / SQL Server 2012, stay tuned!

  14. santosh kanase says:

    Nice Artical James, I want to know what abt SharePoint Core database like config and Admin DB can we restore it , as per MS guidlline it can't support , so what is option to restore it , it.e using Sharepoint Farm Backup ? pls let me know .. if we can't restore those DB will it work in DR Farm

    pls let me know . Thanks.

  15. Good information, thanks for sharing.