Stacked backup disks with a checkmark, illustrating tested backups

The Backup You’ve Never Tested Is Not a Backup

By Resolute Security

Field notes from a senior-led security practice

A client called me on a Tuesday, calm at first, because he was sure he was fine. Ransomware had hit overnight and locked every file on the network. “We have backups,” he said, the way you’d say “we have insurance.” I asked him when the last restore test was. There was a long pause. The honest answer, which took another few minutes to surface, was never. They had been backing up faithfully for three years and had never once pulled the data back to see if it worked.

It did not work. Two of the backup sets were corrupt. A third was missing the database they needed most, because the backup job had been quietly failing on that one folder for fourteen months and nobody read the email reports. They got most of the business back eventually. It took eleven days and a number with a lot of zeros.

Here is the thing I wish every small business owner believed before the bad Tuesday: a backup you have never restored from is not a backup. It is a hope. Hopes are lovely. They are not a recovery plan.

Why untested backups fail so often

Backups rot quietly. A job that worked perfectly in 2023 starts skipping a folder after someone moves a file share. A retention setting silently overwrites the copy you actually needed. The cloud sync looks green in the dashboard but has not touched the accounting server since a credential expired. None of this announces itself. It waits.

There is also a gap most people never think about. Backing up your data is not the same as backing up your systems. I have watched businesses recover every file and still sit dark for a week, because nobody had documented how the server was configured, which software licenses were needed, or what order things had to come back online. The data was safe. The ability to use it was gone.

The test that takes an afternoon

You do not need a disaster recovery program with a binder and a consultant. You need to actually do the thing, once a quarter, on purpose. Pick your most important system. Have someone who did not build the backup try to restore it to a spare machine or a fresh cloud instance. Time the whole thing. Write down what broke.

The first time a business runs this test, the restore almost always takes three to ten times longer than anyone guessed. That is not a failure. That is the point. You are buying the surprise now, on a quiet afternoon, instead of during the worst week of your year.

A few rules that earn their keep

  • Keep at least one backup copy offline or otherwise out of reach of your network. Ransomware that can see your backups will encrypt them too.
  • Write down your recovery target for each critical system. “Email back in four hours, accounting in a day” is a real plan. “As fast as possible” is not.
  • Read the backup reports, or have software that nags a human when a job fails. Silent failure is the whole problem.
  • Back up the configuration, not just the files. Note how things are set up and in what order they need to return.

The businesses that walk away from ransomware without paying are almost never the ones with the fanciest tools. They are the ones who tested. When the attacker demands money, they get to say no, because they already know the restore works. They watched it work last month.

If you take one thing from this, let it be the afternoon. Block it off. Restore something. Find out what you actually have before someone else finds out for you.

Further reading