A backup you have not tested is a guess
Most site owners agree that backups are a good idea. Fewer have ever tried to restore one. The gap matters, because the first time you discover a backup is incomplete, corrupted or missing the database is usually the moment you need it.
A backup is only useful if three things are true: it contains everything needed to rebuild the site, it is recent enough that losing the difference is acceptable, and you know the steps to put it back. This article walks through each.
What to back up
A typical site has more than one part, and a copy of only one part rarely restores the whole thing.
- Files. The theme or templates, uploaded images and documents, and any custom code. On many systems the uploads folder is the largest and most irreplaceable piece.
- The database. If your site stores posts, pages, settings, comments or orders in a database, the files alone will not bring that content back. Many people forget this part.
- Configuration. Settings files, redirect rules, server configuration and your robots file often live outside the main content folders. They are small but painful to recreate from memory.
- Records of what is installed. A note of which software versions and add-ons you run makes rebuilding on a fresh server far easier.
- DNS and account details. You cannot back up a hosting account, but you can keep a record of where your domain is registered, where DNS is managed and how to log in.
If your site is built as static files and kept in version control, the project folder itself may be most of the backup. Even then, form submissions, comments or a separate database on a third-party service need their own plan.
Where to keep copies
A common rule of thumb is to keep more than one copy and to keep at least one of them somewhere other than the server that runs the site. If the backup lives only on the same server, a hardware failure, a hosting account suspension or a compromise can take both the site and its backup at once.
Many hosting plans include automatic backups. These are worth having, but it is wise to find out how long they are kept, how you request a restore and whether the host charges for it. Treat them as one layer rather than the only layer.
If a backup contains customer data or login details, protect it as carefully as the live site. A forgotten archive in a public folder can be a security problem of its own.
How often
There is no single correct schedule. A useful way to decide is to ask how much recent work you could afford to lose.
- A brochure site that changes a few times a year may be fine with a copy after each change.
- A blog that publishes weekly might want at least weekly copies.
- A store that takes orders throughout the day typically needs the database copied much more often than the files, because new orders are the data you cannot recreate.
Whatever schedule you pick, automate it. Backups that depend on remembering tend to lapse.
Before a big change
Before a redesign, a platform switch, a major update or a site migration, take an extra backup by hand even if automatic ones exist. Label it clearly with the date and what it was taken before. Then check three things.
- The backup finished and its file size is plausible compared with the previous one.
- It includes both files and database where relevant.
- You know where it is stored and how to retrieve it without logging in to the thing you are about to change.
It also helps to record the state of the old site before you alter it: a list of important URLs, a note of current titles and a copy of the redirect rules. If something later looks wrong in search results, that record makes it easier to see what changed. Keeping a simple change log of what you did and when pays off here.
Testing a restore
The only proof that a backup works is restoring it. You do not need to do this on the live site. A practical approach is:
- Set up a separate test location, such as a local copy or a private staging area on your host.
- Restore the files and database from a recent backup into it.
- Open the site and click through key pages: the home page, a post, a form, the login page.
- Check that images load, links work and no pages show database errors.
- Write down the steps and how long it took.
That last note is valuable. During a real emergency you will be stressed, and having a written procedure with a known time estimate helps you decide calmly whether to restore or repair.
Repeat the test after major changes to the site, and at least once or twice a year otherwise.
Recovery after a failure
If a change goes wrong, resist the urge to make several fixes at once. Decide first whether the problem is small enough to repair or large enough to roll back. A restore replaces the current state, so anything added since the backup, such as new orders or comments, will need to be recovered separately if possible.
After restoring, check the basics: that pages load over a secure connection, that important pages are not blocked by an old configuration, and that redirects behave as intended. Then look at how search engines see the site over the following days. Problems such as indexing gaps or a spike in broken links after a rollback are signs that something was missed.
If the incident involved a compromise rather than a mistake, restoring an old copy may bring the same weakness back. In that case, find and close the entry point before restoring, and change passwords afterward.
Keep it boring
A good backup routine is dull: automatic copies, stored in two places, checked on a schedule and tested occasionally. It will not improve rankings by itself, but it limits how much a bad day can cost, and it lets you make bigger improvements with less fear.