Black Swans, Disaster Recovery, and DRaaS

Black swans in the context of backup and disaster recovery aren’t angry birds.  Black swan theory is – well, let’s use Wikipedia to explain…

The black swan theory or theory of black swan events is a metaphor that describes an event that is a surprise (to the observer), has a major effect, and after the fact is often inappropriately rationalized with the benefit of hindsight.

(Note: If you get a chance, I really recommend the book “Antifragile: Things that Gain from Disorder” by the originator of black swan theory – Nassim Nicholas Taleb.  He doesn’t have the most conventional writing style and some of his phrasing is tortuous, but the ideas are absolutely fascinating.)

In disaster recovery, one of the core problems are unexpected events.  Here’s one way to think about it using black swan theory – a lot of disaster recovery assumes disasters based on historical occurences of disasters rather than on an open-ended examination of potential disasters scenarios.

That leads to a really good article by Matt Prigge over at InfoWorld: The Challenges of Disaster Recovery as a Service. (Warning: You’re going to have to give them your e-mail address to read the whole thing.)  After explaining what DRaaS is, Matt talks about the fundamental requirements of having DRaaS work.  Matt goes through some of the challenges to making sure your infrastructure can work in a cloud.  He concludes with the following sage advice:

Many organizations that desire warm-site functionality will find it cheaper and easier to use DRaaS than to design and build their own warm-site data centers. However, just because someone else is handling the work of ensuring your data is replicated off-site and can be recovered does not free you from the preparation, planning, and testing that would normally accompany a warm-site buildout.

And therein lies the tie to black swan theory.  Anyone using DRaaS in a public cloud absolutely has to engage in the same level of planning and even more preparation and testing than if you are performing disaster recovery in a private cloud (a second premise, etc.)  There’s absolutely no way around performing the planning – and the correct way to plan is to use not only past historical records of disaster but to be creative around disaster scenarios that have never occurred – but might.

Got any sage disaster recovery advice of your own – either theoretical or won through hard-won experience?  We’d love to hear from you about it.