Your backups are running. Every morning the system sends a green email, sometimes a weekly summary. Nobody looks too closely — after all, it’s green. The uncomfortable question eventually comes from outside: from the cyber insurer, from an auditor, from the statutory accountants: “When was a restore actually last tested?” We build a backup drill with you that can answer that question honestly.
Does this sound familiar?
- Your backup software has been reporting green jobs for years. Whether the data can actually be recovered in an emergency, nobody has systematically tested since the rollout.
- Nobody can say off the top of their head how long a realistic restore of the ERP server would take. The answer varies between “a few hours” and “probably a day” — depending on who you ask.
- Microsoft 365 is in place, but there is no third-party backup for Exchange, SharePoint or OneDrive. If someone deletes a mailbox or ransomware encrypts one, the answer is “Microsoft handles that” — and that’s only half true.
- The cyber insurer has sent a questionnaire asking about “tested restore procedures”. You’ve left the question open because you don’t know how to answer it honestly.
- There is no documented RTO (Recovery Time Objective) and no RPO (Recovery Point Objective) — that is, no written agreement on how long an outage may last and how much data loss is tolerable.
Why now — and not later
Backup is one of the areas where promise and reality drift furthest apart. A green backup message means data was written — not that it’s readable, not that the right data is in it, and certainly not that recovery works in an acceptable time. Postponing the drill just postpones the problem until the real thing happens.
Typical triggers that put this on the agenda now:
- A ransomware wave in your industry — a competitor was hit, and the leadership team starts asking “Are we prepared?”.
- The cyber insurer asks — the questionnaire demands proof of tested restore procedures, otherwise the premium rises or the insurer declines to underwrite.
- NIS2 preparation — business continuity and disaster recovery are mandatory topics if you’re directly in scope or have to provide evidence as a supplier.
- An audit finding — the statutory auditors or internal audit have flagged the topic.
- An M365 account actually was compromised — and you discovered that recovery is more complicated than expected.
What this would look like for you
Step 1 — Set RTO and RPO per system
We sit down with you and management and go through the systems that matter: ERP, file storage, mail, CAD, industry software. For each system we clarify: how long can it be down, at most, before the business seriously suffers (RTO)? How much data loss is tolerable — one hour, four hours, one day (RPO)? That’s a business decision, not an IT decision. Delivery: a compact table with a written RTO/RPO agreement for each system. That puts an end to the “probably a day” guessing.
Step 2 — Define restore scenarios
Together with you we pick three to five realistic scenarios to exercise. A typical mix for a mid-market company:
- Scenario A — restore a single file: someone has deleted an engineering drawing and needs the version from two days ago.
- Scenario B — restore a complete VM or server: the ERP test server is dead and needs to be brought up from backup on new hardware or in Azure.
- Scenario C — restore an M365 mailbox after a compromise: an employee was phished, attackers manipulated the mailbox, and you need it as it was 24 hours earlier.
- Scenario D — restore a SharePoint site or OneDrive folder: a site was accidentally deleted or encrypted.
- Scenario E — full ransomware outage: multiple systems are encrypted — what gets restored, and in what order?
Delivery: a scenario list with a clear success definition for each one. What has to work at the end of the drill for the test to count as passed?
Step 3 — Run the drill in an isolated environment
We set up an isolated test environment with you — a separate Azure subscription, a VM sandbox or a dedicated test area. That’s where we run the scenarios. In scenario B, the ERP test server really is restored from backup, started, and validated against the database. In scenario C, a test mailbox is restored and its contents checked. A stopwatch runs throughout the drill — for each scenario we record how long it actually took, where things got stuck, what was unclear. Delivery: a drill report with real times, real data volumes, real obstacles. No theory.
Step 4 — Assess the gaps and write a restore runbook
After the drill you have three kinds of findings: what worked (sometimes surprisingly well), what took longer than hoped, and what didn’t work at all. Together we assess the gaps. Some are technical (too little bandwidth to the backup target, wrong retention setting, missing indexing), some are organizational (nobody knew where the recovery password was kept, the responsible person was on holiday). From this a restore runbook emerges: a step-by-step guide per scenario that a stand-in can execute in an emergency. Delivery: a runbook of 5 to 15 pages, not a novel.
Step 5 — Agree on a repeat rhythm
A one-off drill is better than never — but it ages. We agree a realistic rhythm with you: a full drill once a year, plus a small spot check of individual scenarios every six months. That fits a mid-market company without blocking day-to-day business. Delivery: a calendar rhythm with clear responsibilities and a mini-template that halves the preparation effort next time.
What to look out for
- Insist that the drill runs in an isolated environment — not on production. Anyone who proposes a “live restore test on the running system” has no plan B if the test goes wrong. A separate sandbox is non-negotiable.
- Ask for the success criterion per scenario before the drill starts. “We test the restore” is not a criterion. “A mailbox in the state from 24 hours ago is available and readable in the test tenant” is.
- Be wary of backup software that sells its built-in validation as a restore test. Integrated job verification is useful, but it isn’t a full drill. It checks whether the backup file is readable, not whether the restored system works.
- Clarify before the drill who gets informed, and in what order, if the test goes wrong. Even an exercise can trigger an incident — for example if the restore attempt hits a backup licensing limit and no further jobs can run.
- Write the runbook for the person with the least knowledge, not for yourself. In a real emergency, the specialist is on holiday. If the specialist is the only one who can follow the runbook, it isn’t a runbook — it’s a personal note.
What realistically changes afterwards
- You have it in black and white how long a realistic restore takes per scenario — and which data volumes are actually recoverable.
- You answer the cyber insurer’s question about tested restore procedures with a written report, not with “we’ll get to it soon”.
- When the real emergency hits, there is a runbook that a stand-in can execute.
- RTO and RPO are no longer gut feeling but a written agreement between IT and management — with realistic values.
- Gaps in the backup concept (missing M365 backup, retention that’s too short, unfavourable restore targets) are known and prioritized, instead of lying dormant undetected.
What you contribute
- A person who knows the backup system from the admin side and is reachable during the drill.
- Access to the backup console, to the target environment (Azure, local hardware) and to the test data.
- Roughly half a day to a full day of your IT lead’s time per drill, plus around 2 hours of stakeholder time for setting RTO/RPO with management.
- A willingness to accept honest results — even if the first drill shows that restore times are longer than previously assumed.
Risks — and when this isn’t the right fit
- If your backup system is outdated and a version upgrade is due anyway — do the upgrade first, then the drill. There’s little point in testing an architecture that will be replaced in three months.
- If you don’t have a systematic backup solution at all yet, just “a few scripts and external hard drives” — set up the solution first, then run the drill. We help with both, but in that order.
- If management expects the drill to be a rubber-stamp exercise where nothing is allowed to go wrong — better to clarify beforehand that finding gaps is exactly what a drill is for. If you don’t want to find gaps, don’t run a drill.
How the conversation starts
- A free 30-minute initial conversation, by video or phone.
- What we clarify: your current backup solution, which systems it covers, your most pressing question (insurance, audit, gut feeling), and a time window for a first drill.
- Useful to have ready, though optional: a screenshot of your latest backup overview, whether an M365 backup is in place, and a rough idea of which systems are business-critical.
Frequently asked questions
Isn’t it enough if our backup software verifies the jobs internally? Internal verification checks whether the backup file is readable — helpful, but not sufficient. A real restore drill checks whether the recovered system actually works: whether the database starts, whether the application connects, whether users can sign in. That’s a different class of test.
Do we really need a third-party backup for Microsoft 365? Often yes, but not always. Microsoft protects the infrastructure — what Microsoft does not provide is a long recovery horizon for accidentally deleted or attacker-manipulated data. The default retention for permanently deleted emails is 14 days (extendable to a maximum of 30); deleted mailboxes remain recoverable for 30 days. If you need to go back further, you need your own solution. The drill makes this visible very quickly.
How long does a drill take overall? Preparation and scenario definition around one week, the actual drill typically one day in the sandbox, evaluation and runbook writing one to two weeks. For the first iteration that’s about 3 to 4 weeks end to end, with a manageable time commitment on your side.
What if the drill shows our backup concept has gaps? That’s exactly what the drill is for. Gaps are, first of all, good news — they’re known, instead of surprising you in an emergency. Together we prioritize which gaps need closing first and which are acceptable. Not every gap has to be fixed immediately, but every one should be a conscious decision.