Your Replication is not my Disaster Recovery

[originally posted on my ESG blog – TechnicalOptimist.com]

It wasn’t that many years ago that ‘Disaster Recovery’ was a key buzz word for IT.  Somewhere along the way, it became ‘Business Continuity’.   Now days, it is simply a feature of your backup or storage solution.  Or is it?

First, let’s talk through the layers from a technology perspective:

Backup & Restoration (B/R)

B/R is about previous versions.   On disk, there is an expectation around either rapid recovery – or end-user initiated without helpdesk interaction.  Each are good, both are better.  On tape, it is all about long-term retention (only).   If you are still using tape as a primary means for data restoration or whole-server recovery, then …

High Availability (HA)

HA is about staying running.  It used to be about ‘failover’, where warm resources would come online when the primary failed – but these days, HA scenarios rarely miss a beat, because most have figured out how to combine load-balancing methods with HA, whereby when everything is fine, it is shared across devices so that load is optimized.  When something fails, the other nodes of the configuration take up the extra slack and the user is never the wiser.   An example being Exchange DAG or SQL Mirroring within the application or a web-farm.

Disaster Recovery (DR)

DR is about data survivability over distance.  In olden days, this would then be followed with the IT and personnel processes to bring the data and services online again from the remote location.  But the key, then and now, is that DR from a technology perspective is about data survivability – achievable through the application (e.g. SQL replication), the host (e.g. Windows DFS-R), from a backup application (Microsoft DPM) or the storage array.

Business Continuity (BC)

Simple math:  BC = DR + HA … +/- B/R

Said another way: BC is remote (DR) resumption (HA) of services, ideally either transparently resilient or automated such that the decision is manual but the execution is programmatic, with the option of optimized backups (B/R) from the remote site.

Your Remote Replication feature is not my Disaster Recovery

All of the above is from a technology perspective, which is nice and probably worth more detail in another blog post as to what makes offerings in each area desirable, but … there is at least one flaw in the above descriptors.   The ‘Remote Replication’ feature in your technology does NOT really equate to DR or BC.

Marketing guys are taught to use action verbs.  So while your remote replication feature may genuinely ‘help you with your disaster recovery goals’, many marketing guys (including me in my past roles) shorten it as ‘does disaster recovery’.  And somewhere along the way, product developers listen to the marketing guys and product managers, and then the feature or button in the product becomes ‘Disaster Recovery’.  But it isn’t!  Because real BC/DR isn’t about technology – its about processes and people.

For all of the IT Pro’s who are certified in this technology or that, there is a certification for BC/DR – so let’s look at their defined ‘Professional Practices’ for Business Continuity Planning at www.drii.org/certification/professionalprac.php:

1. Program Initiation and Management
2. Risk Evaluation and Control
3. Business Impact Analysis
4. Business Continuity Strategies
5. Emergency Response and Operations
6. Business Continuity Plans
7. Awareness and Training Programs
8. Business Continuity Plan Exercise, Audit & Maintenance
9. Crisis Communications
10. Coordination with External Agencies

The punch-line here is that all of the IT technologies and methodologies are applicable to roughly 4 of the 10 aspects of real Business Continuity Planning.

Putting it all together

Are the ‘Disaster Recovery’ features in backup and storage technologies bad?  NO, but take them for what they are.  Storage that is replicated to a secondary site doesn’t help you with disaster recovery unless its only function is a file server.  Unless you also have the ability to bring the services back online, and reconnect the users, and report its restored availability, then it isn’t BC or DR, its RR – Remote Replication.  

I won’t say “its is only remote replication” because RR is the secret sauce for ensuring data survivability.  And without your data, most of the 10 phases of “real” business continuity planning won’t matter.

The first words and the last words in my book are “Get Your Data Out of the Building” – and remote replication is how you do it.   In fact, chapter 12 of the book is around 40 fun-filled pages on how to make BC/DR work within a BCP framework and also how all of it applies to regulatory requirements.

So, embrace Remote Replication (RR) – just don’t call it ‘Disaster Recovery’ or expect it to entirely solve your Business Continuity goals by itself.

 

Disclaimers: 

• Yes, as a former (and recovering) marketing guy, I have shortened out the ‘helps’ and ‘may’ phrases for BC/DR technologies.
• Yes, I have been a Certified Business Continuity Planner (CBCP), as well as an IT Pro (MCSE and Novell MCNE).
• Yes, these are simply my opinions and yours may be different.

Thanks for reading.