Guide
RTO vs RPO: the South African MSP's practical recovery guide
Two numbers define how resilient an organisation really is. Here is how to set them, communicate them, and prove they work.
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the two numbers that turn abstract resilience into measurable commitments. Every backup policy, disaster recovery plan and service-level discussion eventually comes back to them.
RTO — how quickly must it be running again?
RTO is the maximum acceptable downtime after a disruption. If a server's RTO is four hours, the organisation is accepting up to four hours of that system being unavailable before the impact becomes unacceptable.
Setting an RTO requires understanding the cost of downtime for each workload: revenue loss, operational disruption, contractual penalties, reputational impact and regulatory consequences. Not every system needs the same RTO.
RPO — how much data can the organisation lose?
RPO is the maximum acceptable data loss, measured as a time window. An RPO of one hour means the organisation accepts losing up to one hour of data from the point of the last successful backup or replication.
RPO determines backup frequency: a one-hour RPO requires at least hourly backups. A 24-hour RPO allows daily backups. The tighter the RPO, the more infrastructure and bandwidth are needed.
Setting them: a practical approach
- Inventory workloads — list every system, application and data set that needs protection.
- Assess impact — for each workload, determine the cost of one hour, four hours, one day and one week of downtime or data loss.
- Categorise — group workloads into tiers: mission-critical (tight RTO/RPO), important (moderate) and non-critical (relaxed).
- Match to capability — determine what backup frequency, replication method and recovery infrastructure each tier requires.
- Test and prove — run non-disruptive recovery tests to validate that the configured RTO and RPO are actually achievable.
The testing gap
An RTO and RPO that have never been tested are assumptions, not commitments. Regular recovery testing validates that the defined objectives are achievable with real data on real infrastructure — and identifies configuration drift before an incident exposes it.
Through Soteria Cloud, disaster recovery and backup within Acronis Cyber Protect Cloud support non-disruptive recovery testing, allowing MSPs to prove their customers' defined recovery objectives are achievable and generate evidence for auditors, insurers and boards.
Frequently asked questions
What is Recovery Time Objective (RTO)?
RTO is the maximum acceptable time between a disruption and the restoration of a system to a working state. It answers: how quickly must this be running again?
What is Recovery Point Objective (RPO)?
RPO is the maximum acceptable amount of data loss, measured in time. An RPO of one hour means you could lose up to one hour of data. It answers: how much data can the organisation afford to lose?
Who decides RTO and RPO targets?
They are business decisions informed by technical realities. The business defines how much downtime and data loss it can absorb; the IT team or MSP determines what infrastructure and configuration are needed to meet those targets.
Can RTO and RPO be zero?
In theory, near-zero targets are possible with synchronous replication and instant failover, but the cost and complexity increase significantly. Most organisations set targets based on a practical balance of risk, cost and operational impact.
Prove your recovery objectives before an incident tests them
Talk to Soteria Cloud about disaster recovery with defined, tested RTO and RPO targets.