Daily Backups: How They Saved a Client and How to Set Yours Up
Last winter, one of our clients ran a botched theme update at 11pm on a Friday. By Saturday morning her checkout was broken, her product images were missing, and the staging site she "definitely had" turned out to be from 2022.
She was back online by noon Saturday. Not because we're magicians — because she had nightly backups, stored off-server, and we'd tested them six months earlier.
This is the story I tell when clients ask whether daily backups are "really necessary." Yes. Yes they are.
Backups protect against more than hackers
People associate backups with security, but the actual reasons we restore from backup are, in rough order of frequency:
- A user changed something they shouldn't have
- A plugin update broke a site
- A failed migration corrupted the database
- A theme change wiped customisations
- Hosting hardware failure (rare, but it happens)
- Actual malware compromise
Hacks are number six. The first five are everyday accidents.
The 3-2-1 rule (with modern updates)
The old industrial backup rule:
- 3 copies of your data
- 2 different storage media
- 1 off-site
For a modern website, this looks like:
- The live site (copy 1)
- A backup on the same server (copy 2 — useful for fast restores)
- A backup stored externally — S3, Backblaze B2, or a backup service (copy 3 — survives the hosting provider going down)
How often should you back up?
Daily is the minimum for any site that changes regularly. For ecommerce, hourly database backups are sensible — losing eight hours of orders is genuinely expensive. For a static brochure site, weekly is fine.
Whatever frequency you pick, the limit isn't really how often you back up — it's how much data you can afford to lose. That's your recovery point objective (RPO). Match the backup frequency to the RPO and you're sorted.
How to actually set this up
You have three good options, in order of effort:
1. Host-managed backups
Our hosting includes nightly off-server backups with 30-day retention on all business plans. The advantage: zero setup, restoration in a few clicks, support team can do it for you. The catch: you depend on the host. If you ever leave us, you'll want a copy somewhere of your own.
2. Plugin-based backups
The standard options:
- UpdraftPlus — free version is fine for most. Sends to Google Drive, Dropbox, S3, etc.
- BackWPup — similar, free, slightly older interface.
- BlogVault / Jetpack VaultPress — paid, off-site, incremental. The "set and forget" option.
3. Server-level backups
If you have a VPS or dedicated server, scheduled scripts using rsync or restic writing to S3 work brilliantly. Restic is particularly nice because it does encrypted, deduplicated, incremental backups.
Test your backups. Seriously.
I'll say it again: a backup you haven't tested is not a backup. At minimum, twice a year:
- Restore the latest backup to a staging environment.
- Click through the site. Log in. Check the database.
- Time the whole exercise. If a "full restore" takes ten hours, you have a real problem during an actual outage.
This sounds tedious. It is. It's also the only thing that distinguishes "we have backups" from "we have a recovery plan."
What to back up
For WordPress specifically:
- The entire
wp-contentfolder (themes, plugins, uploads — your actual content) - The database
wp-config.php(it has your salts and config)
You technically don't need WordPress core in your backup — you can always re-download it — but most backup tools include it, which is fine.
The day you realise you needed a backup is the wrong day to start setting one up. Today is the right day.
If you're on our hosting and want to enable off-site backups beyond our default, or if you want help setting up your own external backup destination, ping us. Five minutes of conversation can save you an afternoon of regret.