There's a conversation I've had far too often: "Bruno, the site is gone/got hacked — help me restore from backup". Then comes the question that decides everything: "which backup?". When the answer is "the host's automatic one", the story usually ends badly. This guide is so you never live that moment.
Why your host's backup isn't enough
It's not useless — it's that it's one copy, and you can't depend on a single one. Why:
- It lives in the same house. The backup often sits on the same machine/datacenter as the site. If the server goes down — or gets compromised, like the LiteSpeed case I covered yesterday — the backup can fall with it.
- You don't control it. Frequency, retention and availability are the host's call, not yours.
- Suspended account = lost backup. A late payment, a terms violation, or a closure, and the backup leaves with the account.
Do use the host's backup — as one of your copies. Not as the only one.
The 3-2-1 rule (the foundation)
It's the standard IT pros have used for decades, and it fits a website perfectly:
- 3 copies of your data (the original + 2 backups).
- 2 different media/locations (e.g. the server + cloud storage).
- 1 copy off-site — on another provider, out of reach of whatever would take the server down.
What goes in the backup (both halves)
A website is two things, and a backup that forgets one is useless:
- Files: the code, the uploads/media, themes, plugins, and config files.
- Database: the real content — posts, pages, users, orders, settings.
Files without the DB = an empty site. DB without files = content with no site. And note: versioning code in Git is not a backup — Git keeps the code, but not client uploads or the database.
How to do it in practice
WordPress: a plugin like UpdraftPlus or All-in-One WP Migration, scheduled and pointed at an external destination (Google Drive, S3, Dropbox). Don't save the backup inside the site's own folder.
Custom site (PHP and the like): a scheduled task (cron) that packs files + database and ships it off-site. The skeleton I use:
# daily-backup.sh — files + database, shipped to external storage
DAY=$(date +%F)
mysqldump -u USER -pPASSWORD DB_NAME | gzip > /tmp/db-$DAY.sql.gz
tar -czf /tmp/site-$DAY.tar.gz /path/to/site
# ship off the host (rclone -> Google Drive/S3/Backblaze)
rclone copy /tmp/db-$DAY.sql.gz remote:backups/
rclone copy /tmp/site-$DAY.tar.gz remote:backups/
rm -f /tmp/db-$DAY.sql.gz /tmp/site-$DAY.tar.gzSchedule it in cron (e.g. 3 AM daily) and keep several versions — not just the latest. If a problem (or ransomware) corrupts the site, the most recent copy may already be spoiled; you'll want to roll back a few days.
The step almost no one takes: test the restore
This is the secret. A backup that's never been restored is just hope. Corrupted files, an incomplete dump, a deletion no one noticed — you only find out at the worst possible moment. Every few months, take the backup and restore it into a test environment (local or a subdomain) and confirm the site comes up whole. If you've never restored, you don't have a backup — you have a file and a leap of faith.
The checklist for a backup that saves you
- ☐ It's automatic (doesn't rely on you remembering).
- ☐ It includes files + database.
- ☐ At least one copy off the host.
- ☐ It keeps several versions (not just the latest).
- ☐ The restore has been tested in the last few months.
- ☐ The backup destination's credentials are stored somewhere safe.
I want a backup routine that actually saves me
Not sure your backup would hold up when it counts? I set up (and test) a 3-2-1 routine for your site — let's talk.