The Rise and Rise of the Recovery Consistency Objective

[vc_row][vc_column][vc_column_text]Timing, as comedians say, is everything. It’s true if you’re on stage entertaining an audience.

It’s also true if you’re trying to recover from IT disaster situations involving multiple systems that pass data between one another.[/vc_column_text][vc_single_image image=”1947″ img_size=”full” alignment=”center” image_hovers=”false” lazy_loading=”true”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]In complex configurations with different intercommunicating systems running CRM, ERP, business intelligence, and process integration, one system going down can have a global impact on data consistency.

The correct use of the recovery consistency objective or Recovery Consistency Objective, and understanding of timing issues, can help you recover data and consistency in the best way possible.

A quick refresher on Recovery Consistency Objective may be in order. Arithmetically, we define Recovery Consistency Objective as “one, minus [number of inconsistent systems/total number of systems]”.

A little mental juggling of the possibilities shows that Recovery Consistency Objective can vary between a maximum of one (totally consistent) and a minimum of zero (totally inconsistent).

Recovery Consistency Objective (applying to the group of systems) and RPO (recovery point objective, per individual system) may need to be balanced, one against the other, for an overall acceptable compromise.

There are three basic timing options, when one system in a collection of systems goes down, each one offering different possibilities for RCP and RPO.

  1. Recovery restricted to the system that crashed. You restrict data loss to one system (good for the RPO of the others), but may risk the biggest number of inconsistencies (bad for RCO
  2. Recovery for all systems from the same point in time. Potential data loss goes up collectively, while inconsistencies tend to come down – although they may not be zero, because of possible internal clock differences between systems.
  3. Use of a consistent backup, applicable to all systems. The best for RCO and the worst for RPO, but in any case, this also requires that such a backup exists.

As ever, the choice of the trade-off will depend on your particular business setup and requirements. But the more business depends on IT, the more likely such multiple interconnected systems, and the greater the need will be to include RCO in the disaster recovery planning process.[/vc_column_text][/vc_column][/vc_row]