Disaster Recovery is More Than Recovery Point Objective (RPO)

By Todd Matters, Chief Technology Officer, RackWare

When IT professionals talk about Disaster Recovery (DR), Recovery Point Objective — or RPO — almost always dominates the conversation. And for good reason: RPO is a critical measure of how much data you can afford to lose in the event of an outage. But from a strategic as well as practical perspective RPO is only one of several objectives necessary to ensure your production operations are protected and recoverable to meet business objectives.  If your applications aren’t functional, or if it takes hours (or days) to make them functional, your business may fail or be severely damaged. 

True disaster recovery goes well beyond simply setting a recovery point. It requires a strategy that ensures data consistency, automates application recovery, balances cost and performance, and supports non-disruptive testing. Without these elements, RPO is meaningless.

Data Consistency: The Foundation of Functional Recovery

Delta syncs are the cornerstone of any Disaster Recovery strategy, and the way they’re executed has a monumental impact on a successful recovery.  If the sync process doesn’t deliver consistent data, your applications may boot but remain unusable without complex and time-consuming recovery steps. That’s why recovery points built on guaranteed consistency are far superior to journaling methods, where you never quite know if the data will align properly at any given checkpoint.

When a recovery server boots, it must be functional with little to no manual intervention. Anything less risks downtime, user frustration, and potential revenue loss.

Bringing Applications Up in Sync

Most applications aren’t a single server anymore; they’re ecosystems of interconnected services. Recovering servers in waves — supported by automated boot order and post-boot delays — ensures that application groups come up correctly and can communicate seamlessly. Without this level of automation, similar to data consistency issues, recovery is ad hoc and greatly delayed.

Flexible Policies: Balancing Priorities and Costs

Not all workloads are created equal. Some demand aggressive RPOs and minimal Recovery Time (Recovery Time Objective), while others can tolerate longer recovery windows.  Setting overly aggressive RPO targets across the board not only drives up costs but can also unnecessarily consume valuable network bandwidth, slowing down the very high-priority workloads that truly need fast syncs.

The key is flexible policy management: aligning performance with the criticality of each application.  Having the flexibility to dynamically provisioning some servers to manage costs while pre-provisioning others for performance will optimize both performance and cost.

Maintaining Protection with Non-disruptive, Automated and Easy Testing

A key element to all DR strategies relies on scheduled testing with feedback to the plan.  Many organizations test too infrequently or not at all because it’s disruptive, expensive, and resource-intensive.  Robust DR solutions remove that barrier by enabling automated, non-disruptive testing — allowing you to validate that applications and servers recover as expected while production remains fully functional.  Even better, testing can be done for specific applications rather than an entire environment, making it far more cost-effective and practical, especially for high priority workloads.   Additionally, during testing, continuing to protect (delta sync) production severs is imperative.  

Conclusion: RPO Without Functionality is Useless

Recovery Point Objective will always be an important part of disaster recovery strategy.  But there can be tradeoffs with other equally important elements of a DR implementation.  Focusing solely on RPO is shortsighted.  If your applications are not functional or it takes too long to make them functional your RPO is useless.