RTO and RPO

RTO and RPO are the two main targets in disaster recovery. Recovery time objective (RTO) is the longest a service may stay down after a failure before the business impact is unacceptable. Recovery point objective (RPO) is the most data, measured in time, the business can afford to lose. Both are set per system or user journey.

How it works

RPO is driven by how often data is copied. With backups every hour and no replication, a failure can lose up to 60 minutes of writes, so the RPO is at best 1 hour. Continuous replication can bring RPO down to seconds. RTO is driven by how fast you can detect the failure, decide to fail over, restore data and shift traffic. A team with a 30-minute RTO needs restores and cutover runbooks that finish well inside that window.

Why it matters in production

Tighter RTO and RPO cost more, through standby capacity, replication and drills. Setting them per user journey keeps spend focused. Untested targets are guesses. Only regular restore and failover drills show whether you can meet them.

See also

• Service level objective

• Error budget

• Change data capture

• Site reliability engineering

On the One2N blog

• Disaster recovery for SREs: the practical playbook for RTO, RPO, and cutover

• Optimizing MongoDB backup strategy: lessons from achieving a 1-hour RPO

• AWS outage: real costs & disaster recovery

References

1. Disaster recovery options in the cloud (AWS whitepaper)

2. Recovery time objective (NIST glossary)