How To Calculate a Recovery Point Objective

By Indeed Editorial Team

Updated January 19, 2022 | Published July 27, 2021

Updated January 19, 2022

Published July 27, 2021

Nearly all companies in every industry use computers and digital data to show transactions, store records and conduct business. Safeguarding digital content is essential for business, and there are a variety of IT systems, programs and platforms to protect important information, including establishing a recovery point objective (RPO). Knowing more about RPO can help you develop professional skills to use in an IT or business career. In this article, we explore what a recovery point objective is with examples, the factors of it and how to calculate a recovery point objective to help you better understand this technological term.

Related: How To Start a Career in IT

What is a recovery point objective?

A recovery point objective (RPO) is a measurement of time from when a system failure, disaster or loss-causing event takes place, like a power outage, ransomware attack, data corruption event or user error instance. RPOs return to a previous point when your data existed in a usable format, most often from a recent save or backup. In business, IT leaders in an organization or company often set the desired timeframe for which data loss is acceptable, or not causing extreme harm, and program an RPO accordingly. For example, RPOs designated for 60 minutes require a continuous save every 60 minutes.

Recovery point objectives frequently pair with recovery time objectives (RTO), or the projected time until an organization's operations return to normal after a data event. Together these metrics help businesses plan for disaster recovery, especially how to stay operational throughout and after a disaster occurs. Computer programs using RTO and RPO often ensure critical data gets replicated and stored properly with instant access when you need it. You might set separate RPO for various components of your business. For example, each of these electronic platforms might have different settings:

  • Email servers

  • Finance system

  • Customer relationship management system

  • File servers

  • Printer servers

  • Developmental servers

  • Directory servers

  • Human resource data systems

Related: A Beginner's Guide to Information Technology

Why does a recovery point objective matter?

A recovery point objective matters because it can have a profound impact on the operation of a business or organization and can cost money. For example, if you establish an RPO of six hours across your systems and experience a debilitating digital event, you likely lose six hours of data because six hours ago is the most recent previous point you can recover saved material.

Data loss of any time can be a significant amount, and depending on your business, it can add up rapidly. The larger the gap in time from data recovery, often the more likely for a more expensive financial impact. Consider a business with a $100 million turnover rate and how three different RPO settings alter the financial effect of a data event:

RPO TypeRPO Time GapFinancial Impact
Daily backups24 hoursup to $273,972
Snapshot-based replicationFour hoursup to $45,662
Continuous replicationMerely secondsup to $7,610

What factors influence a recovery point objective?

There are various factors to consider when establishing a recovery point objective, including:

  • Industry storage regulations and guidelines, like for financial and healthcare fields

  • Maximum tolerance for organizational data loss or operational impact

  • Compliance needs, like data access and availability and disaster prevention

  • Data recovery speed demands, which can vary between cloud technology or physical files

  • Financial costs of both creating and implementing an RPO and the potential loss from interrupted operations or lost data

With advancements in IT, many data protection services and systems use cloud technology, eliminating the need to have on-site hardware or traditional backup structures.

Related: Learn About Being a Database Administrator

What is an example of a recovery point objective?

A large international e-commerce website with multiple servers for different functions sets recovery point objectives based on the specific uses of a server and the information it stores. Because it operates internationally with sales happening 24/7, some aspects of its data management system need continuous replication rather than daily or weekly backups. For example, executives might designate the following recovery point objectives:

  • One-minute continuous RPOs: Payment gateways, inventory stock levels, email servers, confirmation logs and shipping databases

  • One-hour RPOs: Website interface, customer data, product dashboards and user password authentication

  • 24-hour RPOs: Content creation databases, customer chat logs and customer reviews

If a major data event takes place, the essential information of the e-commerce business, like evidence of items sold, reverts to the most immediate and updated information since it saves every 60 seconds. Slightly less crucial information like a customer product review posted just before the data loss won't be on the site once it's recovered, though the ones that existed the day prior still show since teams set that particular RPO for 24-hours.

Related: What Are the Different Types of Database Management?

How to calculate a recovery point objective

If you want to calculate recovery point objectives for your business or organization, consider following these five steps:

1. Look at how often files update

You can set a recovery point objective to match the frequency you update files. This helps ensure your most up-to-date information is retrievable. For example, if you have digital files and transactions that update every 30 minutes, setting an RPO for every 30-40 minutes helps ensure you continuously have access to recent information with minimal data loss.

Conversely, if your company set an RPO for a weekly backup save every Saturday night, a system failure that happens on Saturday afternoon would mean an entire week's worth of data gets lost because the system save hadn't yet happened that day. You can adjust your RPO, so consider establishing a consistent review of your file update times to determine if you need to change the RPO.

2. Review the goals of your BCP

Recovery point objectives often support the goals of your business continuity plan (BCP), so review each element carefully to determine separate RPOs of various time allotments for each business unit, usually based on the information they store and how critical it is if data loss happened. For example, the financial transactions and critical data processes of a national bank are vital, requiring much shorter RPO times than the human resource files of personnel records, which get updated less frequently and can sustain a longer RPO time.

3. Consider industry standards

While all institutions may have unique RPO needs, you can consider industry standards to help guide you when calculating RPOs for business units at your company or organization. For example, here are four common intervals for recovery point objectives:

  • Zero to one hour: You use the shortest time frame for critical operational elements that can't afford to lose an hour of data, typically because they're high volume, dynamic or difficult to recreate. For example, online banking transactions, patient records or stock market trading activities.

  • One to four hours: You might use this time frame for business units deemed semi-critical, where only some data loss is acceptable. For example, customer online chat logs, file servers or social media records.

  • Four to 12 hours: A time frame of this length might get used for business units that update daily or less frequently, like advertising and marketing, sales or operational statistics data. Typically, these units rarely have a grave impact on a business if affected.

  • 13 to 24 hours: Setting longer RPO time frames for important, but not critical, data and business units rarely exceed 24 hours. You might use this setting for things like purchase orders, inventory control or personnel files.

Most business dealings fall under these general RPO time frame guidelines, though depending on the size of your organization or its purpose, you might use weekly settings for data. For example, an international airline with employees across hundreds of stations would likely designate its HR records to update daily, whereas a single office insurance company with 30 employees might choose to update personnel files weekly because they're less likely to change as frequently as the airline's HR records.

4. Establish and approve each RPO

After factoring in all concerns for each element of your data management, establish the RPOs and have them approved by leadership for IT teams or business partners to implement. Properly document the process and keep the records to refer to and use as a baseline when reassessing or adjusting them. Depending on your role in an organization, you might follow existing RPO processes and procedures or help establish and create them.

5. Analyze your RPO settings consistently

As a company grows or business continuity plans change, so might your recovery point objectives. Consider establishing a routine and frequent review and analysis of how well your existing RPO settings perform and if any need adjusting. This is an important step even though it comes last. If a data loss or system failure happens, an ad hoc review and in-depth analysis of how both your RPO and RTO performed can help you glean meaningful insights into your overall data management system.

Browse more articles