RTO and RPO: setting the right targets with leadership

Two numbers decide most of your continuity choices and their cost: RTO and RPO. Yet they are often set by default, on the technical side, without leadership ever deciding what it is willing to lose. That is a mistake, because these are business decisions before they are infrastructure decisions. Here is how to set them properly.

What RTO and RPO mean

The two answer different questions after an incident:

• RTO (Recovery Time Objective): how quickly must the service be operational again? It is the acceptable downtime.
• RPO (Recovery Point Objective): how much data can you afford to lose? It is the acceptable gap between the last backup point and the incident.

An example makes it concrete. An RPO of 24 hours means you accept losing up to a day of data. An RTO of 4 hours means the service must be restored in under four hours. These are not technical settings, they are promises made to the business.

Why this belongs to leadership

RTO and RPO are trade-offs between accepted risk and cost. The tighter you set them, the more the infrastructure costs: an RPO close to zero requires continuous replication, a short RTO requires high availability and standby capacity ready to start. Loose targets cost less, but expose you to a heavier loss.

Only leadership can make that trade-off, because only it knows the cost of downtime to the business: lost revenue, client commitments, reputational impact, regulatory obligations. IT’s job is to inform the decision with the cost of each target level, not to make it alone in a corner.

One target per criticality, not one for everything

The next mistake is applying a single RTO and RPO to the whole infrastructure. Not all workloads have the same value. Rank your applications by criticality and give each tier its own targets: the ERP that halts the company does not need the same RTO as a test server. This avoids overpaying to protect what does not need it, and underprotecting what really matters.

From target to architecture

Once the numbers are set, they dictate the technical choices:

• RPO drives backup: its frequency, and any use of replication. A 24h RPO is satisfied by a daily backup; a 15-minute RPO requires something else.
• RTO drives recovery: high availability, restore speed, standby capacity, and above all a written and rehearsed recovery plan. Restoring fast is not improvised on the day of the incident.

Where it gets hard

The classic trap is not picking the wrong numbers, it is never checking that you meet them. Claiming a 4-hour RTO without ever timing a real restore is fiction. The only way to know whether you meet your targets is to test the restore and measure the actual time.

That is what managed operations and tested backups guarantee. Our managed Proxmox hosting sizes high availability and recovery capacity against your RTO targets, and Cloud-PBS provides off-site backups whose restore is verified, which turns your RPO and RTO into kept promises rather than numbers on a slide.