A Replication Feature is NOT a Disaster Recovery Plan

A few years ago, I blogged that “your-replication-is-not-my-disaster-recovery/index.html" target="_blank" title="Jason's previous blog post on "Replication vs. Disaster Recovery"">Your Replication is not my Disaster Recovery” where I lamented that real BC/DR is much more about people/process than it is about technology.

To be clear, I am not bashing replication technologies or the marketing folks at those vendors … because without your data, you don’t have BC/DR, you have people looking for jobs.

But that does not mean that if you have your data remotely, you have a BC/DR plan. Having “survivable data” means that you have the IT elements necessary to either roll up your sleeves and attempt to persevere, or (preferably) the means by which to invoke a pre-prepared BC/DR set of mitigation and/or resumption activities.

BC/DR is not a “feature” or a button or a checkbox in a product, unless those elements are part of invoking the orchestrated IT resumption processes that are part of a broader organizational set of cultural and expertise-based approaches to resuming business, not just restarting/rehosting IT.

Replication needs to be part of every Data Protection plan, to ensure agility for recovery – and often to increase the overall usability/ROI of one’s data protection infrastructure by enabling additional ways to leverage the secondary/tertiary data copies. Replication, whether object-, application- or VM-based and whether hardware- or software-powered, is also the underpinnings of ensuring “survivable data.” Only after you have “survivable data” can you begin real BC/DR planning.

As always, thanks for watching.

Topics: Data Protection