What a backup must contain
A website is more than its files. For WordPress (and most content management systems) a complete backup has two parts:
- files: the theme, plugins, uploaded images and documents, and the configuration file,
- the database: all content, settings and users, and for an online store, orders and customers too.
Backing up only the files without the database (or vice versa) is a common mistake that shows up only when you need to restore.
Remember: a database backup of a store or a site with forms contains personal data. Keep it somewhere secure, with limited access, and don’t store it longer than you need to.
The 3-2-1 rule
A proven rule that applies well beyond websites:
- 3 copies of your data (the original plus two backups),
- on 2 different media or services,
- with 1 kept off-site, at a different company or location from the website’s server.
Backups made by your host are convenient, but they sit with the same provider as the website. If someone takes over your hosting account, the provider has a major outage or you simply leave, you can lose the site and its backups at once. That’s why, on top of the host’s backups, it’s worth having your own automatic off-site backup, e.g. in external cloud storage.
How often
The frequency depends on how quickly the site changes and how costly losing those changes would be:
| Type of website | Recommended frequency |
|---|---|
| Brochure site, rarely changed | weekly, plus before every major change |
| Site with a blog or news | daily |
| Online store, bookings | daily, and the database even every few hours |
Whatever the schedule: always back up before an update, a theme change or installing a new plugin. More on that in the guide to safe WordPress updates.
How long to keep backups
The latest backup alone isn’t enough. A hack or data error is often discovered days or weeks later, by which time the newest backup contains the same problem.
A good starting point is a retention policy that keeps:
- daily backups from the last 1–2 weeks,
- weekly ones from the last 1–2 months,
- optionally monthly ones for longer.
That way you can roll back to before the problem started, not just to yesterday.
An untested backup doesn’t exist
The most common letdown: backups have been running for years, and on the day of the outage it turns out the archive is corrupted, incomplete, or nobody knows how to restore it.
So every now and then (say, once a quarter) run a restore test:
- Restore a backup on a staging server or in a separate directory, never over the live site.
- Check that the site loads, images are there, and forms and logins work.
- Time it and write down the steps. During a real outage there’s no time to look for instructions.
When a backup comes in handy
- A failed update broke the layout or took the site down.
- A hack or malware: you restore a clean version from before the infection, then patch the hole the attackers used.
- Human error: someone deleted a page, overwrote content or removed products.
- Moving to a new host: a backup is simply a ready-made package to migrate.
Checklist
- Backups include both the files and the database.
- Backups run automatically, without my involvement.
- At least one copy is stored off the server and outside the hosting company.
- I keep several weeks of backups, not just the latest.
- A fresh backup is made before every update or major change.
- At least once a quarter I check that a backup can be restored.
- Backups containing personal data are secured and not in a public directory.
