The Night the Green Checkmark Lied
I got the call on a Monday morning, which is when all good disasters schedule themselves. A server had gone sideways over the weekend, and the owner was calm in that way people get when they are trying not to panic in front of their staff. "We have backups," he said. "It runs every night." And he was right, in a sense. The backup software opened, it ran, and it reported success with a cheerful green checkmark.
What it had been successfully backing up, night after night, was an empty shell. The real data had moved during a cleanup months earlier, and nobody updated the job. The folder sizes looked plausible because old files were still sitting there, aging quietly. Nobody noticed because nobody ever asked the backup to do the one thing it exists to do.
I have told this story at kitchen tables and in warehouses since then, and every time, somebody in the room goes quiet. Not because they are careless. Because they recognize that green checkmark. We all trust the dashboard a little too much when business is busy and nothing has broken yet.
A Backup Is a Promise You Have to Keep
Here is the plain way I explain it to owners now. A backup is not a product you bought. It is a promise you made to your future self on a bad day. And like any promise, it only counts if it holds up when somebody actually leans on it.
In my experience, the failures are rarely dramatic. Nobody deletes everything on purpose. What I see instead is slow drift. A drive fills up and the job starts skipping files. A password changes and the backup service quietly loses access. Somebody moves a folder to make room and the job keeps protecting the old location with great dedication. The system does not send you a dramatic warning. It just keeps smiling.
That is why I tell clients to stop asking, "Do we have backups?" and start asking a better question: "When did we last prove we can get our business back from one?" Those are completely different questions. The first one gets you a nod. The second one gets you the truth, and the truth is the only version that helps you on restore day.
Test It Like a Fire Drill, Not a Favor
We do fire drills for buildings nobody expects to burn down, but we cross our fingers on the systems the whole business runs on. That never made sense to me, so I run backup tests the same way: scheduled, boring, and non-negotiable.
Once a quarter, pick a real file, a real folder, or a real slice of your system and restore it somewhere safe where it cannot hurt production. Time it. Write down who did it, how long it took, and what confused them along the way. If the only person who knows the restore steps is you, that is a finding, not a footnote. Write the steps down in plain language your most stressed employee could follow at midnight.
In my experience, the first test is almost always humbling, and that is exactly the point. You want to discover the missing password, the expired access, and the mystery folder in October, on a calm Tuesday, with coffee in your hand. You do not want to discover them during a real outage with customers waiting and payroll on the line.
The Cheap Habits That Save Expensive Days
After the scary stories, people expect me to sell them something complicated. I do not. The habits that save businesses are cheap and almost embarrassingly simple, and they work for a five-person shop in Pottsville the same way they work anywhere else.
Keep more than one copy, and keep at least one of them somewhere other than the building, because a backup sitting next to the server shares the server's bad luck. Check the reports weekly, not when you remember, and actually open the latest file to confirm it has real content and a recent date. Test restores quarterly. Review who has access, because former employees should not hold the keys to your recovery. And when you change systems, move data, or hire someone new to run the computers, put "update the backups" on that checklist in ink.
None of this requires a big budget. It requires a calendar reminder and somebody who owns the job by name. Unowned backups are just wishes with software installed.
Frequently Asked Questions
How often should a small business test a restore?
In my experience, once a quarter is the right rhythm for most small businesses. It is frequent enough to catch drift, password changes, and full drives before they become emergencies, but not so frequent that the team starts cutting corners. Pick a date, put it on the shared calendar, restore something real into a safe location, time it, and write down what you learned while it is still fresh.
What should we back up besides our main system?
Back up the things your business actually runs on day to day: accounting data, customer records, shared documents, email-related files where they apply, and the configuration notes and passwords list your team would need to rebuild. Ask a simple question: if this laptop or server vanished tonight, what would we beg to have back tomorrow morning? Start with that list and expand it honestly.
Is one backup copy enough if it runs every night?
No, because frequency is not the same as safety. A single copy can be corrupted, deleted, encrypted, or stored in the same room as the problem that took out the original. In my experience, businesses sleep better with more than one copy and at least one kept off site or in a separate location, so one bad day cannot take out both the business and its safety net.
What is the first step if we have never tested our backup?
Start small and do it this week. Choose one important but low-risk file or folder, ask your backup to restore it to a separate test location, and see what actually comes back. Open the restored copy and confirm it is current and usable. That single honest test tells you more than a year of green checkmarks, and it gives you a calm starting point for fixing whatever you find.
