What this protects
Your records, and your ability to keep trading
A backup is the cheapest insurance a business can buy, and the one most often left untested until the day it is needed.
The investment already in your data
Years of client records, quotes, accounts and correspondence. Nobody can retype a decade of work over a weekend.
Trading continuity
Every hour the systems are down is revenue that does not come back, and staff who cannot do their jobs.
Proof it restores
We run test restores on a schedule and give you the result. Most businesses have never once tried theirs.
A backup is only a backup once it has been restored
Every disaster recovery conversation we have starts the same way. The business tells us they have backups, we ask when they last restored anything from one, and the room goes quiet. It is not that they have been careless with the backup; it is that nobody ever asked the question.
A backup you have never tested is a belief rather than a piece of infrastructure. The five signs below are the failures we find most often when we take over a backup setup that has been quietly working, or so everyone assumed.
The five signs
Nobody has ever restored it
The job runs, the green tick appears, and no one has ever tried to put the data back. Running and restorable are two different things.
It stopped reporting months ago
The most common failure we find. A job that died in March looks identical to a job that is working, right up until you need it.
It lives beside the thing it protects
A copy in the same room, rack or building as the server shares its fate. Fire, flood, theft and ransomware do not respect that boundary.
Your Microsoft 365 data is not covered
Mailboxes, SharePoint and Teams are not backed up by Microsoft in the way most people assume. Deleting a mailbox is your recovery problem, not theirs.
The restore would take too long
A restore that takes eleven hours is no help to a business that can only afford to be down for two. Speed matters as much as the data itself.
What a setup that actually works looks like
A dependable backup does not need to be complicated or expensive. It needs copies held somewhere other than your building, a monitoring system that shouts when a job stops, and a documented restore you have run at least once.
The honest part: getting this right costs money, and for a business with a single server it is a modest sum rather than a project. What it saves you is the morning where your staff are standing around because the accounts system did not come back.
Test yours this week
- Restore a single file and check it actually opens
- Log into the backup console and confirm the last job succeeded today, not in the spring
- Check where the encryption key is kept and confirm it is not on the server being backed up
- Ask your provider how long a full restore of your main server would take
- Confirm Microsoft 365 mailboxes and SharePoint are covered alongside your local files
Questions to ask your current provider
- When did we last successfully restore something, and what was the result?
- What happens when a backup job fails, who notices, and how quickly?
- Are our copies held somewhere other than the building they protect?
- Does the backup cover the server configuration, or only the files on it?
- If our main server died at 3am, what would the next twelve hours look like?
The twelve hours after it goes wrong
The real test of a backup is the twelve hours that follow a failure. In a business that has tested, that time is spent restoring. In one that has not, it is spent discovering what is missing, guessing what to do, and ringing people who are not answering.
If you remember one thing from this article, make it this: test a restore, not a backup. The two are not the same, and only one of them tells you the truth.
What to do about it
- Test a restore, not the backup. Running and restorable are different things.
- Make sure at least one copy is held away from the building it protects.
- Check the date on your last successful job rather than trusting the green tick in the console.
- Confirm Microsoft 365 mailboxes and SharePoint are covered separately from your local files.
Questions we get asked about this
How often should a business test restoring from backup?
At least twice a year, and again after any change to the systems being protected. A restore you ran a year ago does not prove the backup is working today.
Our provider says the backups are monitored. Is that enough?
Monitored is a good start, but ask exactly what it means: whether a failed job raises an alert to a person, or just turns a tile red on a dashboard nobody logs into.
Does Microsoft back up our Microsoft 365 data for us?
No. Microsoft keeps the service running, but recovering a deleted mailbox or a ransomware-encrypted SharePoint site is your responsibility. That needs a dedicated backup product.