Why backups fail in smaller companies
Ask an owner whether they have backups and the answer is yes. Ask when a restore was last tested and the answer changes shape.
The three failures we find most often
The copy is on the same machine as the data. A second disk in the same server protects against disk failure and nothing else — not fire, not theft, not ransomware, which encrypts every drive it can reach.
Nobody reads the reports. The job has been failing since March. The email goes to an address nobody monitors, or to a person who left.
The restore has never been attempted. The backup runs, the file exists, and no one has ever confirmed it contains what it should, or how long it would take to bring back.
The rule that still holds
Three copies of the data, on two different types of media, with one held off-site. It predates the cloud and survives it. In practice, for a small company:
- The live data on the server
- A local backup for fast restores
- An off-site or cloud copy for the bad day
Add the fourth condition
Modern ransomware looks for backups specifically, and it usually finds them, because the backup account has access to everything by design. So one copy must be immutable — written once and impossible to delete or alter for a fixed retention period, even with valid administrator credentials.
If your backup can be deleted by whoever compromises your domain administrator account, it is not a backup. It is a second target.
What to check this week
- Open the backup console and read the last thirty days of job results
- Confirm the alert address belongs to somebody still employed
- Pick one important file and restore it to a temporary location
- Write down how long that took
That last number is the one your directors will ask for during an incident.
Our server and backup work starts with exactly these checks.