The uncomfortable truth about backups is that most small businesses have them set up, assume they’re running, and have never once verified that a file can actually be recovered from them.

This matters because backup failures are common, silent, and tend to be discovered at the worst possible time. A drive fails. A server gets ransomware. Someone accidentally deletes a folder that took three years to build. Then you go to restore from backup and find out the backup job has been failing for months, the backup software license lapsed, or the recovery process requires software that no longer exists.

Testing takes less time than a failed recovery. Here’s how to do it.

Why backups fail silently

Before running a test, it helps to understand the common failure modes:

• The job completed, but the files aren’t actually there. Backup software can report success while backing up empty folders, locked files it couldn’t access, or destinations that ran out of space mid-job.
• The destination isn’t where you think it is. External drives get unplugged and not re-plugged. Network paths change when someone renames a server. Cloud sync pauses and never resumes.
• The software can’t restore without a license. Some backup applications require an active subscription to perform a restore. If your license lapsed, you may have months of backup files you can’t access.
• The backup is there, but restoring it requires the original machine. Certain backup formats are tied to the hardware or OS version they were created on — which becomes a problem if the original machine is the one that failed.

How to run a basic restore test

You don’t need to restore everything. A targeted test of a few critical files tells you what you need to know.

Pick something important and specific. Choose a file or folder that would cause a real problem if it were gone — an accounting file, a client database, a year’s worth of invoices. Not a random test file you created for this purpose.

Try to restore it to a different location. Don’t restore over the original — restore to a different folder (e.g., C:\restore-test\). This confirms the restore process works without touching your live data.

Open the restored file and verify it. A file that restores but won’t open, or opens to blank/corrupted content, is not a good backup. Open it, check that recent changes are reflected, and confirm the content is intact.

Check the backup date. Confirm the version you restored is from the date you expected. If the last good backup is three weeks old when you thought it was nightly, you have a gap to close.

What to check for common backup setups

Windows File History or Windows Backup

Windows File History backs up files in your user folders (Documents, Desktop, Pictures, etc.) to an external drive or network location. To test it:

1. Open File History (Settings → Update & Security → Backup, or search “Restore your files with File History”)
2. Browse to a file you want to test, select a version from a known date, and click Restore to → Choose location
3. Open the restored file and confirm it’s intact

Confirm the external drive is still connected and the backup schedule is running: if the drive has been disconnected, File History stops silently.

Windows Server Backup / Windows Backup (Business)

For servers or business PCs using Windows Server Backup or the Windows Backup application:

1. Open Windows Server Backup from Server Manager or search
2. Go to Local Backup → Recover
3. Work through the recovery wizard: select the backup date, choose “Files and folders,” navigate to your test file, and restore to an alternate location

Check the event log (Event Viewer → Windows Logs → Application, filter for “Microsoft-Windows-Backup”) for any recent failures or warnings you may have missed.

Cloud backup (Backblaze, Acronis, Carbonite, etc.)

Each provider has a different restore interface, but the test is the same: log into the backup console, find a specific file from a known date, download the restored version, and open it. Pay attention to how long the restore takes — a cloud restore that would take 72 hours to complete for your full dataset is useful to know now, not during an emergency.

Also confirm your retention window. Many plans keep 30 days of version history by default. If you need to recover from something that happened 45 days ago, you may be outside your window.

NAS (Synology, QNAP, etc.)

If your files live on a NAS and the NAS itself backs up to an external drive or cloud:

1. Access the backup application on the NAS (Hyper Backup on Synology, QNAP Backup on QNAP)
2. Use the built-in restore explorer to browse a past version and restore a test file
3. Verify the restored file on your workstation

Also check that the NAS backup is actually completing: NAS backup jobs fail when external drives fill up or cloud credentials expire, and the alert emails often go to an address nobody checks.

The questions to answer before you’re done

By the end of your test, you should be able to answer all four of these:

1. What’s the most recent backup I can recover from? If it’s today, good. If it’s three weeks ago, that’s your exposure window.
2. How long would a full restore take? For cloud backups especially, this is often longer than people expect.
3. What would I need to restore to bare metal? If your server dies completely, do you have the OS license, the backup software, and the recovery media needed to rebuild? Where are those things stored?
4. Who knows how to do this besides me? Backup recovery during an emergency is not the time for someone to follow a procedure for the first time.

If you can’t answer any of these, that’s what to fix next.

How often to test

Once a year is the minimum for most small businesses. Quarterly is better if you’re running anything mission-critical. Every time you change something significant — new backup software, new destination, new server — run a test before you need it.

Set a calendar reminder. Put it on the IT calendar if you have one. The test takes 20 minutes. The emergency it prevents can take days or weeks.

Frequently Asked Questions

How long should a backup test take?

For a targeted file restore, 20–30 minutes. A full bare-metal recovery test takes longer and should be done at least once so you know your actual recovery time objective before an emergency makes it relevant.

Does the backup software showing “success” mean it worked?

Not reliably. Backup jobs can report success while backing up empty folders, locked files, or destinations that ran out of space mid-job. The only test that counts is successfully opening a restored file from the backup.

What’s the most common backup failure we’ll find?

Either the external drive was unplugged and File History stopped silently, or a cloud backup license lapsed and recovery now requires a paid subscription you don’t have. Both are common and both are invisible until you test.