- 0 Comments
- May 30, 2014
- by David Lohnes
- disaster recovery, SharePoint,
- Leave a comment
In my last post, we took a look at why every production SharePoint farm urgently needs a tested disaster recover plan. Beginning with this post, we’re going to take a look at the three SharePoint DR options that Microsoft lays out and consider the advantages and disadvantages of each.
The first option is what Microsoft calls “Cold Standby.”
Microsoft describes a Cold Standby DR procedure as follows: “In a cold standby disaster recovery scenario, you recover by setting up a new farm in a new location, (preferably by using a scripted deployment), and restoring backups.”
Cold Standby is the basic DR strategy that is available to everyone by default. That is: If it breaks, start over.
If a cold standby DR model is adopted, the response to a disaster would be to build an entirely new farm on new servers. Anyone who can build a SharePoint environment to begin with can build it again if necessary. However, in a DR scenario, two considerations in particular must be prioritized:
- The rebuild must be completed as quickly as possible to restore service to users
- The rebuild must be made as close to identical as possible to the original farm to ensure seamless continuation of business processesTo achieve these two priorities, a properly realized Cold Standby DR plan won’t simply rebuild completely from scratch without prior preparations. Instead, a proper Cold Standby DR plan will utilize an array of preparatory actions which will in the event of a disaster both speed the rebuild time and significantly decrease the likelihood of differences from the old farm.Preparatory actions include:
- VM templates should be prepared ahead of time to ensure quick creation of suitable server VMs.
- Install scripts, SharePoint install and patch binaries, SSL certs, .wsp solutions, 3rd-party tools and licenses, and all other functional add-ons and customizations to the farm should be gathered ahead of time, each with a verified install procedure; all of this is to ensure the quickest possible creation of a new farm with the same functionality as the old.
- The complete rebuild procedure, including VM setup, SP and customization install, content restore, and DNS and other necessary changes should be practiced repeatedly and well documented so that all necessary resources understand their role and have experience executing it.
If all these preparatory steps are taken, a Cold Standby DR plan can be a sufficient DR strategy for an Enterprise SharePoint farm. Without these preparatory steps, it doesn’t really qualify as a DR plan. Unprepared Cold Standby is really just starting over from the beginning—a very time consuming process that may lack sufficiently reliable results.
- Probably cheapest Microsoft supported DR strategy. Minimal DR readiness maintenance activities, and no extra licenses to purchase.
- Has a high flexibility and low chance of failure (assuming proper preparations are made)
- Probably slowest Microsoft supported DR strategy
- Probably requires more “hands-on” capable SharePoint admins than other Microsoft-supported strategies
- Highest risk of a restored farm that is out of sync with the original
- Does not offer any “fail back” option in the event the original farm is brought back online.
This final point in the list of cons is one of the most important. Given enough leeway in your SLA and enough practice and preparation beforehand, Cold Standby is a perfectly acceptable and reliable approach to SharePoint DR. But it’s a one-way ticket. There is no failback without doing the same thing over again. For situations where DR is in response to a corrupted database and you’re rebuilding in the same datacenter, this limitation is probably fine. But if your recovery has been to a secondary datacenter, and you hope to fail back once the primary is back online, then the lack of failback options can become an important consideration.