Backups: a copy counts once it has been restored
Backups are routine care for any website. What belongs in them, the 3-2-1 rule, how often to save, and why a regular restore test is part of the routine.
Request an AI summary
Backups are a bit like a spare tyre: part of the equipment, checked now and then, and reassuring to have. For a website, they’re simply part of normal care, alongside updates and monitoring.
A backup has one purpose: getting a site back to a known state. Whether that’s after an accidental deletion, an update that didn’t go as planned or a move to a new server, a good routine makes it a calm, planned step.
1. Contents: what belongs in a backup
A website is more than its pages. A complete backup covers:
- Files: the code, themes, plugins and everything that was uploaded, such as images and PDFs.
- The database, for sites that use one: pages, posts, products, orders, users, settings.
- Configuration: server settings, environment variables, redirects.
- Outside the website: DNS records, email settings and the list of services the site connects to. These are easy to overlook and handy to have written down.
For a static site whose content lives in a version-controlled repository, much of this is already covered by the repository itself; what remains is configuration and anything stored elsewhere.
2. The 3-2-1 rule
A well-known rule of thumb for backups:
- 3 copies of the data: the live one and two backups.
- 2 different storage types, for example the server and a separate storage service.
- 1 copy off-site, at a different provider or location from the server.
The idea is simple: no single event, whether at the server, the hosting provider or in an account, affects all copies at once.
3. Frequency: matched to how the site changes
How often to save depends on how much would be missing between two backups:
- A site that changes a few times a year: a backup after each change, plus a regular one.
- A blog with weekly posts: daily backups.
- A shop with orders throughout the day: frequent database backups, often several times a day.
How long to keep them matters too. Several generations, for example daily ones for a few weeks and monthly ones for longer, make it possible to go back to a point before a change that was noticed later.
4. Automation: backups that run on their own
Backups that depend on someone remembering them tend to happen irregularly. Automated backups run on a schedule, and a notification confirms each one or reports when one didn’t complete. That turns backups from a task into a routine that’s simply there.
5. Restore test: the step that makes it count
A backup proves its value when it’s restored. A regular restore test, for example to a separate test environment, confirms:
- The copy is complete: files, database and configuration are all there.
- It works: the restored site runs and looks right.
- The steps are known: how a restore is done is written down, so it’s a calm routine rather than something to figure out.
That’s the difference between having backups and being able to rely on them.
6. Before changes: a fresh snapshot
Some moments call for an extra backup: before a larger update, a redesign, a move to new hosting or a bigger content change. A fresh snapshot right before makes it possible to go back to exactly that state.
The short version
- Backups are routine care, like updates and monitoring.
- Contents: files, database, configuration, and notes on DNS and email.
- 3-2-1: three copies, two storage types, one off-site.
- Frequency follows how often the site changes; several generations are kept.
- Automated, with a notification for each run.
- Restore tests turn a copy into a backup you can rely on.
If you’d like backups for your website set up and looked after, get in touch.