Two questions behind every recovery plan
When something fails, two questions matter more than most: how long will we be without the service, and how much recent data will we have lost? Recovery objectives turn these into agreed targets, so that everyone, from technical staff to managers, shares the same expectations before an outage rather than arguing about them during one.
Recovery time objective (RTO)
The recovery time objective is the maximum acceptable length of time a service can be unavailable after a disruption begins. It is measured from the moment of failure to the moment the service is working again at an agreed level.
If the RTO for an order system is four hours, the organization is saying that it can cope with up to four hours of downtime, but not much more. The RTO is a target to design for, not a promise. Whether you can meet it depends on how you have prepared.
The time includes more than copying data back. It typically covers noticing the problem, deciding to start recovery, getting hardware or a hosting environment ready, restoring data, reconfiguring, testing and letting users back in.
Recovery point objective (RPO)
The recovery point objective is the maximum acceptable amount of data loss, expressed as time. It asks how far back you can afford to go, meaning how old the most recent usable copy of the data may be.
A simple hypothetical: a system is backed up once a night at 1 a.m. If it fails at 5 p.m. the same day, the latest copy is 16 hours old, so up to 16 hours of work could be lost (from 1 a.m. to 5 p.m.). If the organization decides it can tolerate losing at most one hour of data, the nightly backup does not meet that RPO, and more frequent copies or continuous replication would be needed.
How they differ
RTO is about time to restore service. RPO is about the age of the data you restore. They are independent: a system could have a short RTO but a long RPO, for instance a static website that can be redeployed quickly and rarely changes, or a long RTO but short RPO, for instance an archive that is changed constantly but which people can do without for a day.
| Measure | Question it answers | What influences it |
|---|---|---|
| RTO | How long can we be down? | Restore speed, spare capacity, documentation, staffing |
| RPO | How much data can we lose? | Backup or replication frequency |
Setting sensible targets
Targets should come from the needs of the organization, not from what is easiest for IT. A practical approach:
- List the systems and processes that matter. Include the people who use them.
- Ask what a disruption would cost. Consider lost revenue, delays, regulatory trouble, customer trust and staff time. Talk to the people who depend on each system, not only to technical staff. Techniques from risk assessment help to structure this.
- Group systems into tiers. For example, a top tier that must return within hours, a middle tier that can wait a day, and a lower tier that can wait several days. Tiers keep the plan manageable.
- Set a target pair for each tier. Write down both RTO and RPO.
- Check what the current setup can really do. Compare targets with measured results, not hopes. Restore testing shows how long recovery actually takes.
- Close the gaps or adjust. If the gap is large, you can invest in better technology, or revise the target if the cost is not justified.
The cost of tighter targets
Shorter times cost more. Backing up once a day is simple and inexpensive. Backing up every few minutes, or replicating data to a second site that is ready to take over, needs more infrastructure, bandwidth, monitoring and skill. Faster restore may mean standby systems, hybrid cloud arrangements or well-prepared virtual machines. Cloud costs for standby capacity and storage should be weighed too. For many systems a moderate target is entirely sensible, and the aim is to spend on speed only where the impact justifies it.
Using the targets
Once agreed, recovery objectives guide many decisions:
- Backup frequency and type. RPO sets how often you copy data, and the choice between full and partial copies affects restore time.
- Storage and architecture. Local copies restore faster than distant ones.
- Contracts. If you rely on outside providers, check whether their service level agreements line up with your targets.
- Plans and priorities. A disaster recovery plan uses them to set the order of restoration.
Common pitfalls
- Setting targets nobody has checked. An RTO of an hour is meaningless if a restore takes six.
- Forgetting dependencies. An application’s target is limited by the slowest thing it needs, such as sign-in services or networks.
- Treating the numbers as guarantees. Real events involve surprises, so build in margin and communicate that these are objectives.
- Setting everything to “immediate.” This usually reflects a lack of discussion about priorities rather than real need.
- Never revisiting them. Systems and business needs change, so review the targets regularly.
Clear recovery objectives will not prevent outages, but they make the response measurable and the trade-offs visible.