Why you need RTO and RPO before anything else
Most backup projects start with a tool and end with a surprise. A team enables snapshots, sets a retention of 30 days, and assumes the job is done. Then a region has an incident, or someone deletes a database, and the questions arrive all at once: how long will this take, and how much have we lost? Nobody agreed an answer in advance, so everyone improvises.
Recovery time objective (RTO) and recovery point objective (RPO) are the two numbers that remove the improvisation. RTO is how long a service can be down. RPO is how much data you can lose, expressed as time. They drive every later decision in a backup and disaster recovery programme: which services get a standby environment, how often data is copied, and how much you spend.
Our RTO and RPO definition work is the first step of every engagement, because a design without targets is just a guess about what the business wants.
What good looks like
A good outcome is short and specific. You should end the workshop with:
- A list of services grouped into three or four tiers, each with a named business owner.
- An RTO and RPO for every tier, with the assumptions written next to them.
- A dependency map showing what must recover first.
- A rough cost range for each tier, so the numbers are a trade, not a wish.
- A sign-off from someone with budget authority.
A weak outcome is a spreadsheet with “RTO: 1 hour, RPO: 15 minutes” copied into every row. It looks reassuring and means nothing, because nothing has been priced or tested.
How the workshop works in practice
Before the session
We collect facts first so the meeting is not spent on discovery. From your Terraform code, cloud accounts and architecture diagrams we list services, data stores and external dependencies. For each, we ask owners two plain questions in advance: what breaks for the customer if this is unavailable, and what do we lose if the last day of data vanishes?
In the room
The session runs two to three hours with engineering, product and a finance or operations voice. We take each service and ask the owner to describe impact at one hour, one day and one week. Impact is concrete: orders not taken, support tickets, contractual penalties, regulatory reporting, staff idle. We resist the instinct to call everything critical by asking what the business would give up to make that service recover faster.
Then we propose tiers. A common starting shape looks like this:
| Tier | Typical services | Recovery pattern | Relative cost |
|---|---|---|---|
| 1 | Customer facing transaction path, auth | Warm standby or active-active | Highest |
| 2 | Core internal tools, APIs with retries | Pilot light | Moderate |
| 3 | Reporting, batch jobs, staging | Backup and restore | Lowest |
The real numbers are yours to set. The table shows the shape of the conversation, not a recommendation.
Dependencies decide the real RTO
A service with a 30 minute target is not recoverable in 30 minutes if it needs a database that takes two hours to restore, or an identity provider that sits in the failed region. We trace startup dependencies and take the slowest one as the true floor. This is the finding that most often changes a target, and it is far cheaper to discover on a whiteboard than during an outage.
Decisions and trade-offs
Tighter is not better. Halving an RTO can multiply cost, because you move from restoring from backup to running standby capacity. Leaders should see that curve before choosing.
RPO and the data type. Not all data deserves the same RPO. Transaction records may need near-continuous replication, while a cache can be rebuilt and needs no backup. Splitting data by recoverability often lowers cost without raising risk.
Compliance floors. Contracts, sector rules or customer questionnaires may set minimum recovery capabilities. We note these as constraints, not as the target itself, and we do not claim any certification on your behalf.
When not to run a full workshop. A two-person startup with one service and one database does not need a half-day session. A one-page agreement between founders and the engineer is enough, as long as it exists and is tested. The workshop earns its cost when you have several services, several owners or contractual obligations.
Common failure modes
- One number for everything. It is either too expensive or too weak. Tiering fixes this.
- Engineering sets the targets alone. The numbers reflect what is easy to build, not what the business needs.
- Ignoring the human part of RTO. Time to detect, decide, page people and run steps counts. A four hour technical restore is a six hour outage if nobody knows who decides to start it. Our disaster recovery runbooks address this directly.
- Targets that nobody tests. An RTO you have never measured is a hope. We attach every target to a test in the restore testing schedule.
- Silent drift. The product grows, the database triples, and the old restore time is no longer true.
Delivery and handover
You receive a short recovery objectives register: service, tier, owner, RTO, RPO, dependencies, assumptions and the date of the last review. It lives in your documentation tool or repository, not in a slide deck. It becomes the input to backup strategy design and to the business continuity plan. We also leave a template so your team can add new services to the right tier without us.
How to tell it is working
The register is current and every row has an owner. New services are tiered before launch. Measured restore and failover times from drills sit next to the targets, and the gaps are visible and tracked. When a leader asks “how long would we be down?”, the answer is a number backed by a test, not a shrug.
If you want to set realistic recovery targets before you buy any tooling, book a consultation and we will start with your most critical service.