Almost every firm I talk to says they have backups. Far fewer can tell me the last time someone actually restored from one. That gap is where the trouble lives.
A backup is a promise about the future: when something goes wrong, you will get your data back. The problem is that the promise is invisible until the day you need it, and that is the worst possible moment to discover it was empty. Backup jobs report green for months while quietly skipping a folder, excluding a mailbox, or writing to storage that fills up and silently stops. Nobody notices, because nobody looks. Then a laptop dies, or ransomware lands, and the restore either works or it does not.
The job ran. That is not the same as the data being there.
There is a real difference between a backup job completing and a restore succeeding. The job is the easy half. It runs on a schedule, it copies files, it sends a confirmation. The hard half is the part most firms never exercise: taking that copy and turning it back into a working file, a full mailbox, or a usable system, within a time frame that actually keeps the business moving.
I have seen backups that excluded the one shared drive everyone depended on, because it was added after the original job was configured and nobody updated the scope. I have seen retention set so short that by the time a problem surfaced, the clean version was already gone. None of these showed up as a failure. They showed up as a green checkmark, right up until the restore.
If you take one thing from this, make it this: an untested backup is a guess. You do not have a recovery plan, you have a hope.
What the 3-2-1 rule actually asks of you
The 3-2-1 rule is the plain-English standard worth holding your setup against. Three copies of your data. On two different types of media or storage. With at least one copy kept off-site.
The reason it holds up is that each part defends against a different failure. Multiple copies cover simple corruption or accidental deletion. Two types of storage mean a single hardware fault or a single vendor outage does not take everything at once. The off-site copy is what saves you from fire, theft, or a local disaster that reaches every machine in the building.
There is a modern addition worth making explicit. At least one copy should be immutable, meaning it cannot be altered or deleted once written, even by an administrator account. Ransomware now goes looking for backups specifically, because attackers know that a firm which can restore will not pay. An immutable copy is the one they cannot encrypt. If your backups live on a drive that a compromised admin login can reach and wipe, they are part of the blast radius, not protection from it.
Two numbers worth knowing before an incident
There are two questions that quietly decide how bad a bad day gets, and most firms have never put numbers to either. The first is how much data you can afford to lose, measured in time. If your backup runs nightly and something fails at 4pm, you have lost a full day of work, because the last good copy is from the night before. For some firms a day is fine. For an accounting practice mid-filing, a lost day in March is a genuine problem, and the answer might be that critical systems need to be captured every few hours rather than once a night.
The second is how long you can afford to be down while you recover. This is the one the restore test actually measures. There is a large practical difference between a setup that has you working again in two hours and one that takes two days, and the gap usually has nothing to do with whether the backup exists and everything to do with how it restores: where it lives, how fast that storage is, and whether anyone has ever walked the path before. A firm that knows both numbers can make a clear-eyed decision about what to spend. A firm that knows neither is just hoping the answer turns out to be acceptable, and hope is not a recovery objective.
The reason to set these on purpose is that they drive every other choice. They tell you how often to back up, how much to invest in fast recovery, and which systems deserve the most protection. Without them, you are buying backup blind and finding out the hard way whether you bought enough.
The cloud gap nobody mentions
Here is the assumption that catches the most firms off guard. Microsoft 365 and Google Workspace are not backups.
They are excellent at keeping the service running. They replicate your data across their own infrastructure so a hardware failure on their end never reaches you. What they do not reliably protect you from is your own people and your own mistakes. A deleted mailbox, a user who empties a folder, a ransomware process that encrypts files and syncs the encrypted versions up to the cloud, a departing employee who cleans out a shared drive on the way out. Built-in retention windows are short, often around 30 days, sometimes less, and once that window closes the data is gone for good.
If your accounting firm keeps client files in SharePoint, or your team runs on Gmail and Google Drive, that data needs a real backup that lives outside the platform, with retention you control. We get into the platform-specific side of this in our comparison of Microsoft 365 and Google Workspace. The short version is that both platforms expect you to handle backup yourself, and most firms do not realize that until they try to recover something that aged out.
How to actually test a restore
Testing a restore is less work than people expect, and it is the single highest-value hour you can spend on this. Pick a real file and recover it to confirm the basics. Then go further and recover a full user mailbox, because mailboxes are where the painful, time-consuming restores happen and where the surprises hide.
While you do it, time it. The number on the clock is your real recovery time, not the optimistic figure in a vendor brochure. If recovering one mailbox takes four hours, recovering a whole team after an incident is a multi-day event, and you want to know that now rather than during the event. Once you have run the test, put it on a recurring schedule. Quarterly is a reasonable cadence for most small firms. The point is to catch the silent scope change or the storage that filled up before it matters, not after.
Confirm three things in writing and keep them current: what is backed up, how often, and when a restore was last tested successfully. If anyone hesitates on any of the three, treat the backup as unproven until you have tested it yourself.
The way this goes wrong is rarely dramatic in the moment. A firm gets hit, the team stays calm because they have backups, and then the calm drains away over the next few hours as the restore reveals what was actually being captured. The shared drive that held active client files turns out to have been outside the backup scope since someone reorganized the folders a year ago. The mailboxes come back, but slowly, one at a time, and the math on thirty of them suddenly means days, not hours. The off-site copy exists, but nobody has the credentials to reach it quickly because the person who set it up has left. None of these are exotic failures. They are ordinary gaps that stayed invisible precisely because the backup kept reporting success, and the only thing that would have surfaced them was a test that never happened. A single dry run, done on a quiet Tuesday, turns every one of those discoveries from a crisis into a calendar item.
Where this sits in the bigger picture
Backup is one piece of resilience, and it tends to get more serious attention under a proactive support model than a reactive one, because someone is actually accountable for testing it rather than assuming it works. We walk through that difference in Managed IT vs Break/Fix. It also shows up on the renewal form now, since carriers ask whether your backups sit offline and when you last restored, a shift I cover in why cyber insurance renewals just got harder.
But you do not need to wait for any of that to close the most dangerous gap. Go find out, this week, whether your backups can actually be restored. If they can, you have bought yourself real peace of mind. If they cannot, you have just learned the most important thing about your IT before it cost you anything.