Quick answer: The classics: backups on the same server they protect, jobs that silently died months ago, dumps never test-restored, retention that keeps one overwritten copy, credentials that let a hacked machine erase its own history, and databases copied live instead of dumped. Every one is cheap to fix today and expensive to discover during an outage.
Overview
Almost no one loses data for lack of a backup tool — they lose it to a quiet assumption that "it's handled". This checklist collects the failure patterns we actually see in support tickets, each with its one-line cure.
The mistakes
- Same-server backups. Disk dies, dumps die with it. Fix: copy offsite — a Storage VPS in another location (see local vs remote).
- Silently dead cron jobs. Disabled during maintenance, never re-enabled. Fix: log every run and alert on a missing success line, not just on errors (automation guide).
- Never restored, ever. The archive is truncated, the dump is from the wrong DB. Fix: quarterly restore drills (testing guide).
- One overwritten mirror. Corruption noticed Friday was faithfully synced Monday. Fix: real retention — dailies, weeklies, monthlies.
- Live database file copies. Restores that half-work are worse than none. Fix:
mysqldump/pg_dumpfirst, then sync the dump. - Almighty credentials. Production's key can delete every old backup. Fix: dedicated users, restricted commands, append-only repos (access guide).
- Unencrypted copies of sensitive data scattered across boxes. Fix: client-side encryption with escrowed keys (encryption guide).
- Backing up everything except what matters.
/var/wwwcovered, crontabs,/etcand SSL keys forgotten. Fix: restore-drill on a blank server reveals every gap. - No owner. "Someone" watches the backups — meaning nobody. Fix: name a person, put a monthly check in the calendar.
When to contact support
Unsure whether your setup dodges these? Summarise it in a ticket (what, where to, how often, how tested) and the team will point at the weak spots — before an outage does.
Frequently asked questions
What is the single most common backup mistake?
Keeping the only backup on the server it protects. The failure that makes you need the backup — dead disk, full disk, compromise — usually destroys that copy at the same time.
How do backup jobs die without anyone noticing?
They get disabled during maintenance, break after an upgrade, or fill the disk — and nothing alerts. Logging every run and alerting on a missing success line closes that gap.
Why is an untested backup considered unreliable?
Because most silent failures — truncated archives, wrong database, missing directories — look exactly like healthy files until a restore attempt exposes them. Drills find this early.
Related articles
- How to test backup integrity
- Backup retention policy explained
- How to secure backup access
- How to create a disaster recovery plan
Need reliable space for your backups? Order a Storage VPS at Cloud2Y →
