Freigeben über

SharePoint Server 2010 - 10 Steps to Disaster Recovery

  • Artikel

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):

clip_image002

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:

clip_image004

James Kemp
Consultant
Microsoft Consulting Services UK
James.Kemp@Microsoft.com

Click here to see my bio page

DR Diagram - Visio.zip

Comments

  • Anonymous
    August 31, 2011
    The comment has been removed

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

  • Anonymous
    September 01, 2011
    This is a great post. This helps me to update/modify my current SharePoint 2010 Disaster Recovery document. Thank You .

  • Anonymous
    September 01, 2011
    This is a great post. This helps me to update/modify my current SharePoint 2010 Disaster Recovery document. Thank You .

  • Anonymous
    September 01, 2011
    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.

  • Anonymous
    September 01, 2011
    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  :-)

  • Anonymous
    September 01, 2011
    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? Terry

  • Anonymous
    September 01, 2011
    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

  • Anonymous
    September 19, 2011
    The comment has been removed

  • Anonymous
    November 27, 2011
    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="www.sharepointengine.com/"><b>Sharepoint Consulting</b></a>

  • Anonymous
    May 09, 2012
    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.  

  • Anonymous
    August 26, 2012
    Thank you!

<a href="http://salaudeen.blogspot.com"> Salaudeen Rajack's SharePoint Diary </a>

  • Anonymous
    October 25, 2012
    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 :-)?

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

  • Anonymous
    February 21, 2013
    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.

  • Anonymous
    January 27, 2015
    Good information, thanks for sharing.