Your backup isn't a backup until you've restored from it

Almost every business I talk to says yes when I ask whether they have backups. Almost none of them can tell me the last time somebody restored something from one.

That gap is the whole problem. A backup is a promise, and the only way to know a promise is good is to make it pay out. Until you have pulled a real file back from a real backup and watched it open, what you actually own is a monthly invoice and a feeling.

Here is how to find out where you stand, in about half an hour.

The bit that catches Microsoft 365 users out

If your email and files live in Microsoft 365, it is easy to assume Microsoft is handling this. They are not, and they say so themselves.

Microsoft runs the service. They keep it available, replicated across their data centres, and protected from their own hardware failing. What they do not do is protect your data from you: someone deleting the wrong folder, a departing staff member taking a broom to their mailbox, or ransomware encrypting a synced drive.

The safety nets that exist are short and they are not backups:

• The recycle bin holds deleted SharePoint and OneDrive items for 93 days across both stages. After that it is gone.
• A deleted user account is recoverable for 30 days by default. Miss that window and the mailbox goes with it.
• Retention policies stop data being deleted. That is a different job from being able to wind the clock back to last Tuesday.

None of that helps if the damage was done four months ago and nobody noticed, which is exactly how accounting file corruption and quiet mailbox deletions usually surface.

Ransomware does not care that you have a backup

It cares whether it can reach it.

The pattern I see is a backup that lives on the same network, reachable with the same admin credentials as everything else. When something gets in and starts encrypting, it encrypts that too. A backup that shares its fate with the thing it is backing up is not a second copy, it is the same copy stored twice.

What you want is at least one copy that is somewhere else and cannot be altered or deleted by anyone logged into your environment, including an administrator. The industry shorthand is immutability. In plain terms: even with the keys to everything, you should not be able to destroy this copy.

The restore test

This is the part nobody does, and it is the only part that proves anything.

1. Pick something real. Not a test file you created this morning. A genuine document from six months ago, and one mailbox item from a real account.
2. Restore it to a point in time, not just "the latest copy". Being able to get yesterday back is not much use when the corruption started in March.
3. Open it. A restored file that will not open is a failed restore, and it happens more than you would think.
4. Time it. From "we need this back" to "it is open on screen". Write the number down.
5. Try a bigger one. A single file proves the mechanism works. A whole mailbox or a full folder tree tells you what a bad day actually looks like.

That last number is the one that matters, and it is the one almost nobody knows. If restoring your file server takes eleven hours, that is not a disaster, but it is a fact you want to learn on a quiet Tuesday rather than during an outage with staff sitting idle.

Three questions worth asking your IT provider

Ask these in writing. The answers tell you a lot, and so does how long they take to arrive.

• When did we last complete a successful restore test, and what was restored? A date and a description. "The backups report green every morning" is not an answer to this question - a green report means the job ran, not that the data inside it is usable.
• Where is the copy that cannot be deleted from inside our network? You are listening for a location and an explanation of why an attacker with admin rights could not reach it.
• How long would a full restore take, and what does the business do during that time? This is the number that decides whether you need a faster tier or just a realistic plan.

If your provider is any good they will be pleased you asked. If the answers are vague, that vagueness is the finding.

Where this shows up in the paperwork

Cyber insurance questionnaires now ask about backups directly, and increasingly they ask about tested restores rather than just backups existing. Answering optimistically on a renewal form is a bad idea, because that answer is the thing your insurer reads back to you at claim time.

The Australian Signals Directorate puts regular backups in the Essential Eight for the same reason. It is not there to tick a box. It is there because it is the control that gets you trading again after everything else has failed.

Start with one file

You do not need a project to do this. Pick one real document, ask for it to be restored, time it, and see what happens. Half an hour, and you will know whether the thing you have been paying for actually works.

If you would rather I ran it properly across your environment and gave you the answers in writing, that is what the readiness check below is for. Either way, test the restore. The worst time to discover a backup does not work is the day you need it.