What’s recovery point objective (RPO)?

By: Neil Alhanti

Along with recovery time objective (RTO), recovery point objective (RPO) is one of the primary tools for establishing a disaster recovery plan or a data protection plan. It’s also a tool for helping an enterprise select the data backup plan that meets its needs.

RPO and RTO establish the foundation for determining and discerning strong inclusion strategies for the business continuity plan (BCP). These strategies should allow for the speedy resumption of business continuity processes within a time frame equal to or close to the RPO and RTO.

Although they’re both tied into determining disaster recovery, an RPO must remain independent of an RTO or the minimum estimated time needed to restore regular operations following a system or network failure.

Like RTO’s, RPO’s help determine disaster recovery policies and procedures. The RPO helps administrators choose the best backup and recovery technologies to use, depending on the overall design strategy that data loss shouldn’t delay the RTO.

How’s an RPO different from an RTO?

Both RPOs and RTOs are concepts used for supporting business continuity. They also work as business metrics and can help you calculate how often your business should perform data backups.

RPOs and RTOs are instrumental to a business’ disaster recovery plan or data protection plan. They’re both linked to business impact analysis, a systematic process that can help separate critical and urgent organization-specific functions and activities from non-critical and non-urgent ones. Functions can be considered critical if specified by law.

RPO and RTO are the two values that are assigned for each function. Whereas RPO determines how much data will or will not be recovered after a disruption, RTO determines how much time it takes for a system to transition from disruption and to regular operations functioning normally.

How’s a RPO calculated?

RPOs go backwards in time, stretching back from the instance of disruption to the last backup point where the data is usable. They can also measure how often you should regularly backup your data.

In terms of calculation, RPOs are usually calculated in minutes or hours but, depending on the urgency or lack thereof, they can also be calculated in seconds or days. An RPO determines how far back into the data’s history you need to go for backup storage to resume normal operations after a computer, system or network experiences disruption from a hardware, program or communications failure.

An RPO can also be considered the maximum acceptable amount of data loss that’s measured in time. In addition, it can describe how much time passes during a disruption before the amount of data lost during the period of disruption extends beyond the business continuity plan’s maximum allowable “tolerance” or threshold.

For example, if a computer system has an RPO of 30 minutes, that means that the maximum window for data loss following a disruption is 30 minutes. Therefore, a backup of the system must be performed every 30 minutes.

IBM disaster recovery as a service (DRaaS) helps enable rapid and reliable recovery

When should you schedule data backups for an RPO?

RPOs are often easier to perform than RTOs. The reason is because data use provides few variables and is generally consistent. However, the opposite can also be true since calculating restore times is usually based on your whole operation and not just your data.

When the disruption happens is also a factor in the restore time. When constructing your data backup schedule, consider what hours your business is the busiest and least busy. For example, if you have a disruption at 3 AM Eastern Standard Time and IT resolves the disruption by 5 AM, did you lose two hours’ worth of data? If this timeframe is a low-traffic period for your business, then probably not.

For another example, let’s say your business backs up its data every 10 hours. There’s a disruption at noon and it’s quickly resolved with your business back to normal by 12:30 PM. Because there was only a 30-minute window of data loss from 12 PM until 12:30 PM, you don’t need to restore all the data from the previous 10 hours. You only need to restore data from the lost 30 minutes.

Simplify your disaster recovery (DR) management with IBM Resiliency Orchestration

Disaster recovery and disaster recovery plans

Not to be confused with emergency management and disaster response, disaster recovery deals with IT infrastructure and systems in support of important business processes. Disaster recovery is a subset of business continuity, which works to maintain all vital aspects of a business despite any disruption.

Disaster recovery is the policies, tools and procedures that compose the eponymous restoration or continuation of critical technology infrastructure and systems after a natural or manmade disaster has occurred.

A disaster recovery plan (DRP) is the process or procedures used to perform a disaster recovery process, and recover and protect an organization’s IT infrastructure and systems following a disaster. This process can be expanded to take place before and during a disaster.

Ready to take the next step? Schedule a consultation with an IBM Business Continuity Services expert.

Related topic: Disaster recovery as a service (DRaaS)

IBM products related to business continuity plans

Understand how to plan for and react when business disruptions are happening.

Adapt and respond to risks with a business continuity plan (BCP)

How to defend against cyber attacks

Do you have your disaster recovery plan (DRP)?

Defend against ransomware attacks?

What is data breach and how to defend against one?

What is a recovery time objective (RTO) and how does it affect disaster recovery for your enterprise?

What is an RPO (recovery point objectives)?

About The Author

Neil Alhanti

Senior Writer, IBM Global Technology Services

Neil Alhanti is a content marketing writer, wordsmith and editor extraordinaire with IBM Global Technology Services. He spends his days crafting conversational communications across multiple mediums and otherwise “fighting the good fight and writing the good write.”