Restore drills
Testing that a backup actually restores: the quarterly drill Ilia Zavialov keeps on the calendar
Most small teams can point at a backup. Far fewer can say when somebody last sat down, picked a real file or a real mailbox, and brought it back onto a machine that did not hold the original. That gap between owning a copy and being able to work again is where an awkward morning turns into an expensive fortnight. This article treats testing that a backup actually restores as a short, scheduled piece of work with a name attached to it.
English version for the United States.
01
A copy is only a claim until somebody reads it back
Backup software is very good at telling you it succeeded. The dashboard turns green, the log says the job finished, the storage counter climbs. All of that describes the writing side of the work. Nobody has yet asked the archive to give anything back, and that is the only question the team will care about on the morning something goes wrong.
The ways a copy fails are dull and specific. An archive is encrypted with a key that lives only on the machine being backed up. An incremental chain breaks in the middle, and every newer file depends on a link that has gone. A folder was excluded eighteen months ago when a path changed, and nothing since has mentioned it.
The habit of testing that a backup actually restores turns that claim into a fact the team can lean on. The test itself is small. Pick something real, bring it back onto hardware that does not hold the original, open it, and check it against what people remember. If it reads correctly, the copy has earned its place. If it does not, the team has found out on a quiet Tuesday rather than during an incident.
02
Who owns the drill, and how often it runs
A drill with no name attached to it does not happen. Testing that a backup actually restores belongs to one person for a quarter, written down where the whole team can see it, and rotated through everyone who might one day have to do it for real. Rotation matters more in a team of eight than in a company with a service desk, because the person who built the backup will eventually be on holiday, ill, or gone.
There is a good reason to hand the restore to someone other than the person who configured it. Whoever built the system carries assumptions in their head: which credential to use, which console to open, which of the two similarly named folders is the real one. A colleague working from a written page will trip over every assumption that was never written down. Those gaps are the actual output of the drill.
Quarterly suits most small teams. Anything rarer stops being a habit and becomes a project, and anything more frequent eats a morning nobody has. A team gets the most out of the drill when it sits on the calendar beside the VAT return and the payroll run. When the team changes tools, hires, or moves a system to a new provider, add an extra drill in the month after the change.
03
The clock that matters is time back to work
Archive size tells the team very little. The number worth writing down is the interval between the decision to restore and the moment the first person is doing real work again. That interval swallows things nobody plans for: hunting for the credentials, pulling tens of gigabytes down an office connection, sitting in a provider's support queue, reinstalling the application that reads the file.
Small teams tend to be surprised in one direction. A single document comes back in minutes. A mailbox holding several years of history can take most of a working day, because the download and the reindexing run at their own pace. A laptop rebuilt from an image needs the machine, the image, and somebody free to sit with it for hours. Three honest numbers on one page change how the team plans around an outage.
Once the timings exist they can be argued with. If accounting cannot lose more than half a day at month end, and the drill says the accounting file takes a day and a half to come back, the team is looking at a concrete decision instead of a vague worry. An hour a quarter spent testing that a backup actually restores produces exactly this kind of evidence.
04
What turns out to sit outside the copy
Every team that runs a first drill finds something missing that everyone had assumed was covered. Mailboxes and shared drives hosted by a large provider feel permanent, and the retention window quietly disagrees. Deleted items leave the recoverable area after a fixed number of days. A departing colleague's account can be purged along with every document they were the sole owner of.
The second cluster is configuration rather than content. DNS records, registrar settings, the list of who has access to what, the website's environment variables, the invoices held inside a payment provider, the chat thread where a decision was explained. None of it lives in the folder the backup points at, and most of it is needed before the restored files become useful again.
The third cluster is the handful of secrets a team never writes down twice. Signing certificates, license keys, API tokens, and the authenticator app sitting on one phone that gates every administrative login. A file-level drill will never touch any of these, so give one drill a year the narrow job of proving that a second person can get into each critical account without the first person's help.
05
The restore log is the part people skip
Testing that a backup actually restores earns a plain page every time. Write down the date, the person, what was restored, where it was restored to, and how long each stage took. Add every point where something had to be looked up or asked for. Three lines of honest notes written during the work are worth more than a tidy summary assembled afterwards from memory.
The log does two jobs at once. It gives the next person in the rotation a written path rather than a rumour, and it shows patterns across quarters. If the same credential has to be hunted for in three drills running, that is a task, and it is now visible to everybody instead of living quietly in one colleague's irritation.
It also protects the team from the comfortable version of the story in which everything was fine. A dated page with real timings is something a client, an insurer or a new hire can read. A team that finishes the drill and records nothing keeps the same feeling of safety it had before, with none of the evidence.
06
When the drill stops being an exercise
Restores are usually needed after something ordinary: a deleted folder, a failed disk, a laptop left on a train. They are also needed after somebody gets into an account. The FBI's complaint center logged 1,008,597 reports for 2025 and close to 21 billion dollars in stated losses, 26 per cent above the previous year, which is the weather a small team now works in.
Business email compromise accounted for 3.046 billion dollars of that figure, second only to investment fraud. For a small team the practical shape of it is a mailbox that has been read by a stranger, a forwarding rule quietly copying invoices, and messages deleted to cover the trail. Recovering a clean copy of that mailbox from a point in time before the access is a restore question long before it is a legal one.
In the United Kingdom, UK Finance counted more than 4 million confirmed fraud cases across 2025. Figures on that scale say nothing useful about any single office, and they do make the arithmetic plain. A team that has already brought a mailbox back onto a spare machine will spend the bad day working through its own checklist while everyone else is reading documentation for the first time.
07
Fitting the drill into an ordinary month
Keep the scope small enough to survive a busy quarter. One system, one hour, one named person, one page of notes. A drill that needs a weekend will be postponed until it is quietly dropped, and a dropped drill leaves the team exactly where it started.
Rotate the target across the year so coverage builds up on its own. The mailbox in the first quarter, the shared files in the second, the accounting data in the third, a full laptop rebuild in the fourth. By December the team has restored every system it depends on at least once, and it holds four dated pages describing how each one behaved.
The habit is worth more than the tooling. A team with modest, well-understood backups and a quarterly drill gets back to work faster than a team with an elaborate setup nobody has ever read back. Testing that a backup actually restores is the step that converts hope into knowledge, and it is the step most often postponed to a calmer month that never quite arrives.
| What gets restored | Who runs it | Time back to work in that team's drills |
|---|---|---|
| A single deleted document | Anyone in the team, from the written page | Minutes |
| Shared drive folder with a year of files | Office manager or team lead | Under an hour |
| Full mailbox with several years of history | The person on drill duty this quarter | Most of a working day |
| Accounting file and its application | Whoever keeps the books, with support | Half a day to a day and a half |
| Website or shop from files and database | The developer on rotation | Half a day, longer if DNS moves |
| Laptop rebuilt from an image | Drill owner, with the person who uses it | A day, plus reinstalling extras |
| Access to a critical account without its usual owner | A second named person | An hour if the recovery path exists |
Questions and answers
How often should a small team be testing that a backup actually restores?
Once a quarter is enough for most teams of five to twenty people, with one named owner per drill. Add an unscheduled drill in the month after any change of provider, tool or office.
What counts as a successful restore test?
The data comes back onto hardware that did not hold the original, opens in the application that normally reads it, and matches what people remember being there. A restore that lands as an archive nobody has opened proves nothing.
Does a cloud drive count as a backup?
It covers a failed laptop and nothing else. Deletion, account takeover and retention limits all propagate through a synchronised drive, so the copy has to be somewhere the sync cannot reach.
How long should a restore take for a team of ten?
There is no single figure worth quoting, which is why the drill exists. In one team the pattern looked like this: a document back in minutes, a folder in under an hour, a full mailbox most of a working day. Every team has to measure its own.
Who runs the drill when there is no IT person?
Whoever is on the rotation that quarter, following a page written by the person who set the system up. The point of the exercise is that somebody without the original knowledge can complete it.
What data is usually missing from a small team backup?
Configuration and access rather than documents: DNS and registrar settings, permission lists, license keys, API tokens and the authenticator that gates admin logins. Provider retention windows also quietly limit how far back a mailbox can go.