RPO vs RTO: Understanding Backup and Recovery Objectives

Recovery Point Objective (RPO) and Recovery Time Objective (RTO) turn vague statements like "we need good backups" into numbers you can design and test against. This article explains both, shows examples for common systems, and explains how they determine backup frequency, storage location and budget.

Definitions

RPO, Recovery Point Objective: the maximum amount of data, measured in time, that you accept to lose. An RPO of 24 hours means that after an incident, restoring yesterday's backup is acceptable. An RPO of 5 minutes means you can lose at most the last five minutes of changes.

RTO, Recovery Time Objective: the maximum time a system may stay unavailable before it is running again. An RTO of 4 hours means that from the moment of the incident, the service must be back within four hours.

   last good backup        incident                 service restored
          |                    |                            |
----------*--------------------X----------------------------*------> time
          <------- RPO -------><----------- RTO ------------>
            data you may lose     time the service is down

RPO looks backwards from the incident; RTO looks forwards. They are independent: a system can have a strict RPO (no data loss) and a relaxed RTO (a day to restore), or the opposite.

What each objective drives

Examples by system

Online store

Orders and payments arrive all day. Losing a day of orders means lost revenue and angry customers, so the RPO for the database should be minutes. The storefront itself can be redeployed from code, so its files need a relaxed RPO. During an outage the business stops selling, so the RTO might be one or two hours.

• Database: nightly full backup plus continuous binary log or WAL archiving offsite (RPO of a few minutes).
• Application: code in version control, configuration and uploads backed up daily.
• RTO: a tested runbook, local copies for fast restore, and a pre-provisioned recovery server.

Internal file server

Employees can redo a few hours of document edits, and the company can work without the server for half a day. A daily backup (RPO 24 h) with an RTO of one business day is often acceptable. Hourly snapshots can improve the RPO cheaply for accidental deletions.

Accounting system with legal obligations

Financial records may need to be preserved for years and must not be lost. RPO close to zero for confirmed transactions, long retention, and at least one immutable copy. The RTO may be a day if operations can continue manually for a short period.

Proxmox cluster running many services

Each VM inherits the objectives of the service it runs. Domain controllers, DNS and databases usually need the shortest RTO, because other services depend on them. Restore order and restore throughput become the real constraints, as discussed in our Proxmox disaster recovery guide.

How to define RPO and RTO

1. List the systems and the business processes that depend on each one.
2. Estimate the impact of downtime per hour: lost revenue, contractual penalties, productivity, reputation.
3. Estimate the impact of data loss per hour of lost changes: can the data be re-entered, reconstructed or is it gone forever?
4. Agree on numbers with the business owners, not only with IT. Objectives are business decisions.
5. Price the options. Shorter objectives cost more: more frequent backups, more storage, standby infrastructure. Adjust until cost and risk are balanced.

A simple tiering helps keep things manageable:

Common pitfalls

• Confusing backup frequency with RPO in practice: a nightly backup that takes six hours and is only uploaded offsite the next morning gives a worse RPO in a site disaster than the schedule suggests.
• Forgetting detection time: RTO starts when the incident happens, not when someone notices it. Monitoring is part of meeting your RTO.
• Ignoring dependencies: an application restored in 30 minutes is useless if its database takes six hours.
• Measuring RTO with small tests only: restoring one file proves little about restoring 5 TB over the internet. Calculate restore time from real bandwidth: 2 TB at 200 Mbit/s needs about 22 hours.
• Treating replication as backup: replication improves RPO for hardware failures, but it replicates deletions and corruption instantly. You still need backups for those cases.

Testing your objectives

An objective is only real if a test meets it. For each tier:

1. Pick a system and simulate a realistic incident at a random time.
2. Note the timestamp of the most recent recoverable data: the difference is your actual RPO.
3. Run the restore with the documented procedure: the total time is your actual RTO.
4. Compare with the objectives, fix the gaps, and repeat on a schedule.

How objectives map to backup design

• RPO of 24 hours: daily backups, copied offsite the same day.
• RPO of 1 hour: hourly incremental backups or snapshots replicated offsite.
• RPO of minutes: continuous log archiving for databases (see MySQL and PostgreSQL), in addition to base backups.
• Short RTO: local copies for speed plus offsite copies for disasters, as explained in cloud vs local backup.
• Protection against ransomware for any tier: one immutable copy, the extra "1" of the 3-2-1-1-0 rule.

Next steps

1. Build a table of your systems with a proposed RPO and RTO each.
2. Review it with the people responsible for the business processes.
3. Compare each objective with your current backup frequency and measured restore times.
4. Schedule a restore test for each tier this quarter.

Backnix is designed to help you meet your objectives with scheduled, encrypted offsite backups; see backup security and how it works for details and current availability.

References

• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
• NIST glossary: Recovery Point Objective
• NIST glossary: Recovery Time Objective

Topics: Business continuityDisaster recoveryRPORTO