What Is a Recovery Point Objective (RPO)?

Definition

A recovery point objective (RPO) is the maximum amount of data, measured in time, that a business can afford to lose in an outage. If your RPO is four hours, you need a usable copy of your data at least every four hours. It answers "how far back can we afford to go?"

How It Works

NIST SP 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems, defines the RPO as "the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage." NIST notes that unlike recovery time, RPO "is a factor of how much data loss the mission/business process can tolerate."

Setting an RPO starts with the business, not the technology:

List the data: orders, invoices, patient or client records, email, website content.
Ask what losing it costs: an hour of online orders, a day of bookkeeping entries, a week of blog edits.
Match the backup method: nightly backups give an RPO of up to about 24 hours; hourly snapshots or continuous replication shrink it.

Two cautions. First, replication is not a backup: if data is deleted or encrypted, the change copies over too. Second, an RPO is only real if the backups behind it are tested. CISA's small business backup guidance calls for scheduled recovery tests to verify backup integrity and to refine RPOs and RTOs so they "ensure business needs are met."

Real-World Example

On January 31, 2017, an engineer at GitLab accidentally wiped the production database directory on the wrong server. GitLab's public post-mortem explains that its daily pg_dump backups had been failing because of a version mismatch, and the failure alert emails were rejected by the receiving mail server, so "we were never aware of the backups failing, until it was too late." Replication was already broken. The best remaining copy was a snapshot an engineer had taken manually about six hours earlier; the alternative meant losing almost 24 hours of data. GitLab lost database changes made between 17:20 and 00:00 UTC, affecting an estimated 5,000 projects, 5,000 comments, and 700 new user accounts. This was an internal error, not an attack, but the lesson is the same: the real RPO was set by the last copy that worked.

Why It Matters for a Small Business

Most small businesses have never written down an RPO, so they discover it during an incident. CISA advises small businesses to make sure they can "roll back data at least seven days if needed," because ransomware or a slow-moving compromise may have damaged recent copies too. A short RPO means more frequent backups and more storage, so the right answer differs for the accounting system, the website, and the shared drive. GitLab's outage also shows a quieter risk: backup jobs that fail without anyone noticing stretch the real RPO far beyond what the plan says.

How to Spot It / How DTS Handles It

Warning signs: no one can say when the last good backup ran, backups run nightly for systems that change every few minutes, and nobody has checked the age of the newest restorable copy.

DTS can help with setting an RPO per system with you, scheduling backups to meet it, alerting on failed jobs, and proving it with test restores. See our data recovery service.

Related Terms

Recovery time objective (RTO): how long you can be down, the partner metric.
Backups and the 3-2-1 rule: the copies that make an RPO possible.
Business impact analysis: where RPOs are decided.
Disaster recovery plan: the plan that records each system's RPO.
Recovery: the incident stage where your RPO is tested for real.
Ransomware: the most common reason small businesses need to restore.

Sources

NIST, SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (2010, updated): https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
CISA, Back Up Business Data: https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/back-up-business-data
GitLab, Postmortem of database outage of January 31 (February 10, 2017): https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/

Last updated October 14, 2026.