A disaster recovery runbook is a specific, written set of steps for what to actually do when something goes seriously wrong — who to contact, where backups live, how to restore, in what order — written calmly in advance, so that during an actual incident nobody’s improvising a recovery plan under pressure for the first time.
Disaster recovery runbook creation
A written, step-by-step recovery plan for when something goes seriously wrong — written calmly, before it does.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Details of your current hosting, backup system, and any relevant third-party services
- Who should be contacted or involved during an actual incident
- Any past incidents worth reflecting in the runbook’s specific guidance
This or something else?
| You want a written, step-by-step plan for responding to a serious site incident | This fix covers it |
| You want the backup system itself improved, not just documented | Backup system setup & schedule configuration, a related but different fix |
| You’re currently in the middle of an active incident and need help now, not a plan for next time | Contact us directly and describe the situation — this runbook is for future preparedness |
| You want a post-incident security review after cleanup, not a general recovery plan | Post-incident hardening review |
What we do
- Document your current hosting, backup, and infrastructure setup
- Define clear, ordered steps for the most likely disaster scenarios (site down, data loss, compromise)
- Include specific contact information and escalation paths
- Write recovery steps in plain, actionable language, not generic advice
- Review the runbook with you to confirm it reflects your actual situation
- Deliver it as a clear, accessible document your team can find quickly when needed
What is included
- A written, scenario-specific disaster recovery runbook
- Clear escalation and contact information included
- A review session to confirm accuracy and completeness
- A copy in a format that’s easy to find and use during an actual incident
Not included
- Actually responding to an incident, a separate service if and when needed
- Implementing infrastructure changes the runbook might recommend, quoted separately
- Ongoing updates as your setup changes, unless separately arranged
- Testing the runbook through a simulated incident, a related but separate exercise
Questions about this fix
How is this different from just having good backups?
Backups are one component of recovery; a runbook is the plan for using them and everything else correctly under pressure — who does what, in what order, with what information, which good backups alone don't provide.
Will this actually help if I'm not technical myself?
We write it in plain, actionable language specifically so it's usable by whoever needs to act during an incident, technical or not, rather than assuming deep technical fluency.
Should I test this runbook somehow, or just trust it as written?
A simulated run-through is a valuable, separate exercise worth considering — a runbook that's never been tested carries some uncertainty about whether it actually works as smoothly as written.
How often should this be updated?
Whenever your hosting, backup system, or key contacts change meaningfully — a runbook describing an outdated setup is less useful exactly when you'd need it most.
What kinds of scenarios does this actually cover?
The most realistic ones for your setup — site down, significant data loss, a security compromise — rather than an exhaustive list of every conceivable failure, most of which would follow similar core steps anyway.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.