Home » Technology » Understanding RPO and RTO in backups

Subscribe to receive PuneTech updates updates in your email inbox or via RSS. And, if you are looking for special interest groups, Click here. See our About Page to find out more about what PuneTech is.

The best way to stay in touch with PuneTech and associated activities is to follow us on twitter

Understanding RPO and RTO in backups

This post is based on an article posted by Jaspreet Singh on the Druvaa Blog. Druvaa is a Pune-based startup based on Continuous data protection (CDP) technology.

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

RPO – Recovery Point Objective (wikipedia)

“Recovery Point Objective (RPO) describes the amount of data lost – measured in time. Example: After an outage, if the last available good copy of data was from 18 hours ago, then the RPO would be 18 hours.”

In other words it is the answer to the question – Up to what point in time can the data be recovered ?.

RTO – Recovery Time Objectives (wikipedia)

“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.


It should be noted that the RTO attaches to the business process and not the resources required to support the process.”

In another words it is the answer to the question – How much time did you take to recover after notification of a business process disruption ?

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 of restoring from the 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 a 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 only on how soon the data on target/replicated site can be made available to the application.

About Druvaa Replicator

Druvaa Replicator is a Continuous Data Protection and Replication (CDP-R) product which near-synchronously and non-disruptively replicates changes on production sever to target site and provides point-in-time snapshots for instant data access.

The partial synchronous replication ensures that the data is written to a local or remote cache (caching server) before its application can write locally. This ensures up to 5 sec RPO guarantees . CDP technology (still beta) enables up to 1024 snapshots (beta) at that target storage which helps the admin to access current or any past point-in-time consistent image of data instantly, ensuring under 2 sec RTO.

More Information – http://www.druvaa.com/products/replicator/

If you liked this post, subscribe for updates by email or via RSS.

4 thoughts on “Understanding RPO and RTO in backups”

  1. vikas says:

    good explanation …thanks

  2. Jie Z says:

    Very good and useful.

Leave a Reply

Your email address will not be published. Required fields are marked *