Backups are easy. Restoring from them is the hard part.

I’ve seen the same thing at enough client offices to stop being surprised: a folder full of backup files. Dozens of them. Stacked neatly. The sizes are impressive. Terabytes of data, collected over years, sitting in a folder that hasn’t been opened since the person who set it up left.

They had backups, right? In a manner of speaking.

Let me ask you a question. When was the last time you actually restored from one?

Not “looked at the backup software to check it said successful”. Not “saw the green tick in the dashboard”. I mean actually opened a file from the backup, verified it was readable, and put it somewhere you could use it.

If you’ve never done that, you don’t have backups. You have false confidence with a nice interface.

The problem with “it worked”

Backup software is designed to tell you when something goes wrong. That’s its job. It logs errors brightly. It flashes red. It emails you. Everything about it is optimised to show you failure.

Its job isn’t to verify that the data is actually usable.

So when you see “backup succeeded” - even when it has - you’re seeing one very narrow thing. The software managed to copy something from somewhere to somewhere else. Most will do some kind of verification that the copy was successful. It doesn’t mean they’re the right files. It doesn’t mean you know where they are when you need them.

It means the software didn’t crash while copying.

There’s a difference. A large one.

Why restoring is hard

Restoring from a backup is a completely different problem to making one.

Making a backup is automatic, at least it should be after initial setup. Set it and forget it. Walk away. A green light appears.

Restoring is manual, time-pressured, and full of unknowns. You discover problems that nobody notices in the making phase:

• The backup format is one that no software on your current machine can open
• The files are stored somewhere you don’t know about because the person who set it up isn’t there anymore (or is on holliday)
• The restore process took four hours and required a degree in sysadmin
• You finally got the files back, but they were six months out of date
• They are password protected - and you don’t have the password.

And none of these show up in the backup log.

The backup was never the solution. It was the paperwork for the solution.

Part one: making backups

This is the easy part. You set up something that copies your important data to a separate location. It runs automatically. You get a green light.

There are principles. The 3-2-1 rule is simple enough to write on a post-it:

• 3 copies of your data (the original plus two backups)
• 2 different kinds of storage (a local drive and something else)
• 1 offsite copy (somewhere that isn’t in the same building)

Part two: verifying they work

This is the part people seem to forget.

A backup is only a backup if you can restore from it. Everything else is theatre.

The test is simple. Once a quarter, pick something. Anything. A file. A folder. Restore it. Open it. Check it.

It takes ten minutes.

If that sounds like a lot, consider the alternative: something goes wrong, your files disappear, and when you reach for the backup, you discover - too late - that you’ve never actually verified it works.

What a real backup routine looks like

I don’t want this to sound harder than it is. A real, working backup routine for a small organisation is almost embarrassingly simple.

1. A local backup drive or network server A USB harddrive you plug in once a day. It copies whatever you have changed that day. You unplug it and put it in a drawer. That’s your first backup.

   • If you have network attached storage, use that instead.

2. A cloud backup. A service that copies your important files to the internet. Doesn’t need to be clever. It just needs to run while you’re working and do its job silently. That’s another copy of a different kind in an offsite location.

3. A quarterly restore test. Ten minutes, once every three months. You pick two random files. You restore one from your local backup. You restore one from your cloud backup. You open them. If they work, you’re done. If it doesn’t, you’ve just discovered a problem before it was an emergency.

That’s it. Three things. Nothing more.

The first two take might take some setup if you’ve got no backups currently. The third takes ten minutes a quarter.

There’s no dashboard. No real-time maps. No “enterprise-grade threat detection”. Just a drive, a service, and a quarterly check.

Why this gets ignored

I think it’s because the backup part is so easy. The software does everything. You push a button. The cloud does the rest. It’s almost too simple to feel like it counts.

Verifying the backup requires effort. You have to think about it. You have to open the restored file and actually look at it. There’s no green tick to comfort you. There’s just a file, waiting to tell you whether it works or not.

It’s the kind of thing that gets pushed aside because there are flashier things to worry about.

The takeaway

You can have all the backup software in the world and still have nothing if you’ve never practised restoring from it.

Check yours. Now. Before the next disaster strikes and you discover it was all paperwork. If you need some help: