How to Back Up a WordPress Site, and Know the Backup Works

Most WordPress sites have a backup of some kind. Far fewer have a backup that would actually bring the site back. The difference usually shows up on the worst possible day: the server is gone, the archive turns out to hold only half the site, or nobody remembers the password to the storage it was sent to.

This guide walks through what a complete backup contains, how often to take one, where to keep it, and how to check that it works before you need it.

A WordPress site is two things

Every WordPress site lives in two places, and a backup needs both.

1. The files. WordPress itself, your theme, your plugins, and everything you have uploaded to the media library.
2. The database. Posts, pages, comments, users, settings, menus and, on a WooCommerce store, every product, order and customer.

A copy of the files without the database gives you an empty site with a nice theme. A copy of the database without the files gives you posts that point at images that no longer exist. One without the other is not a backup.

What to include, and what you can skip

You do not need to save every file on the server. These are the parts that cannot be downloaded again:

• wp-content/uploads/: your media library. Often the largest folder, and the one that cannot be recreated.
• wp-content/themes/ and wp-content/plugins/: especially any theme or plugin that was customised or bought, since you may not be able to download that exact version again.
• wp-config.php: it holds the database name, user and password, the table prefix and the security keys. Without it, a restored site cannot find its database.
• .htaccess, if your server uses one: it holds your permalink rules and any redirects.
• The full database, exported as a single dump.

What you can usually leave out:

• WordPress core files (wp-admin/, wp-includes/). They are the same on every site of the same version and can be downloaded again at any time.
• Cache folders, such as wp-content/cache/. They rebuild themselves.
• Old backup archives that a plugin left inside wp-content. Backing up your backups only makes every archive larger.

How often to back up

Match the schedule to how often the site changes, and to how much change you could afford to lose.

• A brochure site that changes a few times a month can live with a weekly backup, plus one before any big change.
• A blog that publishes several times a week is better off with a daily backup.
• A WooCommerce store takes orders around the clock. A day-old backup means a day of lost orders, so back the database up at least daily, and more often on a busy store.

Whatever the schedule, take one more right before you update WordPress, a theme or a plugin. That is the backup you are most likely to need.

Keep the backup somewhere else

A backup that sits on the same server as the site disappears together with it: a failed disk, a hacked account or a closed hosting plan takes both at once.

A simple rule that has held up for decades is 3-2-1: keep three copies of your data, on two different kinds of storage, with one copy off-site. For a WordPress site, that can be as simple as:

• the live site on your server,
• a copy in object storage, such as Amazon S3, Cloudflare R2, Backblaze B2 or Wasabi,
• an occasional copy downloaded to your own computer or a second provider.

Two more habits are worth keeping:

• Encrypt the backup before it leaves the server. Your database holds user emails, password hashes and, on a store, customer addresses.
• Keep more than one version. If a site is quietly hacked, you may not notice for weeks. A setup that keeps only the latest backup will happily replace your last clean copy with an infected one. Keep daily backups for a couple of weeks and a monthly one for longer.

A backup you have never restored is only a hope

This is the step almost everyone skips. A backup job can report success for months while producing archives that are empty, cut short or impossible to open.

The only real test is a restore. Every so often, take a recent backup and bring it back somewhere that is not your live site, such as a staging copy or a local install, then check that:

• the database imports without errors,
• the home page and a few inner pages load,
• images appear in the media library,
• you can log in to the dashboard,
• on a store, recent orders are there.

If any of these fail, you have found the problem on a quiet afternoon instead of during an outage.

A short checklist

• Files and database are both in every backup
• wp-content/uploads/ and wp-config.php are included
• The schedule matches how often the site changes
• An extra backup runs before every update
• Backups are stored off the server, and encrypted
• Several versions are kept, not only the latest
• A restore has been tested recently

Where PaperScale fits

If you run WordPress on your own server, PaperScale takes care of most of this list. It backs up files and database together on a schedule, encrypts them before they leave the server and sends them to storage you own, and takes a snapshot before every update it makes. The docs show how to connect a server and set it up.

Whatever tool you use, the checklist above is the part that matters.