Is Your Backup Actually Working? A 20-Minute Test

Almost every business I audit has backups. A green checkmark somewhere, a service that emails a success notice, a drive that fills up.

Far fewer have backups that restore. The gap between those two things is where businesses die, and you only find out which side you're on during the worst week of your professional life.

Here's how to find out today instead.

Why Backups Fail Silently

A backup job reporting success only means the job ran. It doesn't mean:

• The files it copied are complete or usable
• The thing you actually care about was included in the job
• The database was in a consistent state when it was copied
• Anyone can decrypt it
• The destination still has space
• The credentials it uses haven't expired

Failures here are quiet by nature. Nothing crashes, no alarm goes off, and the report says "completed." The system works perfectly right up until the moment you need it, which is the only moment that counts.

The Only Question That Matters

Not "do you have backups." When did you last restore one?

If the answer is "never" or "I don't remember," you don't have a backup system. You have a backup hope.

The 20-Minute Test

Do this on a normal Tuesday when nothing is on fire.

Step 1 — Pick something real (2 min). Not a test file you created for this. Choose an actual business file from at least a week ago: a customer database, last month's invoices, the folder your team works out of daily.

Step 2 — Find it in the backup (5 min). Open your backup system and locate that specific item. Start the clock here, because this is the part that surprises people. If you can't find it in five minutes, that's your first finding — during a real incident you'll be doing this at 2 a.m. with everyone waiting.

Step 3 — Restore it somewhere safe (10 min). Restore to a different folder, a test machine, anywhere that isn't on top of your live data. Never restore over production during a test.

Step 4 — Actually open it (3 min). This is the step everyone skips. Open the file. Query the database. Look at the invoice. A restored file that won't open is not a restored file.

Step 5 — Write down the date. Put it in a calendar, a note, anywhere. Then set a reminder to do this again in three months.

What Usually Goes Wrong

In my experience, roughly a third of first tests fail. The common findings:

• The backup didn't include what you assumed. Someone set it up years ago to cover one folder, and the business has since spread across four.
• It's backing up to the same server. If the machine dies, so does the backup. This is the single most common mistake, and it means you have no backup at all — just a second copy in the same building.
• The database is corrupt. Databases copied while running, without being properly quiesced or dumped, often restore to something unusable.
• Nobody has the credentials. The account belongs to an employee who left, or the encryption key lives on a laptop that was replaced.
• It stopped running months ago. The disk filled up in March, the job has been failing since, and the notification email goes to an address nobody reads.
• The restore takes days. Technically fine, practically useless. If restoring your system takes four days, your business is down for four days.

The 3-2-1 Rule

The standard worth aiming at, and it's simpler than it sounds:

• 3 copies of your data
• 2 different types of storage (local drive and cloud, for example)
• 1 copy somewhere else entirely — a different building, a different region

That last one is what turns a backup into a disaster recovery plan. A fire, a flood, a break-in, or a hurricane takes the whole location, not one machine. I've written about building the wider plan in Why Every Business Needs a Disaster Recovery Plan.

If Your Test Fails

Don't panic and don't overhaul everything. In order:

1. Fix the destination first. If backups live on the same machine as the data, change that today. Everything else is secondary.
2. Confirm what's actually covered. List what would end your business if it vanished, then verify each item appears in the backup.
3. Set up failure alerts. You want an email when a job fails, going to an address someone reads. Success notifications train people to ignore the whole channel.
4. Test the restore quarterly. Put it on the calendar like any other obligation.

The Part Worth Saying Plainly

An hour of testing costs you an hour. Discovering your backups were broken after a ransomware infection, a failed drive, or a storm costs some businesses everything — and the numbers on that are grim: a meaningful share of small businesses that suffer major data loss don't reopen.

You don't need enterprise software to be safe here. You need a backup that lives somewhere else, an alert when it breaks, and proof — recent, dated proof — that it restores.

Want someone to run the test with you? Get in touch — I'll check what you have, tell you honestly whether it would hold, and fix it if it wouldn't.