RPO

In practice

RPO answers a question about data rather than about downtime. If a service is recovered to a point fifteen minutes before the failure, fifteen minutes of work is gone. RPO states how much of that the organisation can live with, and it is stated in time because that is what backup and replication schedules are measured in.

It drives different mechanisms from recovery time objective. A short RPO means data has to be replicated continuously or near-continuously, which brings distance, bandwidth, consistency and cost into the design. A longer RPO can be met with periodic backups, which is far cheaper and entirely appropriate for services whose recent data is reproducible.

The two objectives are frequently confused with each other and frequently traded against each other. A service can be brought back very quickly at an old data point, or slowly at a recent one; achieving both at once is the expensive case. Stating them separately per service is what keeps the conversation honest.

Neither objective is worth anything untested. An RPO assumed from a backup schedule, rather than proven by an actual restore, is a hope — and the gap between the two is usually discovered at the worst possible moment.

Scope of this definition

This is an educational summary of how the term is used in data center practice. It is not a standard, a specification or engineering advice, and where a real decision depends on it, the current adopted standards, verified site information and qualified professional review are the correct sources.

Back to the A–Z glossary · Operator Academy