Ask a room of business owners whether they have backups and every hand goes up. Ask who has restored a file from those backups in the last quarter and most hands come down. Ask who has restored an entire server, and you can usually count the remaining hands on one finger.
That gap matters because a backup is not the thing you need. The thing you need is a restore, and the only evidence a restore works is having done one.
A green checkmark is not a recovery plan
Backup software reports on itself. The job ran, the checkmark is green, everyone moves on. Here is a partial list of things we have found behind green checkmarks over the years:
- Backups of a folder that was moved two years ago, faithfully protecting nothing
- Backups running nightly to a drive that filled up months earlier, silently overwriting the ability to go back further than a week
- Databases copied while open, producing files that restore into something the application cannot read
- Cloud file sync doing the job everyone believed backup was doing, meaning a deleted file was deleted everywhere, promptly and efficiently
None of these announced themselves. Every one of them was discovered at the worst possible moment, which is the only moment an untested backup gets examined.
Sync is not backup, and neither is RAID
Two beliefs cause most of the trouble.
The first is that file sync services are backup. They are excellent at what they do, which is making the same files available everywhere. That includes making a ransomware-encrypted file available everywhere. Versioning helps, and it has limits worth knowing before you need them.
The second is that redundant drives in a server are backup. They protect against one specific failure, a dead drive. They replicate every deletion, every corruption, and every encryption instantly and perfectly. Redundancy keeps you running through a hardware fault. It does not take you back in time, and going back in time is the entire point of backup.
The questions that matter
You do not need to be technical to audit your own position. Five questions do most of the work:
- What exactly is backed up, named specifically? Not the server, but which data on it.
- Where do the copies live, and is at least one somewhere ransomware on your network cannot reach?
- How far back can you go?
- When did somebody last restore something, and was it a real test or a hope?
- If the building were inaccessible tomorrow, what is the sequence of steps, and who knows it?
If any answer is I am not sure, that is not a criticism. It is the normal state of a business that has been busy running itself. But it is worth fixing while it is a list of questions rather than an emergency.
Continuity is the actual goal
Backup is a means. The end is continuity: how quickly your business is working again after something goes wrong. Two companies can have identical backups and very different outcomes, because one has thought through the order of restoration, where people will work, and which systems matter most on day one, and the other is deciding all of that during the incident.
That thinking costs a few hours in a calm week. Our backup and business continuity services exist to do it properly: what gets protected, where copies live, how often restores get tested, and what the first day of a recovery actually looks like.
We have also written honestly about what recovery looks like when the plan was inherited rather than designed. If you want the audit version of this conversation, schedule a call. The restore test alone is worth the meeting.