A Website Backup Routine You Can Trust

4 min read

Đọc bằng tiếng Việt →

Most site owners have a backup in the same way most people have a spare key: somewhere, probably. The trouble is that a backup nobody has checked is a hope, not a plan. This guide is for self-hosted WordPress sites and walks through a routine that a non-developer can set up in an afternoon and keep alive with a few minutes a month.

What a complete backup actually contains

A WordPress site is built from two halves, and you need both to rebuild it.

  • The database holds your posts, pages, comments, menus and settings.
  • The files hold WordPress itself, your theme, your plugins, your uploaded media and a couple of configuration files.

A copy of only one half cannot bring the site back. It is also worth knowing that the export option built into the WordPress dashboard does not include themes, plugins or media, so it is a handy way to move content around but it is not a backup.

How often should it run?

Match the schedule to how quickly your site changes. WordPress’s own administration handbook suggests roughly weekly copies for a small site that rarely changes, and daily copies for a busy one. If you take orders, accept bookings or publish several times a day, think about what you would lose between two backups and tighten the schedule until that loss is tolerable.

On top of the schedule, take a manual copy before anything risky: a WordPress core update, a theme change, a plugin installation or a site move.

Where the copies should live

If the only backup sits on the same server as the website, one failure takes out both. Aim for a small spread of recent copies in different places, for example:

  • your hosting provider’s own backup tool
  • a cloud storage service such as Google Drive, Dropbox or Amazon S3
  • a folder on your own computer

Hosting backups are a good starting layer, but keep at least one copy that you control independently of the host.

A setup checklist

  1. Find out what your host already does. Look in the hosting control panel for backup settings, and note how long copies are kept and whether you can download them.
  2. Add a backup plugin if the host’s tool is thin. For most people, a plugin that runs on a schedule and can restore in a few clicks is the least painful option.
  3. Choose a schedule that fits the section above. Be aware that some scheduled jobs only fire when someone visits the site, so a very quiet site may not run exactly on time.
  4. Send copies off the server to cloud storage or your own computer so a copy exists elsewhere.
  5. Name things clearly. If you save manual copies, put the date in the folder name so you can tell Tuesday’s copy from last month’s.
  6. Turn on notifications so a failed job reaches your inbox rather than going unnoticed.

Prove the restore works

Security specialists at Sucuri recommend keeping off-site copies of both files and database, and testing at least one restore. They also suggest a restore drill every quarter. You do not need to be technical to run a simple version of this:

  1. Download your most recent backup and open it. Confirm that it contains both a set of site files and a database export.
  2. If your host offers a staging or test copy, restore the backup there rather than on your live site.
  3. Browse the restored copy. Log in, open a few pages, submit a contact form and, for a store, go as far as the cart.
  4. Write down how long it took and what you had to click. In an emergency you will be glad of the notes.

When restoring by hand, the handbook describes bringing the files back first and importing the database afterwards. If the database login details changed in between, the site’s configuration file needs to be updated to match, which is a good moment to ask for help.

Common mistakes

  • Keeping the only copy on the web server itself.
  • Backing up the database but not the media folder, or the other way round.
  • Assuming a green tick in a plugin means the files are actually usable.
  • Never running a manual backup to compare against the automatic ones. The handbook suggests doing this from time to time as a sanity check.
  • Updating plugins first and backing up afterwards.

When it is time to call a developer

Bring in help if a restore fails or comes back half-working, if you suspect the site was hacked and are not sure the backups are clean, if your store processes enough orders that a day of lost data would hurt, or if you are moving to a new host. A developer can also set up staging, real-time copies and monitoring that go beyond what a plugin does out of the box. Our services page describes the development work we do, and our theme collection is worth a look if a redesign is on your list.

Further reading

← All posts