Disaster Recovery Planning is the most important part of any technology implementation.
We all know that it’s important to have a Disaster Recovery Plan (DRP) in case of, well…, a disaster, but how many treat it as the MOST important part of the implementation process?
In order to take a DRP as seriously as you should you need to know the definition of a Disaster.
A disaster can be any moment in the life of a product in which there is unplanned downtime and/or loss of data.
That means that disasters are not just natural in nature. The most common disaster that occurs is due to human error. A good comprehensive DRP should address and prevent that type of disaster, in addition to the standard environmental disasters that can occur.
The organization I work for experienced a problem with our SharePoint 2010 environment earlier this spring which ended up costing us weeks of lost productivity, and I’m sure plenty of money. We spanned 4 continents of Microsoft support personnel to finally find a resolution and we still fear there are lingering issues due to the poor DRP.
I was brought on a few months prior to our disaster so I wasn’t fully aware of the impending doom looming over us. Our DRP was nearly non-existent. It consisted of ideas, but none of which had been tested or documented.
I have now been charged with developing a comprehensive DRP for our SharePoint 2010, Project Server 2010, and Team Foundation Server 2010 environments. All of which have parts that live on the same SharePoint 2010 environment which causes some interesting issues in the DRP planning.
Over the next couple of posts I plan to break down the Planning and Implementation of a SharePoint 2010 DRP. By the final post I should have a Disaster Recovery Plan template you can download and use as you like.
Stay tuned for more info on SharePoint 2010 Disaster Recovery Planning.