Glossary
RTO and RPO: Meaning, Difference and Examples
RTO and RPO are the two numbers a disaster recovery plan is built on. The recovery time objective (RTO) is the longest a system may stay down after a disruption before the harm to the business is unacceptable. The recovery point objective (RPO) is the most data, measured in time, the business can afford to lose. RTO is about downtime; RPO is about data loss. This entry puts RTO vs RPO on one timeline, gives examples by system tier and shows how to calculate both.
Glossary Published 6 min read
RTO and RPO meaning
RTO and RPO meaning, on one timeline
Both targets are measured from the same moment: the disruption, whether a failed storage array, a ransomware attack or a data centre losing power. RPO looks back from that moment to the last good copy of the data. RTO looks forward to the moment users have the service back.
Read more
- Recovery point objective: if the last good copy was taken at 02:00 and the failure happens at 10:00, everything entered in between is gone unless it is re-keyed. An RPO of one hour says that gap must never exceed an hour.
- Recovery time objective: if the service is back at 14:00, it was down for four hours. An RTO of two hours says it must be back within two.
Both are objectives, set before anything fails. A recovery drill shows what you actually achieve.
How to calculate RTO and RPO
Ask the people who run each system, not IT alone: how much recent work could we re-create by hand, and how long can we work without the system before real harm?
Worked example, with illustrative figures: an online ordering system takes about 300 orders an hour. The sales team can re-key at most 50 lost orders, so RPO = 50 ÷ 300 hours = 10 minutes. A manual fallback covers one hour, and after two hours customers go elsewhere, so RTO = 1 hour.
Then check the design: a nightly backup can lose a day of orders, far beyond a 10-minute RPO.
Compared
RTO vs RPO
The two targets are met by different parts of the design, so they are set and tested separately.
| RTO (recovery time objective) | RPO (recovery point objective) | |
|---|---|---|
| Question it answers | How long can we be down? | How much data can we lose? |
| Measured | Forward from the disruption to service restored | Back from the disruption to the last good copy |
| Set mainly by | The standby environment and the recovery runbook | How often data is copied or replicated |
| Made smaller by | A warmer standby, automation and rehearsed failover | More frequent copies, up to continuous replication |
| Example target | Service back within 4 hours | No more than 15 minutes of data lost |
Read RTO with MTTR: RTO is the target for one serious disruption, while MTTR is the average time your incidents actually take to recover.
What sets them
Replication frequency sets RPO; standby type sets RTO
RPO follows how often the data is copied
A nightly backup can lose up to a day of data; hourly snapshots, up to an hour. Continuous replication sends each change to a second copy shortly after it happens, so the loss shrinks to the replication lag at the moment of failure.
RTO follows what is waiting on the other side
Read more
With a cold standby, servers are provisioned and data restored after the disruption: hours to days. A warm standby already runs, often smaller, with current data, so recovery is a switch-over and a scale-up. A hot standby runs at full size and takes traffic within minutes. Each step warmer costs more.
The two are independent
Continuous replication into a cold site gives a small RPO and a long RTO; a hot standby fed nightly gives the reverse.
By tier
RTO and RPO examples by system tier
Most organisations group systems into a few tiers. The figures below are illustrative examples, not a standard.
| Tier | Example systems | Illustrative RPO | Illustrative RTO | Usual approach |
|---|---|---|---|---|
| 1. Critical | Core banking, payments, online checkout | Near zero to a few minutes | Minutes to one hour | Continuous replication to a warm or hot standby; rehearsed failover |
| 2. Important | ERP, customer portal, CRM | 15 minutes to one hour | 2 to 8 hours | Frequent snapshots or replication; warm standby |
| 3. Supporting | HR, reporting, email archive | 4 to 24 hours | 1 to 2 days | Regular backups restored onto standby capacity |
| 4. Low impact | Intranet, test environments | 24 hours | Several days | Nightly backup; rebuild when needed |
Your own figures come from a business impact analysis: what an hour of downtime or lost data costs each process.
Good practice
Common mistakes, and what good practice looks like
- One target for everything, set by IT alone. RTO and RPO are business decisions per system; IT says what each costs to meet.
- Treating replication as a backup. A replica copies deletions, corruption and encrypted files within seconds. You still need backups you can restore to a point before the damage.
- Forgetting dependencies. A database restored in 20 minutes does not help if identity, DNS or the application servers take a day.
- Never testing. Run a recovery drill, time it from the start of the disruption, and record the actual figures beside the objectives.
iblync and Interkey
Where iblync real-time replication and Interkey fit
For a database whose RPO is shorter than its backup interval, iblync real-time replication, Interkey's own platform, streams each change from the source to a target shortly after it happens. Changes queue while the target is unavailable, and throttling stops replication competing with production. iblync states no fixed delay: the lag depends on your change rate, source and target, so we agree it in scoping.
Read more
Replication shortens RPO; it does not set RTO, and it does not replace backups. RTO depends on the standby environment and the runbook, which is the subject of Interkey's disaster recovery work: tiering, standby design and drills. Backups against corruption are covered under cloud backup. Where a database vendor supplies a supported native replication path, use that first; it is usually cheaper.
Relatediblync real-time replicationInterkey's disaster recovery workcloud backup
In a Saudi context
In a Saudi context
A standby copy is still a copy of your data, so the data residency decision that applies to production applies to it too. Many organisations in the Kingdom place the recovery site in a second Saudi location or cloud region for that reason. The National Cybersecurity Authority's Essential Cybersecurity Controls include cybersecurity resilience among their main domains, and sector regulators may set their own expectations; our NCA ECC guide explains the framework in general terms. Interkey's engineers support recovery planning from Riyadh, in Arabic and English.
Questions teams ask about RTO and RPO
Which matters more, RTO or RPO?
Neither in general. For payments, lost transactions may be worse than an hour offline, so RPO leads. For a public website, downtime is the harm, so RTO leads.
Can RPO really be zero?
Only when every change is confirmed on a second copy before it is accepted, which slows each write and needs the sites close together. Most designs accept seconds or minutes instead.
Does our disaster recovery copy have to stay in Saudi Arabia?
It follows the same data residency rules as production, because it holds the same data. Check your data classification and your sector regulator's requirements.
How much does a shorter RTO or RPO cost?
A warmer standby means more capacity running unused; continuous replication means licences, network and monitoring. We price it per tier after scoping, so only systems that need tight targets carry that cost.
How often should we test our recovery targets?
At least once a year for every tier, and after any major change to a critical system.
How long does it take to set up replication for a shorter RPO?
It depends on the source and target, the data volume, the daily change rate and the network between sites. We estimate after scoping and say what drives the estimate.
Next
Read next
Next step
Set recovery targets for your systems
Tell us which systems matter most and how you back them up today. We will help you set RTO and RPO per tier and show what meeting them takes.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia