Using RTO and RPO for data protection

Using RTO and RPO for data protection

How can I evaluate the correct level of data protection using recovery time and recovery point objectives? Under what conditions do I use one over the other?

    Requires Free Membership to View

    When you register for SearchStorage.com, you’ll also receive targeted emails from my team of award-winning editorial writers. Our goal is to keep you informed on the hottest topics, the latest news and the biggest challenges you face as a storage professional today.

    Rich Castagna, Editorial Director

    By submitting your registration information to SearchStorage.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 SearchStorage.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

I am not a big fan of the terms "Recovery Point Objective (RPO)" and "Recovery Time Objective (RTO)". I think that the terms "lost data" and "downtime" are much more descriptive and relevant.

That being said, the two are independent, not interchangeable or complementary. Both must be considered as any solution to increase system availability is evaluated.

When an interruption occurs, it can cause downtime, and it can cause lost data. The amount of downtime and lost data depend on the nature of the interruption, and the preventative/recovery methods that are in place.

An organization's requirements for minimizing downtime and lost data vary by application. Usually, that is determined by the cost to the organization of said downtime and lost data, and how much it is worth to protect against those factors.

I hope this is helpful. Thank you for the question.

This was first published in April 2003