Every business I talk to has backups. Almost none of them have tested a restore.
That gap is where disaster recovery actually lives. A backup is a copy of your data. Recovery is your ability to get the business running again, in an acceptable amount of time, using that copy. Those are related, but they are not the same thing, and a company can be completely covered on the first one while being completely exposed on the second.
Here is the uncomfortable version. The backup job that has been showing green for three years is not evidence that you can recover. It is evidence that a job ran. What it backed up, whether those files open, how long a full restore would take, and whether anyone still working here knows the procedure are all separate questions, and nobody asks them until the day it matters.
The five things that actually go wrong
Nobody has tested a restore. This is the big one. Restores fail for boring reasons: the backup captured the database files while the database was running and they are unusable, the encryption key lives on the server that died, the backup software needs a license server that is also down. You find all of this in ten minutes of testing, or you find it during the worst week of your year.
The backup is reachable from the thing you are protecting against. If your backups live on a NAS on the same network, using the same credentials, ransomware will find them. Modern attacks go after backups first and on purpose, because a business with working backups does not pay. You want at least one copy that is offline or immutable, meaning it cannot be deleted or altered for a set period even by someone holding your administrator password.
Nobody has defined how long the business can actually be down. There are two numbers worth knowing. How much data can you afford to lose, measured in time, which is your recovery point objective. And how long can you be down before real damage starts, which is your recovery time objective. Most owners have never been asked. When they do the math, the answer is usually hours, while the current setup would realistically take days.
Only part of the environment is covered. File shares get backed up because they are obvious. What gets missed: the line-of-business application and its database, Microsoft 365 data (Microsoft replicates your data for availability, but retention after deletion is limited and that is your responsibility, not theirs), server configurations, firewall and switch configs, and the documentation describing how any of it fits together.
Nobody knows the order. Restoring servers is not a parallel operation. Domain controllers and DNS come up before anything that depends on authentication. Databases come up before the applications that read them. Without a written sequence, a recovery becomes a series of guesses made by a tired person under pressure.
A test you can run this week
You do not need a full disaster recovery exercise to learn something useful. Try this instead, and time it.
Pick one important file from a shared folder, something from about two weeks ago. Ask your IT provider or internal person to restore it to a separate location. Then note three things: how long it took to reach someone who knew how, how long the restore itself took, and whether the file opened correctly.
If that takes an afternoon, ask yourself what a full server restore would look like. The single-file test is the cheapest diagnostic in IT, and it is remarkably revealing.
What good actually looks like
You do not need an enterprise budget for this. For most small and mid-size businesses, a solid position looks like the following.
- Three copies of your data, on two different types of media, with one copy off site. This is the old 3-2-1 rule and it still holds up.
- At least one copy that is immutable or genuinely offline.
- Recovery point and recovery time objectives that somebody in leadership has actually agreed to, in writing.
- A restore test on a real schedule. Quarterly is reasonable. Once a year is better than never.
- A written recovery runbook with the order of operations, account credentials stored somewhere reachable when your systems are not, and the phone numbers you would need.
- Coverage that includes Microsoft 365, your line-of-business applications, and device and network configurations, not just file shares.
Notice how little of that is about buying something. Most of the gap in a typical small business is process, not product. The software is usually already in place and nobody has closed the loop around it.
Why this gets skipped
Backups are easy to buy and easy to forget. They run at night, they report success, and they produce no visible benefit on any normal day. Testing them costs time and produces nothing you can show a customer. So it sits at the bottom of the list, year after year, until an event moves it to the top in the worst possible way.
The businesses that survive a serious incident are almost never the ones with the most expensive tools. They are the ones who found out what worked before they needed it.
Want to know where you actually stand?
Reviewing backup and recovery posture is a core part of my IT assessment. I look at what is covered and what is not, whether the copies would survive a ransomware event, what a realistic recovery timeline looks like for your environment, and what it would take to close the gap. You get that in plain language, with priorities, not a vendor quote.
I do not sell backup software, hardware, or support contracts, and I take no commissions. If your current setup is fine, I will tell you it is fine.
Book a free 30-minute call and we will talk through what recovery would really look like for your business.