The relationship between RTOs and RPOs

The relationship between RTOs and RPOs

Is there some kind of standard ratio or relationship between RTOs and RPOs, or are they completely independent of each other?

    Requires Free Membership to View

    Login

    When you register for SearchDataBackup.com, you’ll also receive targeted emails from my team of award-winning editorial writers. Because your job never seems to get any easier, it’s our goal to keep you up-to-date on the latest backup tips, trends and technologies that will help you get the job done.

    Rich Castagna, Editorial Director

    By submitting your registration information to SearchDataBackup.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchDataBackup.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

The quick answer is that there's no "standard" ratio or relationship between a recovery time objective (RTO) and a recovery point objective (RPO). However, they aren't always independent of each other -- one can affect the other.

The RTO is the amount of time in which a system must be recovered in the event of an interruption. It's driven by the business and represents the maximum amount of time a company can tolerate an interruption of a business function or process that depends on the system. The RTO plays an important role in the development of data recovery strategies and is often used as the basis for the development of a service-level agreement (SLA).

An RPO is the point in time to which a system's data must be recovered after an outage (i.e., last night's backup, the last transaction before the outage, etc.). The RPO is often used as the basis for the development of data backup strategies. It's also used to determine the amount of data that may need to be recreated after the system is recovered or, ultimately, what constitutes acceptable data loss.

Depending on the type of application and the business function it supports, the RTO and RPO can be miles apart. For example, an application providing a critical service relying on static data may have an RTO of one hour, but an RPO of one day. The application must be up in one hour, but using yesterday's data is OK. Conversely, a four-hour email server outage may be tolerable to a company, but losing a single email message may be unacceptable for business or legal reasons. We end up with an RTO of four hours and RPO of zero (down to the last transaction).

Now with all that said, it's possible to miss a RTO while trying to meet a RPO. In other words, it takes so long to restore the data to meet the RPO that the application ends up being down longer than allowed. This is when we need to start rethinking our data recovery strategies.

This was first published in April 2008