How to actually test your backups: a restore drill

A backup you have never restored is a guess. The green checkmark in your backup console means a job ran, not that the data comes back, and we have watched businesses discover the difference in the worst possible week. This guide walks you through a restore drill: a scheduled, timed exercise where you actually pull data back and prove it works. By the end you'll have three successful test restores, real numbers for how long recovery takes, a written list of what broke, and the next drill on the calendar.

Prerequisites

• Admin access to your backup system, whatever it is: Veeam, Datto, Acronis, Synology Active Backup, Microsoft 365 backup, or even an external drive rotation.
• A restore target that is not your production system: a spare folder on another machine, a spare PC or server, or a temporary cloud VM.
• Two to three hours blocked off, ideally during a quiet part of the week.
• A rough recovery time objective (RTO): how long the business can function without its files and systems before real damage. If you've never picked one, write down your gut answer now, even if it's just "one business day." You'll test against it.
• A notes document open the whole time. The notes are half the value of the drill.

Step 1: Pick your three test subjects

You'll restore three things of increasing size:

1. One file. Pick something real and recently changed, like this month's invoicing spreadsheet. Not a test file you created for the drill; part of the point is proving the backup covers what people actually work on.
2. One folder. Pick a working directory a team depends on, a few GB with a mix of file types. A project folder or a shared department drive is ideal.
3. One full system. Your most important server or, if you're fully cloud, your most important workstation build or your Microsoft 365 site/mailbox. This is the test almost nobody runs and the one that matters most.

Write down each item's name, location, and size before you start.

Step 2: Restore the single file to an alternate location

Never restore over the live copy during a drill. Always restore to an alternate location, then compare. In your backup console, find the file-level restore option, select yesterday's (or the most recent) recovery point, and point the restore somewhere new, for example:

C:\RestoreTest\2026-07-13\invoices-june.xlsx

Start a timer when you begin and stop it when the file is open on screen. Then verify the content, not just the file's existence: open it, check it has current data, check it isn't zero bytes or corrupted. Note the recovery point's age too. If the newest available backup of a daily-use file is nine days old, your backup schedule has a problem the green checkmarks never mentioned.

Step 3: Restore the folder

Same idea, bigger scope. Restore the whole folder to an alternate path and time it. When it finishes, compare against the original. On Windows, a quick structural check from PowerShell:

Get-ChildItem -Recurse C:\Shares\Projects | Measure-Object -Property Length -Sum
Get-ChildItem -Recurse C:\RestoreTest\Projects | Measure-Object -Property Length -Sum

On macOS or Linux:

diff -rq /Volumes/Shares/Projects /Volumes/RestoreTest/Projects

Matching file counts and sizes is the floor. Also spot-open a handful of files of different types, including at least one that's password-protected or unusual, and confirm permissions came back sanely if the folder had restricted access. Note anything that didn't restore: some products silently skip locked or in-use files, and you want to know that today.

Step 4: Restore the full system

This is the drill's main event. Restore the full server or workstation image to an alternate target: a spare physical box, a VM on your hypervisor, or your backup vendor's cloud recovery option if you pay for one. Do not touch the production machine.

Keep the restored system off your production network (an isolated VM network or an unplugged cable is fine) so it can't fight the live machine over names and addresses. Then start the timer and note three separate durations:

1. Time until the restore job completes.
2. Time until the system boots to a login screen.
3. Time until it's actually usable: the key application opens, the database mounts, the data is there.

That third number is the real one, and it's routinely hours longer than the first. Log in, launch the line-of-business app, open recent records, and confirm services started. A server that boots but whose database won't mount is a failed restore that most drills would have marked as a pass.

Step 5: Compare your times against your RTO

Now put the numbers side by side. Say your gut RTO was one business day, and the full system restore took 14 hours of restore plus 3 hours of fixing before it was usable. That's a fail, and a cheap one, because you found it on a calm Tuesday instead of during an incident. Also multiply honestly: if one server took 14 hours and you have four servers and one restore pipeline, your real recovery is days, not hours.

If you missed the target, your options are ordered by cost: schedule more frequent backups (shrinks data loss, not restore time), add local backup copies so restores don't pull from the cloud over your internet line, or move to a backup product with instant-boot virtualization, where the backup itself runs as a temporary VM in minutes while the full restore happens behind it.

Step 6: Write down what broke, then calendar the next drill

Everything that surprised you goes in the notes: the admin password nobody remembered, the restore that needed a license key, the skipped locked files, the recovery agent that had to be reinstalled, the 3-hour gap between "booted" and "usable." Turn each into a to-do with an owner. This document, updated each drill, becomes the first draft of your actual disaster recovery runbook, and it's worth more than any template you could download.

Then put the next drill on the calendar before you close the console. Quarterly for the file and folder tests, at least twice a year for the full system. A recurring calendar invite with the checklist pasted in is enough. Drills that live in someone's head happen exactly once.

Verify it

You're done when you can point to all of these:

• Three restores completed to alternate locations, with contents verified by opening real files and apps, not just seeing filenames.
• Timed results for each, written down, including the boot-to-usable gap on the full system.
• A pass/fail call against your RTO, and a plan if it failed.
• A dated notes file listing everything that broke, with owners for the fixes.
• The next drill on the calendar with a named person responsible.

Do this twice and it stops being scary and starts taking an hour. That's the goal: recovery as a practiced routine instead of a hail mary.