Why Backups Fail Exactly When You Need Them (and the Checklist That Prevents It)

Failure 1: the job that\'s been failing since March

Backup software fails quietly: a changed password, a full disk, an expired certificate — and the nightly job errors out while everyone assumes it\'s running. Months later, the most recent restorable copy predates the data you need.

The fix: alerting on failure and on absence of success — the difference matters, because a crashed backup service sends no failure alerts. Someone must be accountable for reading them. In our managed backup service, verification is a daily monitored task, not a setting.

Failure 2: sync is not backup

OneDrive, Dropbox, and Google Drive replicate changes — including bad ones. Ransomware encrypts your files, sync dutifully uploads the encrypted versions, and your "backup" now contains exactly what the attacker left you. Version history helps but has limits and retention windows, and mass-restoring thousands of files through it is a project of its own.

Sync is availability. Backup is point-in-time copies, kept separate, immune to what happens to the original. A business needs both, and needs to know which is which.

Failure 3: the ransomware got the backups too

Attackers hunt backups before triggering encryption — the connected USB drive, the NAS on the same network with the same admin password, the cloud backup reachable with the same compromised credentials. All of it dies with the primaries.

The fix is the 3-2-1 rule with modern teeth: three copies, two different media, one offsite — and the offsite copy immutable, meaning it cannot be altered or deleted even by an administrator account during its retention window. Immutability is the single feature that decides whether ransomware recovery takes days or ends the business.

Failures 4 and 5: wrong scope, untested restores

\n
• The backup ran perfectly — on the wrong data. The accounting database moved, the new server never got added to the job, the local folder everyone saves to was never in scope. An annual scope review against a data inventory catches this.
\n
• The restore was never tested. Backups that verify perfectly can still fail to restore: corrupt archives, missing dependencies, restore times measured in days when the business assumed hours.
\n

The fix: scheduled restore tests — actually restoring real systems to isolated hardware and confirming they boot and open. Quarterly for critical systems. It\'s the only proof that counts, and it also tells you your true recovery time before you\'re quoting it to a room full of stopped staff.