Most backup software reports one thing well: the job finished. That is a fact about the copy. It says nothing about whether the copy can be restored, how long that takes, or whether the restored system works.

A restore drill answers those questions by doing the restore on purpose, on a schedule, before anyone needs it. The report is what makes the drill useful afterward. This article covers what a good report records, what a weak one looks like, and how to read one in five minutes.

A tick is not a test

CISA’s #StopRansomware Guide advises organizations to “regularly test the availability and integrity of backups in a disaster recovery scenario.” Two words in that sentence matter.

Availability means you can actually get the copy back, in a time you can live with. Integrity means what comes back is complete and usable: the file opens, the database mounts, the server starts and the app works. A green tick in a console proves neither. A written drill result can prove both.

If you have not run a restore test before, how to test a restore without breaking anything covers the method. This article is about the paper that comes out of it.

Nine things every report records

  1. Scope and date. What was restored, and why those items were chosen.
  2. Where it was restored. An isolated environment, so nothing touched the live systems.
  3. The recovery point used. Which backup version, with its timestamp, for each item.
  4. Start and finish times. For each item, so the elapsed time is measured, not estimated.
  5. The target. The recovery time agreed for that system, and whether it was met.
  6. How it was checked. Opened, counted, booted to a sign-in screen, or an app used to open a real record.
  7. What failed. Every failure, with its cause, even small ones.
  8. What was fixed. The change made, and the date it will be tested again.
  9. Who ran it and who reviewed it. By role, so you know who to ask.

Point 6 is where reports most often fall short. “Restored successfully” can mean the files were written to disk. It should mean someone opened them.

Signs of a weak report

  • It says “success” with no times.
  • Every item is a small file; no whole system is ever restored.
  • The same item is tested every quarter.
  • Nothing ever fails. A drill that never finds a problem is often not testing hard enough.
  • It arrives weeks later, or only when asked for.
  • Failures are listed with no fix and no retest date.

Example: a freight brokerage’s drill report

Take a 60-person freight brokerage. Its systems are a dispatch server with a database, a file server and Microsoft 365. During the Map phase, the business agreed a recovery time for each system. Here is what one quarter’s drill report might look like in summary:

Item Recovery point Agreed target Time taken Result
20 files from the shared drive, mixed sizes Tuesday, 2 p.m. hourly version 1 business hour 18 minutes Passed: all 20 opened
One mailbox, 14 GB Tuesday, midday copy 4 hours 1 hour 50 minutes Passed: item counts match, three old messages opened
Dispatch server, full system Monday, 11 p.m. image 6 hours 2 hours 35 minutes to sign-in Failed: dispatch app would not start

Under the table, the report explains the failure in plain words. The server restored and booted, but the dispatch software refused to start. Its license is tied to the hardware it runs on, and the restored machine looked like new hardware.

That is a real finding, and it is exactly the kind a drill exists to find. On a real day, the business would have had a working server, an app that would not open, and a software vendor’s support line to wait on.

The report then records the fix. The vendor’s license-transfer steps are now written into the runbook, with the account details stored where the recovery team can reach them. The dispatch server is booked for a retest five weeks later, inside the same quarter.

This is how the Restore Drill plan works. Each quarter we restore a sample of files, one mailbox and one full system to an isolated environment, time each one, and send a written result within 3 business days. Failures are fixed and tested again the same quarter.

Choosing what to restore each quarter

A drill is only as useful as the items it picks. A few rules keep the sample honest:

  • Rotate the full system. Restore the most important server first, then work through the others in later quarters.
  • Pick files at random, not the ones you know will work. Include old files, large files and files from deep folders.
  • Vary the mailbox. Choose a busy one, a shared one, and at some point the mailbox of someone who has left.
  • Follow the changes. A new server, a new app or a recent migration goes to the front of the queue.
  • Repeat the failures. Anything that failed last time goes back into the next drill, even after it has been fixed.

Over a year, that gives four whole-system restores and a broad spread of files and mailboxes, without ever touching the live systems.

Reading a report in five minutes

You do not need to be technical to read a drill report well.

  • Read the failures first. They are the most valuable lines on the page.
  • Check the recovery points. Are they as recent as you expected? An image from last week means a week of work lost.
  • Compare time taken with the target. Then compare it with last quarter. A restore that gets slower each quarter is telling you something.
  • Look at how it was checked. “Opened” and “app started” beat “restored.”
  • Check the rotation. The full-system item should change across quarters until every important system has had a turn.
  • Ask what changed in the runbook. Every finding should show up somewhere in the written steps.

When an item fails

A failure in a drill is the cheapest place to find a problem. It costs some time on a quiet day instead of a lost day on a bad one.

Treat it in three steps. Fix the cause, not just the symptom. Update the written recovery steps, so the next person does not repeat the mistake. Retest the same item, and keep the second result beside the first.

If you have no written steps to update, the Recovery Runbook plan builds them system by system, with a tabletop exercise to test the order. The drill itself sits in the Prove step of our method: Map, Copy, Prove, Restore. It is the step where a backup stops being a promise.

Keep every report

Drill reports are worth keeping, all of them, in one folder outside the systems they describe. One report shows a quarter. A year of them shows a trend: restores getting faster or slower, the same kind of failure coming back, a system that has never had its turn.

They are also useful outside IT. If an insurer, an auditor or a client’s security questionnaire asks whether you test your backups, a folder of dated, signed reports is a clear answer. It is far easier than describing a process from memory.

Questions to ask your provider

Whoever runs your backups, these questions will tell you a lot:

  • How often do you restore a whole system, not only files?
  • Where do test restores run, and how do you keep them away from live systems?
  • What do you record for each item, and can I see a sample report?
  • What was the last thing that failed in a drill, and how was it fixed?
  • How soon after the drill do I get the written result?
  • Who reviews the result before it reaches me?

Pair these with the 3-2-1 backup checklist and you have a fair picture of how ready your backups are.

A calm next step

If you have never seen a written restore result for your own systems, the free backup check is a simple first look. It takes 45 minutes, remotely, includes one test restore, and ends with a written page of findings. Book a free backup check when you are ready.