A backup you have never restored is a hypothesis

Every business we assess has backups. Almost none of them have evidence that those backups work. The gap between the two is where recovery plans go to die.

A backup console showing green ticks tells you that a job completed and wrote some data somewhere. It does not tell you that the data can be read, that it is internally consistent, that the application it belongs to will start, or that anyone knows how to bring it back. Until you have restored something, your backup is a hypothesis.

What a real restore test looks like

Not a file. Restoring a spreadsheet from OneDrive proves very little — that path is well trodden and rarely the thing that fails.

A real test restores the thing the business cannot operate without, in a way you could repeat under pressure:

• Pick the system that stops the business. The ERP database, the practice management system, the file server the whole team maps a drive to
• Restore it somewhere isolated. An isolated network or a sandbox, never over the live copy
• Start the application. Not just the data — the application, against the restored data
• Have someone who uses it look at it. Ask them to find last Tuesday's records. A technician cannot tell you whether the data is right; the person who works with it every day can
• Write down how long it took. Start to usable, including the parts where somebody had to find a password

That last number is the one that matters. It is your actual recovery time, as opposed to the one in the plan.

The three failure modes you only find this way

1. The backup is fine and the dependency is missing

The database restores perfectly. The application will not start because the licence server, the certificate, or a second database nobody documented is not in the backup set. Extremely common with line-of-business software that was installed years ago by somebody who has left.

2. The backup is fine and the restore path is not

The data is intact but bringing it back needs credentials stored in the system that is down, or a tool nobody has installed, or bandwidth you do not have. A 2 TB restore over a business internet connection is a very different event from a 2 TB restore from local storage.

3. The backup has been quietly failing for a subset of data

The job reports success because most of it succeeded. One database was locked, one folder had a permissions change, one virtual machine was added six months ago and never included in the selection. Nobody reads a green report closely.

How often

For most SMBs: a full restore test of the critical system twice a year, and a spot restore of something smaller each quarter. More if you are in a regulated sector or your customers ask for evidence.

Schedule it when the business can absorb it. For a fresh produce operation that means not during harvest; for an accounting practice it means not October. Booking it around the calendar is most of what makes it happen rather than getting postponed indefinitely.

Microsoft 365 is not backed up by default

Worth a paragraph of its own, because it catches people constantly. Microsoft operates the service and protects it against their own failures. What they do not do is protect you against deletion, ransomware encryption of synced files, a departing staff member clearing a mailbox, or a retention policy someone configured optimistically.

Retention is not backup. If your Exchange Online, SharePoint, OneDrive and Teams data matters, it needs third-party backup with its own retention and its own restore path.

Offline, or immutable

Modern ransomware looks for backups first, and it looks with the credentials it just harvested. A backup server that is domain-joined and reachable from a compromised workstation is part of the same blast radius.

Immutable storage cannot be altered or deleted for a defined retention window — not by an attacker, and not by an administrator either, which is the point. Where immutability is not available, offline still works: media that is physically disconnected between runs.

This is also the specific thing your insurer is asking about on the renewal form. See what your insurer is really asking.

The record you want

One page, kept current: what was restored, on what date, how long it took, who verified the data was correct, and what broke. Two years of those pages is the most persuasive document you can put in front of an auditor, an insurer, or a customer running a supplier review.

It is also, quietly, the document that lets you sleep during an actual incident — because you already know it works.