Everyone has backups until they need one. The two common discoveries at that moment are that the backup does not include the database, or that nobody has ever tried restoring it.
A working backup strategy covers files and database together, stores copies somewhere separate from the server, retains several versions rather than only the newest, runs automatically, and has been tested by performing an actual restore. A backup nobody has restored is a hypothesis, not a backup.
What has to be included
- Database. All your content, users, orders and settings. Missing this is the most common failure.
- Files. Themes, plugins, uploads and custom code.
- Configuration. Server settings, redirect rules, environment variables.
- Certificates and DNS records, at least documented so they can be recreated.
Files without the database gives you an empty site. Database without files gives you content with nothing to display it.
How often, and how long to keep
| Site type | Frequency | Retention |
|---|---|---|
| Brochure site, rarely changed | Weekly | One to three months |
| Business site with a blog | Daily | One month, plus monthly archives |
| E-commerce | Daily minimum, hourly for orders | Three months minimum |
| Anything with user accounts | Daily, continuous for the database | Per your data policy |
Frequency should reflect how much work you are willing to lose. Weekly backups mean accepting the loss of up to a week.
The rules that make backups reliable
- Store off-server. A backup on the same server is lost with the server. Use separate cloud storage.
- Keep versions. If corruption goes unnoticed for a week, you need last week's copy too.
- Automate. Manual backups stop happening within a month.
- Monitor. Alert on failure, because silent failure is the norm.
- Test restores. Quarterly, to a staging environment. This is the step everyone skips and the only one that proves anything.
Backups are not a security strategy
They are recovery, not prevention. Ransomware that sits undetected for weeks can encrypt your backups too if they are reachable from the same server.
Keep at least one copy that the web server cannot write to. That is what makes the difference between an inconvenience and a rebuild from scratch.
Frequently asked questions
How often should I back up my website?
Match it to how much work you can afford to lose. Daily suits most business sites, weekly is acceptable for sites that rarely change, and e-commerce should back up at least daily with more frequent database copies so orders are not lost.
Does my host back up my site?
Many do, and the details matter: how often, how long they retain copies, whether the database is included, and how quickly you can get a restore. Host backups are a reasonable baseline and a poor sole strategy, since a hosting account problem can take both.
Where should backups be stored?
Somewhere separate from the web server, such as cloud object storage. A backup on the same machine disappears with the machine. Ideally keep one copy the web server has no write access to, so malware cannot reach it.
How do I know my backups work?
Restore one. Take a recent backup, restore it to a staging environment and check the site functions and the data is complete. Do this quarterly. Until you have restored, you do not know whether the backup is usable.
How long should I keep backups?
At least a month of daily copies plus a few monthly archives. Problems are often discovered well after they occur, and a single most-recent backup may already contain the corruption you are trying to escape.