Understanding RPO and RTO

Understanding RPO and RTO

Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are one of the most important parameters of a disaster recovery or data protection plan. These objectives guide the enterprises to choose an optimal data backup (rather restore) plan.

RPO: Recovery Point Objective

Recovery Point Objective (RPO) describes the interval of time that might pass during a disruption before the quantity of data lost during that period exceeds the Business Continuity Plan’s maximum allowable threshold or “tolerance.”

Example: If the last available good copy of data upon an outage is from 18 hours ago, and the RPO for this business is 20 hours then we are still within the parameters of the Business Continuity Plan’s RPO. In other words it the answers the question – Up to what point in time could the Business Process’s recovery proceed tolerably given the volume of data lost during that interval?

RTO: Recovery Time Objective

The Recovery Time Objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster in order to avoid unacceptable consequences associated with a break in continuity.

In other words the RTO is the answer to the question: How much time did it take to recover after notification of business process disruption?

At first glance these two terms appear to be quite similar. The best way to understand the difference between them is to associate the “RP” in “RPO” by imagining that they stand for “Rewrite Parameters” and the “RT” in “RTO” as “Real Time.”

RPO designates the variable amount of data that will be lost or will have to be re-entered during network downtime. RTO designates the amount of “real time” that can pass before the disruption begins to seriously & unacceptably impede the flow of normal business operations.

The RTO/RPO and the results of the Business Impact Analysis (BIA) in its entirety provide the basis for identifying and analyzing viable strategies for inclusion in the business continuity plan. Viable strategy options would include any which would enable resumption of a business process in a time frame at or near the RTO/RPO. This would include alternate or manual workaround procedures and would not necessarily require computer systems to meet the objectives.

There is always a gap between the actuals (RTA/RPA) and objectives introduced by various manual and automated steps to bring the business application up. These actuals can only be exposed by disaster and business disruption rehearsals.

Some Examples

Traditional Backups: In traditional tape backups, if your backup plan takes 2 hours for a scheduled backup at 0600 hours and 1800 hours, then a primary site failure at 1400 hrs would leave you with an option to restore from 0600 hrs backup which means RPA of 8 hours and 2 hours RTA.

Continuous Replication: Replication provides higher RPO guarantees as the target system contains the mirrored image of the source. The RPA values depend upon how fast the changes are applied and if the replication is synchronous or asynchronous. RPO is dependent on the fact that how soon can the data on target/replicated site be made available to the application.

Druva Phoenix

Druva Phoenix for physical and virtual servers brings together backup, disaster recovery, and archival in the cloud, removing the burden of legacy infrastructure and significantly lowering TCO. It simplifies the process by enabling managers to back up straight to a secure cloud environment. It also mitigates the difficulty of managing mixed environments from a central location, as many times remote agency sites lack the tools to protect their data.

Learn more by downloading our 20 Point Checklist: Why Move Backup and Disaster Recovery To The Cloud

Additional Resources: 

Strategies & Trends for Offsite Data Protection – Register for Free Webinar Now! 

Remote Office Branch Office Training ESG



Get a free trial of Druva’s single dashboard for backup, availability, and governance, or find out more information by checking out these useful resources:

Try Druva


Jaspreet Singh

Jaspreet bootstrapped the company while defining the product, sales and marketing strategies that have resulted in Druva's early and impressive success. Prior to founding Druva, Jaspreet was a member of the storage foundation group at Veritas.


  1. Santhosh 9 years ago


    But how is this different from any other snapshot mechanism that is out there of the likes of Netapp?

  2. Jaspreet 9 years ago

    Hi Santhosh,

    CDPR is replication and then snapshots at replicated end. Even with this we aren’t attempting anything totally new … just putting some things rightly in place.

    The idea with replicator is to implement DR and get out in single day.

    Another area we are investigating is stretch clusters.

    – J

  1. Pingback: PuneTech » Understanding RPO and RTO in backups
  2. Pingback: Painpoints with Traditional Backup | Druvaa Blog