On Thursday, March 18th I’ll be presenting on SharePoint 2010’s Personalization features for the Sandhills SharePoint User Group in Fayetteville, NC. While the group is relatively new, I know there is strong interest in SharePoint so I look forward to the opportunity to present on one of my favorite topics. I look forward to seeing everyone there!
Additional details can be found on the group’s site here.
Today I put the finishing touches on a SharePoint Disaster Recovery presentation I’ll be delivering at the Triangle SharePoint User Group meeting this week. Part of the presentation goes into the regular technical aspects of backing up and restoring SharePoint, but the second half goes into how I approach a Disaster Recovery plan.
Prioritize Your Content
Not all sites, nor all types of content are the same. In environments where I have seen SharePoint been very successful, it was successful because it was used to manage or store business critical content. When looking at any medium to large implementation, 100GB+ of content, it really pays to spend some time working with the business to prioritize the content so that a restore sequence can be established. Getting the most critical content back online will likely buy you some time and ease the pressure while you work on the rest of the content.
When you practice your recovery, be sure to practice it based on your recovery sequence to validate that it can be executed in that order and that you are not overlooking any dependencies.
Track Customizations and Solutions
I’ve mentioned a few times in the past how important it is to keep a running list of all the customizations in place along with the actual solutions or install files. If you have to rebuild the environment this is crucial to getting the system back in working order. Review the list regularly and be sure to save it to separate media since keeping it on the SharePoint server may not help you much during a catastrophic failure.
Identify Multiple Recovery Paths
There are different types of failures, and the same path isn’t appropriate for each. In addition, sometimes unknowns come up that either complicate or block the desired recovery path. It is always a good idea to have a secondary recovery path. When it comes to Disaster Recovery, redundancy is a very good thing.
Know Your Restore Rate
It is important to know who long it will take you to restore the systems. Base the rate on actual tests, not on the stated rate of a given network or tape technology. If the company has a DR agreement with a facility like Sun Guard it would be a good idea to also include both the expected rates for your home facility as well as the disaster facility. Once the restore rate is established it can be used for ongoing planning as your contend databases grow.
It also pays to set a worst case scenario rate. If the entire data center had to be restored or rebuilt and every tape machine is in overdrive and the network is saturated you are not going to see the same performance that you will when just recovering a single system.
Ensure the Plan Meets the Business Objectives
All of this planning is to ensure that you can recover the system in a way that can get the business back up and running. Be sure to get validation on the recovery plan and do not make assumptions. If the business really does require quicker recovery times there may be justification for additional tools to help speed up the recovery process. The cost of those tools is typically negligible when compared to the cost of business interruption.