Backups You've Never Restored Aren't Backups: A 30-Minute Test

Almost every small business has a backup of some kind. Far fewer have ever tried to get something back from it. That's where the surprises live: the backup job that has been failing quietly for months, the folder that was never included, the encryption password nobody wrote down, or the restore that works but takes two days instead of two hours.

You don't need a disaster-recovery project to find out where you stand. Here is a restore test you can do in about 30 minutes, and then repeat every few months.

Before you start (5 minutes)

• Find out what is backed up, where the copies are kept, and how to sign in to the backup system. If nobody knows, you've already learned something important.
• Make sure you'll restore to a safe place: a new folder, a test mailbox or a spare machine. Never restore over the live copy during a test.
• Start a timer and a notes file.

Test 1: a single file (5 minutes)

Pick a file someone actually uses, from the shared drive, SharePoint or a server, not one you created for the test. Restore the version from about a week ago to a new folder. Open it and check it's the right file and isn't damaged.

This tests the everyday case: someone deleted or overwrote something and wants yesterday's copy back.

Test 2: a mailbox or a folder of email (10 minutes)

Restore one folder from a mailbox, or a handful of deleted messages, into a test location. If you use Microsoft 365 or Google Workspace, this is where you find out whether you have a real backup of email, or only the built-in retention.

Test 3: the thing you couldn't work without (10 minutes)

Every business has one: the accounting data, the line-of-business database, the server that runs the practice-management system. You won't restore all of it in ten minutes, but you can check three things:

• The most recent good backup of it exists, and how old it is.
• You can start a restore of it to somewhere safe, or at least open its contents in the backup system.
• A rough estimate of how long a full restore would take, from the backup system or from its size and your connection speed.

If the honest answer to the third point is "two days", that's worth knowing now, not during an outage.

Write it down

The record is as valuable as the test. For each restore, note:

• What you restored, from which date, and where to
• How long it took
• Whether it worked, and anything that went wrong or needed a password you had to hunt for
• Who did it and when

Keep these notes with your IT documentation. The next time you test, compare the times. If a cyber-insurer or auditor asks when you last tested your backups, you'll have the answer.

What a good result looks like

• Every test restore worked, and the data was the version you expected.
• You have more than one copy, including one that isn't simply another folder on the same network. Ransomware that can reach your files can often reach a backup stored right next to them.
• At least one copy is offline or immutable: it can't be changed or deleted, even by someone with an admin password, for a set period.
• Backup failures send an alert to someone who reads it.
• The passwords and encryption keys needed to restore are stored somewhere the business controls, not only in one person's head.

When the test fails

A failed test is a good outcome: you found the problem on a quiet afternoon. Fix the specific issue, whether that's a failing job, a missing folder or a lost key. Then repeat the same test until it passes. If the gaps are bigger, such as no offline copy or no backup of email at all, put them at the top of your IT plan.

Then put the next test in the calendar.