What are RPO and RTO?
RPO and RTO are two targets that define a recovery plan. The recovery point objective (RPO) is the point in time your data must be restored to after an outage, so it caps how much recent data you may lose. The recovery time objective (RTO) is how long the system may stay in recovery before the business is hurt.
Think of writing a long document on a laptop that dies. RPO is how far back your last save was: one minute of lost typing or one whole afternoon. RTO is how long it takes to get a working laptop, open the saved file and carry on.
How do RPO and RTO differ?
RPO looks backwards from the moment of failure and is measured in lost data. RTO looks forward and is measured in downtime. The two are set separately, because a business may tolerate an hour offline but not a single lost order, or the other way round.
RPO: how much data you can lose
Your real RPO is the gap between the last good copy and the failure. With a nightly backup at 02:00, a crash at 17:00 loses fifteen hours of writes. Backing up more often, or shipping changes continuously, shrinks that gap.
RTO: how long you can be down
RTO covers everything between the failure and users being back: noticing the problem, deciding to restore, getting new servers, copying data back and checking it. Restoring a large database from a backup can take hours. Replaying change logs on top of it adds more time, and the longer since the last full backup, the more there is to replay.
How do you meet a given RPO and RTO?
Each method trades cost against how close to zero it gets you:
- Nightly or hourly backups give an RPO of up to one interval and an RTO set by how fast you can restore.
- Continuous log archiving, such as PostgreSQL WAL shipped to object storage, lets you restore to any point since the last base backup. RPO drops to the archiving interval, often a minute or less.
- A standby replica that receives every change is close to ready once promoted, which cuts RTO. Synchronous replication brings RPO close to zero.
- Versioned or locked copies protect against deletion and ransomware. A replica copies those changes as faithfully as good ones.
Test the restore
An RTO you have never measured is a guess. Restore a backup into a clean environment on a schedule, time it, and write the steps into a runbook. The first real outage is a bad time to learn that a backup was empty.
How enum handles RPO and RTO
With DevOps as a Service, enum’s engineers run backups, restore tests and runbooks for your Kubernetes platform, along with monitoring and on-call. Response times for critical incidents go down to 15 minutes, depending on the service level, and are written into your contract. Ask us about the RPO and RTO your workloads need.
FAQ
Is RTO the same as an availability SLA? No. An availability SLA states how much uptime is promised over a period. RTO is the longest a single recovery may take. A service can meet its yearly uptime target and still miss the RTO in one bad outage.
Can RPO and RTO both be zero? Close to zero is possible with synchronous replication and automatic failover, but it costs more and adds write latency. Replicas also copy mistakes, so you still need backups for deleted or corrupted data.
Who sets RPO and RTO? The business sets them per system, based on what lost data and downtime cost. Engineering then picks backup and replication methods to match, and tests that recovery actually fits inside the targets.