Ask a room of owners whether they have backups and every hand goes up. Ask who has restored a whole server in the last year, and most of those hands come down.
That gap matters, because what you need in a bad week is a restore, and the only proof a restore works is having done one. I'd want to see one done on purpose, before a crisis forces it.
What a backup success report can hide
Backup software reports on itself. The job ran and the checkmark is green, so everyone moves on. Here is a short list of what I've 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, quietly losing the ability to go back more than a week
- Databases copied while open, producing files that restore into something the application can't read
- File sync doing the job everyone believed backup was doing, so a deleted file was deleted everywhere, promptly and for good
None of these announced themselves. Every one turned up at the worst possible moment, which is the only moment an untested backup gets looked at.
File sync and RAID are not backup
In my experience, two beliefs cause most of the trouble. The first is that file sync services are backup. They're very good at what they do, which is making the same files available everywhere, and 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, often set up as RAID so two or more drives mirror each other, are backup. They protect against one thing, a dead drive. A deletion or a ransomware encryption is copied to every drive instantly.
Redundancy keeps you running through a hardware fault. It doesn't take you back in time, and going back in time is the whole point of backup.
The questions that matter
You don't need to be technical to audit your own position. Five questions do most of the work:
- What exactly is backed up, named specifically? Name the data on the server, such as the accounting database, and not only the server itself.
- Where do the copies live, and is at least one somewhere ransomware on your network can't reach?
- How far back can you go?
- When did someone last restore something, and was it a real test or a hope?
- If the building were off limits tomorrow, what is the sequence of steps, and who knows it?
If any answer is I'm not sure, that is normal. A business busy running itself rarely has these written down. I'd still fix it now, while it's a list of questions and before it's an emergency.
Continuity is the actual goal
Backup is a means. The goal is continuity, meaning how fast you're working again after something goes wrong. I've seen two companies hold identical backups and get very different outcomes, because one has thought through the order of restoration and where people will work on day one, while the other decides 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 are tested, and what the first day of a recovery really looks like.
We've also written up a ransomware recovery case study where the backups were the first thing the attacker encrypted. If you want the audit version of this conversation, schedule a call. The restore test alone is worth the meeting.