Outage on a Tuesday: ransomware on the VPS, or simple DROP TABLE after a risky migration. The team reassures the client: "we have backups". Four hours later you discover snapshots do not restore the database to yesterday, upload files live on an unincluded disk, and nobody ever tested a full restore.
A useful backup does not start with a plugin or cron. It starts with one sentence: in disaster X, we must recover state Y in Z minutes, losing at most N minutes of data.
Define scope before tool
List what must come back:
| Component | Example | Common omission |
|---|---|---|
| Database | MySQL, PostgreSQL | Transactions between dumps |
| App files | Uploads, media | Separate object storage |
| Configuration | .env, nginx, TLS | Secrets outside git |
| DNS / certificates | DNS zone, ACME keys | Registrar not "backed up" |
| Code | Git remote | Unpushed branches |
Then set RPO and RTO per critical component. Brochure blog: 24 h RPO acceptable. Shop: 15 min RPO, RTO < 2 h.
Backup without RPO/RTO is archiving in fog.
3-2-1 adapted for web
3 copies — production + local backup or snapshot + remote copy.
2 media — disk + cold object or other region.
1 off-site — other datacenter, other cloud account, offline tape if sensitive.
On shared hosting, off-site copy is often the only real value of your custom script — host snapshots stay correlated to their infra.
Included backups vs custom scripts
| Source | Advantage | Limit |
|---|---|---|
| Host VPS snapshot | Fast, integrated | Same region, short retention |
| Shared "included" backup | Simple | Vague scope, slow restore |
| mysqldump + rsync cron | Full control | Operations to maintain, encryption to manage |
| Restic/Borg tool | Dedup, encrypted | Learning curve |
Read SLA exclusions: some hosts backup system disk but not attached volumes. Cross-check our included backups enquiry when comparing offers.
Errors that kill restore
Backup without integrity check. Truncated MySQL dump stays silent until crisis.
Single retention. Deleting dailies after 7 days without monthly = no return before late-detected breach.
Secrets in unencrypted backup. .env in public S3 archive = double incident.
Forgetting restore order. DNS before TLS, database before workers, object before signed URLs.
The peak: newest backup is not the right one
Peak that "daily backup included" quotes avoid: freshness is not cleanliness. Plan immutable restore points and test an older recovery.
Decide and move forward without blind spots
Write two to three scenarios (DB deletion, ransomware, bad deploy). Set RPO and RTO per scenario. Automate exports and encrypted off-site copy. Schedule quarterly restore test. Compare hosts on real backup via directory and compare tool.
Frequently asked questions
Difference between RPO and RTO?
RPO sets how much data you accept losing — e.g. one hour of orders max. RTO sets how fast service must resume — e.g. four hours. Both numbers guide backup frequency and restore procedure.
Are host snapshots enough?
Often for quick rollback on same infrastructure, insufficient alone: same datacenter, no protection against malicious deletion. Add off-site and immutable copies.
Should you backup logs?
Only if legally required or forensics. Otherwise they inflate bill without helping bring site back online.
Shared hosting: what can you actually backup?
Often DB via export and files via FTP/rsync if allowed. Check exclusions and "backup included" detail.
The right question is not "do we backup?" but "which hour yesterday can we cleanly revive, and how fast?"