Nobody thinks about backups until the moment they need one, and that is the worst moment to find out they do not work. The good news is that you can check, without being technical. These six questions will tell you whether your backups would really save you.
1. Where are they stored?
Ask your host or provider where the backups sit. If the answer is "on the same server as the site", a server failure or a hack could take both. You want copies stored somewhere else, ideally encrypted.
2. What is in them?
A site has two halves: its files and its database. The files hold the code and your uploads. The database holds your pages, orders, users and settings. A backup that covers only one half cannot rebuild the site.
3. How far back can you go?
Problems are often noticed weeks after they happened: a deleted page, a slow infection, a bad update. If your history only goes back a few days, the clean version may already be gone. Ask for the number of days of history and compare it with how quickly you tend to notice things.
4. When was a restore last tested?
This is the question that matters most. Taking a backup is automatic. Restoring one onto a test copy and checking the site works is a separate job, and most setups never do it. Ask for the date of the last test and the result. If the answer is "never", you do not yet know that your backups work.
5. Who can restore, and how do you ask?
When something breaks you will not want to work this out. Know who restores, how to ask, what they need from you and roughly how long it takes. Write it down where you can find it.
6. Will you be told?
A backup that fails silently looks fine until you need it. You want a report or alert that tells you when backups ran, when a test was done and what the result was.
Warning signs
- "We think it is backed up" with no date or proof.
- Backups stored on the same server as the site.
- Only the files, or only the database.
- No restore test, ever.
- No report or alert of any kind.
Types of backup, in plain words
| Type | What it is | Good for | Watch out for |
|---|---|---|---|
| Full | A complete copy of files and database | Rebuilding a whole site | Large, so often taken less frequently |
| Incremental | Only what changed since the last copy | Frequent backups without huge storage | Needs the earlier copies to restore |
| Database only | Pages, orders, users and settings | Sites whose content changes daily | Does not include the theme or uploads |
| Files only | Code, theme, plugins and uploads | Rolling back a bad update | Does not include your content |
The three-two-one idea
A well-known rule of thumb is to keep three copies of important data, on two different kinds of storage, with one copy somewhere else. For a website this means: the live site, a backup near it for fast restores, and another backup stored away from your hosting server. The exact numbers matter less than the idea: do not keep all your copies in one place.
What a restore actually involves
- Choose the backup to go back to.
- Restore the files and the database to a test location.
- Check that pages load, forms work and, on a store, an order can be placed.
- If it works, restore it to the live site, or copy back what you need.
- Check the live site again.
Knowing these steps in advance is half the value of a test.
If you are restoring after a hack
Take care. A backup taken after an infection restores the infection too. Choose a backup from before the problem began, find out how the attacker got in, and close that way before putting the site back online, or the same attack will work again.
Who should be able to reach your backups
Backups hold the same customer details as your live site, so access should be limited and logged. Ask who can download or delete them, and keep the logins for the backup storage separate from your site logins.
How often to back up, by type of site
| Type of site | A sensible rhythm |
|---|---|
| A brochure site that rarely changes | Weekly for files, daily for the database |
| A blog or content site | Daily for the database, weekly or daily for files |
| An online store | Daily, and before every update |
| A site that takes bookings or sign-ups | Daily, because new entries arrive all day |
A message you can send your host
"Hello, I would like to understand the backups for my site. Could you tell me: where they are stored, how often they run, how many days of history I can go back, whether both files and database are included, and when a restore was last tested? Please also tell me how to ask for a restore and how long it usually takes. Thank you."
The way they reply tells you a lot. A clear, specific answer is a good sign. A vague one is a reason to look further.
A word on encryption
Encrypting a backup means it is locked, so that anyone who gets hold of the file cannot read it without the key. Because backups hold the same customer details as your live site, encryption is worth asking about, together with who holds the key.
How long is long enough?
| If you tend to notice problems... | Keep at least |
|---|---|
| Within a day or two, because you watch the site closely | A couple of weeks of history |
| Within a few weeks, like most busy owners | Thirty to sixty days |
| Only when something goes wrong or a customer says so | Sixty days or more, plus a longer archive |
For reference, our plans keep 45 days on Essential, 60 days on Business, and 60 days plus a one-year archive on Priority.
Orders that arrive between backups
On a store, orders placed after the last backup are not in it. If you restore, those orders have to be found and re-entered from your payment provider, order emails or other records. This is why stores benefit from daily backups and from knowing where else their order records live.
Backups and moving to a new host
A move is a risky moment. Take a fresh backup of files and database before you start, keep it somewhere you control, and do not cancel the old hosting until the new site has been tested and the old backup copies are safe.
If you find a gap
- Take a manual backup of files and database now, and store it somewhere you control.
- Ask your provider to fix the gap and to tell you when it is fixed.
- Schedule a restore test, and put the date in your diary.
- Ask whether a different arrangement, such as managed backups, suits you better.
A list to keep
Print the 12-point website backup checklist and go through it with whoever looks after your site. To see how we handle each point, read about our backup services.
