RPO and RTO Definitions

Downtime is not an option for modern organizations that must fulfill their customers’ needs and expectations. Different types of incidents can occur and impact your business revenue or even existence. Whether it’s a ransomware attack, a power outage, flood or simply human mistakes, these events are unpredictable, and the best thing you can do is to BE PREPARED.

Preparedness means that you should have a solid business continuity and disaster recovery (BCDR) plan. One that has been tested and that can be put in motion smoothly.

Two of the important parameters that define a BCDR plan are the Recovery Point Objective (RPO) and Recovery Time Objective (RTO). For those of you who are not familiar with these terms, let me give you a brief description:

  • RPO limits how far to roll back in time, and defines the maximum allowable amount of lost data measured in time from a failure occurrence to the last valid backup.
  • RTO is related to downtime and represents how long it takes to restore from the incident until normal operations are available to users

Demystifying Recovery Objectives

While RPO and RTO may sound similar, they serve different purposes and, in an ideal world, their values would be as close to zero as possible. However, back to our world, the cost for zero RPO and RTO would be extremely expensive and might not be worth the effort.

Let’s take a closer look at recovery objectives. RPO is about how much data you afford to lose before it impacts business operations. For example, for a banking system, 1 hour of data loss can be catastrophic as they operate live transactions. At a personal level, you can also think about RPO as the moment you saved a document you are working on for the last time. In case your system crashes and your progress is lost, how much of your work are you willing to lose before it affects you?

On the other hand, RTO is the timeframe within which application and systems must be restored after an outage. It’s a good practice to measure the RTO starting with the moment the outage occurs, instead of the moment when the IT team starts to fix the issue. This is a more realistic approach as it represents the exact point when the users start to be impacted.

Article Source