RTO and RPO
Also known as: recovery time objective, recovery point objective, RTO/RPO
RTO (recovery time objective) and RPO (recovery point objective) are two targets used in backup and disaster recovery planning.
RTO is the maximum acceptable time a system can be down before it must be restored, such as four hours. RPO is the maximum acceptable amount of data loss, measured in time, such as losing no more than one hour of work. Together, they decide how often to back up, how backups are stored, and how much recovery will cost. While these sound technical, they're really business decisions about how much downtime and data loss the company can tolerate.
RTO and RPO, explained at three levels
At home
Imagine your laptop dies the night before an essay is due. RPO asks how much work you could stand to lose: if your last backup was this morning, you lose everything since. RTO asks how long you can wait before the laptop must work again: an hour, or until next week. One measures lost work, the other lost time.
At work
RTO and RPO are two targets a business sets for recovering from an outage. RTO, the recovery time objective, is how long a system can be down before it must be back. RPO, the recovery point objective, is how much recent data the business can afford to lose. Leaders care because tighter targets need more frequent backups and faster recovery, which cost more.
At home
RTO and RPO measure a disaster from two directions. RPO, the recovery point objective, looks backward: how much recent data could you lose, measured in time since the last good copy. If your phone backs up photos nightly, a breakdown before tonight loses up to a day. RTO, the recovery time objective, looks forward: how long you can be without the system before it must be working again. One is about lost data, the other about lost time.
At work
Targets come from a business impact analysis that asks what each hour of downtime and each hour of lost data costs. Email might tolerate a day for both, while a point-of-sale system might need an RTO of an hour and an RPO of minutes. Shorter targets require more expensive methods: nightly backups give an RPO near 24 hours, frequent snapshots reduce it to minutes, and continuous replication to a standby site can approach zero.
At home
Cloud syncing services such as OneDrive or iCloud Drive copy changes within seconds, which gives a very short RPO. The catch is that they sync mistakes too: delete a folder or let ransomware encrypt your files, and the damage spreads to the cloud copy just as fast. Version history helps, within limits. In my view, pair syncing with separate versioned backups, so a bad change cannot overwrite your only other copy.
At work
Run business impact analyses with system owners, tier systems by criticality, and choose backup and replication methods that meet each tier's targets at an acceptable cost. Dependencies matter, since an application's RTO is limited by the slowest component it needs, such as identity or DNS. Test restores against RTOs with realistic data volumes, record actual recovery times, and report gaps to leadership with the cost of closing them, so accepting risk becomes an explicit decision.
Real-world examples
At home
Sophie realized her laptop backed up only weekly. Losing a week of freelance work would be painful, so she switched to daily backups, shortening her RPO.
At work
Marcus's Calgary MSP worked with a dental clinic to set targets. The scheduling system got a two-hour RTO and 15-minute RPO, while archived records could wait a day.
How it compares
| feature | RTO (recovery time objective) | RPO (recovery point objective) |
|---|---|---|
| Question answered | How long can we be down? | How much data can we lose? |
| Measured as | Time to restore | Time since last good backup |
| Driven by | Recovery speed and process | Backup frequency |
| Example | Back online within 4 hours | Lose at most 1 hour of data |
RTO is about downtime. RPO is about data loss.
For analysts
I'd ask business owners, not IT, to set RTO and RPO for each system, then show the cost of each option. It turns backup budgets into informed business choices.
History & origin
Disaster recovery planning grew in the 1970s and 1980s as banks and large companies came to depend on mainframes, and RTO and RPO became standard terms in business continuity practice. Standards such as ISO 22301, first published in 2012, formalized business continuity management. Cloud backup, replication, and disaster recovery as a service in the 2010s made short RTOs and RPOs affordable for smaller organizations. Ransomware attacks, which often target backups, pushed businesses to test whether their recovery targets were realistic. In my view, an RTO nobody has tested is just a wish.