Ask any executive how much downtime their business can tolerate and the instinctive answer is "none." Ask how much data they can afford to lose and you will hear the same thing. Both answers are understandable — and both are usually wrong, because true zero-downtime, zero-loss recovery is extraordinarily expensive and rarely justified for every system you run.
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the two numbers that turn that instinct into an honest engineering and budgeting decision. Get them right and your disaster recovery plan is both achievable and affordable. Get them wrong and you either overspend protecting systems that do not need it, or you discover — at the worst possible moment — that your recovery falls far short of what the business assumed.
This guide explains both terms in plain language and gives you a practical method for setting targets that hold up under pressure.
The Two Numbers That Define Recovery
RTO — Recovery Time Objective
RTO answers the question: how long can this system be down before the impact becomes unacceptable?
If a system has an RTO of two hours, your people, processes, and technology must be able to restore it to working order within two hours of an incident. RTO is about downtime — the gap between "everything stopped" and "we are operating again."
RPO — Recovery Point Objective
RPO answers a different question: how much data can we afford to lose, measured in time?
If a system has an RPO of four hours, you are accepting that an incident could cost you up to four hours of work — everything created or changed since the last recoverable copy. RPO is about data loss, and it directly dictates how often your backups or replication must run. An RPO of four hours is meaningless if your backups run only once a day.
Picture It on a Timeline
Imagine an incident strikes at 14:00.
- Your RPO looks backwards from that moment. If your last good backup was at 12:00, you have lost two hours of data. If your RPO is four hours, you are within target. If your RPO is one hour, you have already breached it.
- Your RTO looks forwards from that moment. If you restore service by 16:00, that is two hours of downtime. Whether that meets target depends on the RTO you committed to.
The two numbers are independent. A system can have a tight RPO (you lose almost no data) but a loose RTO (it takes a while to come back), or vice versa. You must set both, per system.
Why "Zero" Is the Wrong Default
Near-zero RTO and RPO are technically possible. Continuous replication, hot standby infrastructure, and automated failover can get you there. But each step toward zero multiplies cost — duplicate infrastructure, higher-bandwidth links, and more sophisticated tooling and testing.
The discipline is to spend that money only where the business genuinely needs it. A core trading or billing system might justify aggressive targets. A departmental file archive almost certainly does not. Treating every workload as mission-critical is how DR budgets balloon while the actually-critical systems remain under-protected because the money was spread too thin.
How to Set Targets That Hold Up
Setting credible recovery targets is a business exercise first and a technical one second. Work through it in four steps.
Step 1 — Quantify the Cost of Downtime
For each major system, estimate what one hour of unavailability actually costs. Include the obvious — lost sales, idle staff, missed SLAs — and the less obvious: reputational damage, contractual penalties, and regulatory exposure. You do not need a perfect figure. A defensible range is enough to rank systems and justify spend. The question that anchors everything is simple: what would one hour of this being down cost us?
Step 2 — Tier Your Systems
Group systems by business impact rather than treating them individually. A practical three-tier model works for most organisations:
| Tier | Description | Typical RTO | Typical RPO |
|---|---|---|---|
| Tier 1 — Mission critical | Revenue stops or safety is affected | Minutes to 1 hour | Minutes to 1 hour |
| Tier 2 — Business important | Disruptive but not immediately revenue-ending | 4–8 hours | 4–12 hours |
| Tier 3 — Standard | Can wait without material harm | 24–48 hours | 24 hours |
These ranges are illustrative starting points, not prescriptions. Your tiers should reflect your own cost-of-downtime analysis. The value is in forcing a deliberate conversation about which systems truly belong in Tier 1 — because everything in Tier 1 carries the highest cost to protect.
Step 3 — Get Business Sign-Off
RTO and RPO are business decisions wearing technical clothing. The person who owns the revenue impact must own the target. IT can advise on what is achievable at what cost, but the acceptance of risk — "we are comfortable potentially losing up to four hours of data on this system" — has to come from leadership, in writing. This single step prevents the most damaging DR failure of all: a recovery that performs exactly as designed but falls short of what the business silently assumed.
Step 4 — Match Technology to the Target
Only now does technology enter the picture. Your backup frequency, retention, replication, and failover design all flow from the targets you set:
- A one-hour RPO demands backups or replication at least every hour. Daily backups cannot deliver it, no matter how good they are.
- A one-hour RTO demands rapid restore capability — pre-staged recovery images or standby infrastructure, not a multi-hour rebuild from scratch.
- Looser Tier 3 targets can be met with standard daily cloud backup at far lower cost.
This is where Cove Data Protection fits naturally. Its block-level TrueDelta technology produces incremental backups dramatically smaller than traditional methods, making frequent backups practical even on constrained South African bandwidth — which is what tight RPOs actually require. For demanding RTOs, Cove's Standby Image provides a recovery point that can be brought online quickly rather than rebuilt slowly. And because backups are immutable and stored off your production network, ransomware cannot quietly destroy the very copies your RPO depends on.
The Test That Proves Your Targets Are Real
A recovery target written in a document is a hypothesis. The only way to know whether you can actually hit two hours is to rehearse it and measure. Run restore tests, record the real recovery time, and compare it honestly against your RTO. If the test takes six hours against a two-hour target, you have a choice: invest to close the gap, or revise the target to something truthful. Either outcome is better than discovering the shortfall during a live incident.
Cove automates much of this verification, running recovery testing on regular cycles and confirming that backups are genuinely restorable. Automated testing addresses RPO confidence — proving your recovery points are good — but you should still rehearse full restores periodically to validate RTO end to end, including the human steps.
Common Mistakes to Avoid
Setting one target for the whole business.
Different systems carry different stakes. Uniform targets either overspend or under-protect.
Confusing the two.
A tight RTO with a loose RPO means you are back online quickly but missing a chunk of recent data. Decide both deliberately.
Ignoring dependencies.
A Tier 1 application that depends on a Tier 3 database inherits the weaker target in practice. Map dependencies so your tiers are coherent.
Never testing.
An untested target is a guess. Rehearsal is the difference between a plan and a hope.
How OAS Helps
OAS builds disaster recovery plans around realistic, tested recovery targets — not aspirational numbers that fall apart under pressure. As the "Recover" pillar of our Protect, Detect, Recover methodology, and backed by Cove Data Protection, we help South African organisations set defensible RTO and RPO targets, deploy the technology to meet them, and prove recoverability through regular testing.
With over 40 years of enterprise IT experience in South Africa, we have seen what happens when recovery targets are guessed rather than engineered. Let us help you set yours honestly.
Hope is not a recovery target.
OAS sets RTO and RPO you can actually meet — and tests them.