The Backup You Have Never Restored

Every business we audit has backups. The console shows a column of green ticks going back months. Then we ask a simple question: when did anyone last restore something from them, end to end, and time how long it took? The room usually goes quiet.

A green tick means a job ran. It does not mean the data is complete, that it can be read back, that the right things were selected, or that the business can be running again before customers notice. The only proof that a backup works is a restore.

The ways a "successful" backup fails

None of these show up as a red cross in the console:

• It is backing up the wrong thing. The file server is covered, but the accounting package moved to a new database folder during an upgrade two years ago, and nobody updated the selection.
• The database copy is unusable. Copying the files of a running database often produces something that will not open. Databases need their own backup method, and it has to be tested separately.
• It sits in the same place as the original. A USB drive plugged into the server is a backup against a failed disk. It is not a backup against theft, fire, a burst geyser, or ransomware, all of which take both.
• Nobody knows the password. Encrypted backups are good practice. Encrypted backups whose key lived in the head of a technician who left are a locked safe with no combination.
• It takes four days to come back. The data is all there, but restoring two terabytes over an office line runs to days. The backup "worked"; the business still stopped.

Ransomware goes for the backups first

This is the change of the last few years that most small-business backup setups have not caught up with. Modern ransomware is not a virus that encrypts whatever it lands on. It is usually a person, operating inside your network for days or weeks, and one of the first things they look for is your backups. They delete them, encrypt them, or wait until the retention period has cycled past the last clean copy. Only then do they encrypt production, because a victim with good backups does not pay.

So any backup that the ordinary network can reach, and that an administrator account can delete, should be assumed to go down with everything else. That is the reason for the one rule that matters most today.

If the account that manages your servers can also delete your backups, then whoever steals that account can too.

3-2-1, updated

The classic rule still holds: three copies of your data, on two different types of storage, with one off-site. Current practice adds two numbers to the end, and they are the ones that matter against ransomware:

• One copy immutable or offline. Immutable means that once written, it cannot be changed or deleted until its retention period expires, not even by an administrator. Most reputable cloud backup services and many backup appliances offer this; it is often a setting that has to be switched on. The old-fashioned version, a rotated disk kept disconnected in a different building, achieves the same thing if someone actually rotates it.
• Zero errors on a tested restore. Which brings us back to the only test that counts.

Keep the backup system's logins separate from your everyday administrator accounts, protect them with multi-factor authentication, and store them in a password manager that more than one trusted person can open.

Your cloud apps are not backed up the way you think

Microsoft 365 and Google Workspace are extremely reliable services. Reliability is not the same as backup. The provider protects you against their hardware failing; they do not protect you against your own people or your own attackers. A mailbox deleted by a departing employee, a SharePoint library wiped by a synced ransomware infection, or a folder removed nine months ago and needed now for a dispute, can all fall outside what the built-in recycle bins and retention hold by default.

A third-party backup of Microsoft 365 or Workspace is inexpensive per user and closes that gap. The same logic applies to the other cloud systems you rely on: find out what your accounting, CRM and ERP providers actually keep, for how long, and whether you can get a copy of your own data out on demand.

Running a restore test

This takes an afternoon and does not need to touch the live system.

1. Pick one critical system. Usually the accounting or ERP database, because that is what stops the business.
2. Restore it somewhere else. A spare machine, a test virtual server, or a cloud instance. Never over the top of production.
3. Start the clock. Time from "we need it back" to "a user can log in and see last night's data". This is your real recovery time, and it is usually longer than anyone guessed.
4. Check the data, not the files. Open the package, run the aged debtors report, compare the totals to the live system. A restore that produces files but not a working system has failed.
5. Write down what went wrong. The missing password, the licence that would not activate on new hardware, the step nobody documented. Every one of those would have happened during a real incident, under pressure.

Then make it routine: a handful of individual files each month, and a full test of each critical system once a year. The result belongs in your disaster recovery plan, alongside who to call and in what order.

Ask three questions this week

Put these to whoever looks after your IT, and ask for evidence rather than reassurance:

• When was the last full restore test, which system was it, and how long did it take?
• Which backup copy could an attacker with our administrator password not delete?
• Who, other than you, can get into the backups if you are not available?

If all three have clear answers, you are in better shape than most. If any of them produce a pause, that pause is the most useful thing you will learn about your IT this year, and it is far cheaper to learn it now than on the morning the server does not start.