The questions that matter
If your production database was corrupted at 2pm on a Tuesday, how much data would you lose, and how long until customers could log in again? If you can't answer both in numbers, that's what this project fixes. Not with a fifty-page plan. With numbers you've agreed to and a restore you've actually watched succeed.
What I do
- Audit what's actually being backed up, versus what everyone assumes is
- Agree recovery targets in plain english: how much loss is tolerable, how long an outage is survivable
- Fix the gaps: coverage, retention, isolation from ransomware (backups an attacker with your keys can't delete)
- Write the runbook: who does what, in what order, when things are on fire
- Run a live restore test and time it. This is the deliverable that matters
Why the test is non-negotiable
Untested backups fail at a rate that would genuinely surprise you. Snapshots that never completed, retention policies quietly deleting the thing you need, restores that take 14 hours when the business assumed one. Every one of those is fine to discover in a drill. None of them are fine to discover during an incident.