A backup that has never been restored is not a backup. It is a theory. Backup testing is the part most small businesses skip because the backup software says the job completed, the cloud dashboard shows a green checkmark, and nobody wants to spend billable time proving something they assume already works.
The uncomfortable part is that the green checkmark usually means one narrow thing: some data was copied somewhere at some point. It does not prove the files are usable, the permissions are intact, the database is consistent, the backup includes the right folders, or the business can actually operate again within a reasonable amount of time. That is the gap that matters.
The Problem With Untested Backups
Small business backups usually fail in boring ways. The wrong folder was selected. A user saved work to a desktop instead of the shared location. A database file was copied while open and is now technically present but unusable. The backup destination filled up three months ago. The encryption key exists only in the head of the person who set it up. None of this looks dramatic until the restore is needed.
Ransomware has made this worse because attackers know backups are the escape hatch. In one 2024 ransomware report, 94% of organizations hit by ransomware said attackers attempted to compromise their backups, and 57% said those attempts succeeded.1 That should change how business owners think about backup testing. The question is not only whether yesterday’s files were copied. The question is whether the business has a recent, clean, recoverable copy that an attacker has not modified, deleted, or encrypted.
This is where small businesses are exposed. Larger companies usually have formal recovery testing, written recovery objectives, and someone whose job is to care about this every quarter. A 20-person firm often has a backup subscription, a shared drive, and an assumption. I understand why. Nobody starts a business because they want to spend Friday afternoon restoring accounting files into a test folder. But if nobody has ever done it, nobody actually knows what will happen.
Why Backup Failure Gets Worse Over Time
The damage from a bad backup rarely stops at lost files. It turns into downtime, rework, payroll delays, missed deadlines, uncomfortable client conversations, and a lot of expensive guessing. The first few hours are usually spent figuring out what is gone. The next few are spent figuring out what can be restored. Then comes the part nobody budgeted for: rebuilding the difference between the last usable backup and the day the failure happened.
Consider a 30-person accounting firm during tax season. This is hypothetical, but the mechanics are real. The firm has a file server, a cloud document folder, tax software data, scanned client documents, and years of working papers. They discover that a critical share is corrupted or encrypted. The backup system shows successful jobs for the last month, but nobody has tested a restore in over a year. When they finally try, the most recent backup contains the same corrupted files. The older backup is clean, but it is 11 days old. That does not mean they are down for 11 days. It means they have 11 days of missing work to reconstruct while still trying to answer phones and serve current clients. That is a very different problem from “restore the backup.”
This is why recovery time matters as much as backup existence. If your office can tolerate one day of missing work, then the backup schedule and retention need to support that. If you can tolerate four hours of downtime, then your recovery process needs to be tested against four hours, not against a vague hope that everything will probably be fine. I see a lot of businesses buy backup tools without ever defining the business requirement. That is backwards. The business requirement should drive the backup design.
The financial side is not theoretical. The average cost of a data breach reached $4.88 million globally in 2024, and while that number includes larger organizations, the lesson for smaller firms is still useful: downtime, investigation, legal review, customer notification, and operational disruption are where the cost piles up.2 Most small businesses will not see a $4.88 million event. Many can still be seriously hurt by a $25,000 event if it arrives in the form of two weeks of disruption, emergency IT labor, and a few lost clients who were already on the fence.
There is also reputational damage, which people tend to underestimate because it is hard to invoice. If you lose a client file and recover it two days later, that may be technically successful recovery. From the client’s perspective, you lost control of their information and had to go looking for it. That is not the same thing. Trust does not always disappear in one big moment. Sometimes it gets chipped away by delays, vague explanations, and the sense that your systems are held together by luck.
The worst cases are the cascading ones. A server goes down, the backup is incomplete, the person who knows the system is unavailable, the internet connection is saturated during the restore, and nobody knows which files are most critical. Each individual issue might be manageable. Together they turn a recoverable event into a business interruption. This is why I care more about restore testing than backup screenshots. Screenshots are easy. Recovery is where the truth comes out.
What Good Backup Testing Actually Proves
A proper backup strategy has two parts: automated offsite backup and periodic restore verification. Automated offsite backup means copies are created without someone remembering to drag files onto a drive, and at least one copy is stored outside the office or outside the primary system. Restore verification means someone periodically restores files, folders, or systems into a safe test location and confirms the data opens correctly.
For some businesses, file-level recovery is enough. That means restoring individual documents, spreadsheets, PDFs, and project folders. For others, especially offices with line-of-business applications, you may need image-based recovery, which captures an entire machine or server so it can be rebuilt more quickly. Businesses with higher risk should also look at immutable backup retention, which means backup copies cannot be changed or deleted for a defined period, even if an attacker gets into the main environment.
The right setup depends on how much downtime you can tolerate and how much data you can afford to recreate. Those are called recovery time objective and recovery point objective. Recovery time objective is how long you can be down. Recovery point objective is how much recent data you can lose. If those terms sound like consultant language, translate them this way: “How long can we be useless?” and “How much work can we redo without losing our minds?”
If you want a broader primer on why backup planning matters in the first place, I wrote about that here: Why Data Backup is Crucial for Small Businesses. But the short version is simple. Backups are not judged by whether they run. They are judged by whether they restore.
What You Can Do Right Now
You do not need a major project to start reducing this risk. You need to prove one small restore, document what happened, and repeat it on a schedule.
- Restore one important file today. Pick a file your business actually uses, restore it to a separate test folder, open it, and confirm it is the correct version.
- Check what is not being backed up. Look for desktops, downloads folders, local application data, scanned documents, and any shared folder created after the backup was first configured.
- Find your oldest clean copy. Make sure you know how far back your backups go. Seven days of retention is not enough if corruption sits unnoticed for two weeks.
- Write down where the encryption keys and admin credentials are stored. If the only person who knows this is unavailable, your recovery plan has a single point of failure.
- Time a restore. Do not just confirm that a file comes back. Measure how long it takes. A backup that restores 2 terabytes over a slow connection may be technically valid and operationally useless.
- Schedule backup testing quarterly. Put it on the calendar like payroll taxes or insurance renewal. If it is not scheduled, it will not happen.
The most useful test is not complicated. Restore a few files, restore one folder with permissions, and if you have a server or business application, test the recovery process before you are forced to do it under pressure. Backup testing is one of those maintenance tasks that feels optional until the day it becomes the only thing that matters.
Sources
1 State of Ransomware Report, 2024
2 Cost of a Data Breach Report, 2024
Want to assess your security posture? We offer complimentary security assessments for LA/OC businesses – no obligation, just a clear picture of where you stand. Reach out and we’ll walk you through it.
