Backups are running, but nobody has restored one
A backup job that reports success tells you a job ran. It does not tell you how long a restore takes, whether the thing that comes back is usable, or who would do it at two in the morning.
Usually raised by: CTO, infrastructure lead or risk owner.
What normally triggers it: A board question, a customer asking for recovery objectives, an incident near-miss, or a new risk owner reading the register.
- AWS
- PostgreSQL
- Terraform
You probably recognise some of these.
Not all of them, and not in this order. If three or four land, this is the page you want.
- "We have backups" is the complete answer to the question.
- Nobody can state a recovery time for the main workload with a straight face.
- The dependencies a restore needs — DNS, secrets, a queue, another service — have not been mapped.
- The person who would perform the recovery has never performed one.
What is different afterwards.
You get a measured recovery time for an agreed workload, a runbook someone other than its author can follow, and an explicit list of what is still not covered.
The work itself
- Agree recovery objectives per workload with the people who own them, rather than one number for the estate.
- Run the authorised, controlled restore and record what went wrong, because something usually does.
- Write the runbook for the person holding the pager, who will not be us.
Who does it: an InfraEdge engineer, who walks your team through what was found and answers your reviewer on each change.
One workload, restored and measured.
The one you nominate as most material, with an agreed recovery objective.
What is really captured today, dependencies included.
Into an isolated environment — production is never the test bed.
Elapsed time recorded, runbook followed by your engineer, not by us.
One workload, restored and timed
The workload you nominate as most material, restored into an isolated environment under an agreed window.
Done when
The restore has been performed, the elapsed time and the steps are recorded against the agreed objective, the dependency map is written down, and the runbook has been followed by someone from your team rather than only by us.
What you receive
- Recorded restore results — timings, steps, and what did not go to plan
- A dependency map for the recovered workload
- A runbook written for an operator who was not involved in the exercise
- A coverage gap list, prioritised, with what each would take
What we need from you
- An agreed window and an isolated environment to restore into
- A named person on your side who authorises the exercise
- Someone from your team to follow the runbook at the end, which is the part that proves it works
What makes it larger or smaller for you.
The variables that drive the size, judged against your own estate.
Larger if
- Several workloads, or a recovery that crosses regions
- Dependencies on other services that have to be stood up in order
- No isolated environment to restore into, so one has to be built first
Smaller if
- One workload with a clear owner
- Backups already managed centrally rather than per service
- An existing non-production environment the restore can land in
For a sense of elapsed time on work of this shape, the phased timeline on a comparable engagement is published with it. We do not quote a duration for your estate before seeing it, and the scope you receive after the call names the package rather than an hourly rate.
What this does not include.
Stated here rather than discovered later.
- Nothing destructive happens to production. The exercise restores into an isolated environment; anything else would need its own scope, window and approval from you.
- We do not guarantee a recovery time. We measure the one you have and tell you what it would take to improve it.
- This is not disaster-recovery certification, and it is not a substitute for your own regular exercises. One measured restore is a baseline, not a programme.
What if the restore fails?
Then the exercise has done its job — in an isolated environment, with people watching, not during an incident. A failed first restore is common and useful; it is why the work is worth doing before you need it. We record what failed and what it would take to fix.
What we can point at.
Anonymised prior delivery, described by technical shape. No client names, no logos, and no figures we did not measure.
Problems that tend to arrive together.
The incident is over, but the work it exposed is not
The patch shipped. The test that would have caught it, the alert that would have found it sooner, and the runbook for next time are all still open tickets.
An enterprise customer’s security review has stalled the deal
The useful move is to stop treating it as a document exercise. A questionnaire is a list of technical controls with a deadline attached, and most of them are engineering work.
Describe the project
Twenty minutes, no charge, with the engineer who would do the work. We work out whether this is the work you need and whether we are the right people — which is sometimes us and sometimes not. Nothing is priced on the call; if there is work worth doing, a written scope and a price reach you within 24 hours.