Data replication options - Part Two (Application-based replication)

At the top of the IT stack lies the application.  This is what the end-user interfaces with and what you're most likely to hear "is down" in the event of an outage.  Since the application is what you're actually trying to protect against a disaster it makes a great deal of sense to leverage any built-in options for data replication.

And luckily applications have added built-in replication as the importance of disaster preparedness increased.  A few brief examples:

Oracle offers Data Guard for their RDBMS.  While this solution could have been considered simply log shipping in the past, today they position it as a complete disaster recovery solution.

For the popular Exchange Server, Microsoft offers Cluster Continuous Replication (CCR), while for SQL Server there are options both for log shipping and transactional replication.  A more detailed discussion of the SQL Server options is available here.

If you define "application" broadly enough to include infrastructure services, then there are typically options there as well.  DNS, LDAP, and Active Directory are all architecturally designed so that they may be deployed in a fashion that is redundant across multiple sites - the key is to recognize the need for this redundancy, deploy appropriately, and test.

Given that the application is what we're trying to protect, then why doesn't everyone just rely on application-based replication?  Well, there are a couple of considerations:

First of all, most environments have multiple applications that they're trying to protect against a disaster.  In the same way that the real test of a backup is whether or not you can restore, the real test of a disaster recovery solution is whether or not you can recover.  When you use an application-based replication solution then when a disaster happens you have to have a person available at the remote site who knows enough about the application to perform the necessary steps to bring it online.  If you're only running one application (if you're a Software as a Service provide, for example) then that's great.  You have the necessary resources for that one application.  As you start putting more and more applications into the mix, though, the probability that you won't have the right resource available in the event of an emergency increases.

A second reason is that leveraging application-based recovery couples your disaster recovery solution with the support matrix of the application.  This means that as time progresses and the application move through its life cycle you have to include the replication in your considerations.

To summarize:

Pros:

• Protects the environment at an easily understandable level.
• Typically cost-effective.
• No concerns around application support (as it is part of the application).
• Often includes testing for logical corruption (which other approaches cannot).

Cons:

• Increased complexity in environments with multiple applications, decreasing the probability of successful recovery of an entire environment in a disaster.
• Couples replication to the application, meaning that application maintenance and upgrades must include testing and validation of replication.

Data replication options - Part Two (Application-based replication)