How to Back Up a WordPress Site Properly

Most people who think they have a WordPress backup have half of one. They have the files but not the database, or a copy sitting on the same server as the site it is meant to protect, or a nightly job that has been silently failing since March. None of that is discovered on an ordinary Tuesday. It is discovered on the day the site is gone, which is the one day it is too late to find out.

This is what a WordPress backup actually has to contain, the three ways to make one, and the step almost everybody skips.

A backup is two things, and you need both

WordPress keeps your site in two completely separate places, and a copy of one is worth very little without the other.

Restore the files without the database and you get a working WordPress install with no content at all — the theme is there, the pages are not. Restore the database without the files and you get every word of your site pointing at a theme and plugins that no longer exist, which usually renders as a white screen.

The WordPress documentation on backups is explicit about this, and it is still the single most common gap. If your backup is a zip of public_html and nothing else, you do not have a backup of your website. You have a backup of its wallpaper.

The files that matter most

Inside the site folder, three things are irreplaceable and everything else is not:

• wp-content/uploads/ — every image and document anyone has ever added. This is usually the bulk of the size, and it is the part you cannot download again from anywhere.
• wp-content/themes/ — specifically any custom theme or child theme. A stock theme can be re-downloaded; the CSS somebody wrote for you three years ago cannot.
• wp-config.php — your database name, user, password and, crucially, your table prefix and security keys. Losing this is recoverable but tedious. The wp-config reference covers what each value does.

WordPress core itself does not need backing up. It is the same few thousand files on every installation on earth and you can fetch a clean copy in seconds. Nor do you need the caching plugin's cache directory, which is often several gigabytes of files that regenerate themselves and do nothing but make your backup slow and expensive to store.

Your host's backup is not your backup

Nearly every host advertises backups. They are worth having and they are not enough on their own, for four reasons that only ever come up at the worst possible moment.

They are on the same infrastructure. A host-level backup protects you against your own mistakes. It does not necessarily protect you against the host's — an account suspension, a billing dispute, or a provider going under takes the site and the backups together.

The retention is shorter than you think. Seven days is common on shared hosting. Malware often sits quietly for weeks before it does anything visible, so by the time you notice, every backup in the window may already contain it. This is the failure mode we see most often in malware recovery work.

Restores are often all-or-nothing. Plenty of hosts will roll the whole account back to a point in time. If you want one deleted page from Tuesday without losing Wednesday's orders, that is a very different job.

Nobody is checking they work. An automated job that started failing in March will keep reporting nothing at all, because there is nothing to report to.

Keep the host backup. Treat it as the convenient one, and hold your own copy somewhere the host cannot reach.

Three ways to back up WordPress

Most sites should use a plugin for the routine schedule, keep the host backup as a bonus, and know how to do it by hand for the awkward cases. Those are not alternatives so much as layers.

The plugin route

UpdraftPlus is the usual choice and the free version does the job properly, which is not true of every free backup plugin. Whichever you use, the configuration matters more than the brand:

1. Back up files and database on separate schedules. The database changes constantly; the uploads folder barely changes at all. Daily database and weekly files is a sensible starting point for a brochure site.
2. Send it to remote storage. Google Drive, Dropbox, S3, anything that is not the server. A backup stored in wp-content is deleted along with everything else when the account goes.
3. Set retention deliberately. Keep enough copies that you can go back past a slow-moving infection. Thirty days is a reasonable floor; two copies is not.
4. Turn on failure emails and make sure they go to an address someone reads.

The manual route

If you have SSH access, WP-CLI makes this two commands. The database first:

wp db export backup-$(date +%F).sql

That writes a dated SQL dump into the current directory, reading the credentials straight out of wp-config.php so there is nothing to type. Then the files:

tar -czf site-$(date +%F).tar.gz wp-content wp-config.php

Two archives, dated, containing everything that is genuinely yours. Download both, and delete the copies from the server once they have transferred — a SQL dump sitting in your web root is readable by anyone who guesses the filename.

Without SSH, cPanel will do the same through a browser: phpMyAdmin exports the database and the File Manager compresses the folder. Our guide to cPanel for WordPress covers where those tools live. The database backup documentation walks through the phpMyAdmin export screen option by option.

How often, and where to keep it

The right frequency is not a number somebody else can give you. It is the answer to one question: how much work are you willing to redo? Whatever happens between two backups is what you lose.

A shop is the case people get wrong. A daily database backup on a site taking orders means that on a bad day you lose up to twenty-four hours of orders — not just the revenue, but the customers' expectation that their order exists. If you are selling, the database needs backing up far more often than the files do.

For where to keep them, the NCSC's guidance on backing up your data is short, free and written for small organisations. The principle it comes down to is that at least one copy should be somewhere separate from the live site — different provider, different account, not merely a different folder.

The step everybody skips: test the restore

An untested backup is not a backup. It is a file you hope is a backup, and the difference between those two things becomes apparent exactly once.

The failures are mundane and common: the archive is truncated because the job timed out. The SQL dump is 0 bytes. The database exported with a different table prefix than the one wp-config.php expects. The uploads folder was excluded by a filter somebody set two years ago. Every one of those is invisible until you try to use it.

Test it like this, twice a year:

1. Spin up a staging site, or a local install — most decent hosts offer staging in one click.
2. Restore the most recent backup into it. Not a fresh one made for the test; the one your schedule actually produced.
3. Log in. Load the home page, one deep page, and the checkout or contact form.
4. Check the uploads. Images are the first thing to go missing and the last thing anyone notices.

If that takes an afternoon, it has told you something valuable about how long a real recovery would take, which is worth knowing before it is happening for real. If your site is down right now and you are reading this hoping for good news, urgent support is the faster route.

Backups and UK data protection

Worth a paragraph, because it is routinely forgotten. If your site has customer accounts, orders or form submissions, your backups contain personal data — and UK GDPR applies to them exactly as it applies to the live database.

Two practical consequences. Backups need to be held securely, which in practice means encrypted at rest and not in a shared Dropbox folder anyone in the company can browse. And they need a retention period, because keeping every nightly backup forever means holding personal data indefinitely with no stated purpose. The ICO's guide to data security sets out what is expected.

There is a wrinkle worth knowing: if someone exercises their right to erasure, you are generally not expected to dig their data out of every archived backup, but you are expected to make sure it is not restored back into the live site. Documenting that in your retention policy is the usual approach.

What good looks like

You have a working backup strategy when all five of these are true:

• Database and files are both covered, on schedules that match how often each changes.
• At least one copy is held somewhere the host cannot delete.
• Retention is long enough to reach past a slow-moving problem — thirty days or more.
• Failures generate an email that a person reads.
• Somebody has restored one, on purpose, in the last six months.

The last one is the one that separates a backup strategy from a backup plugin. Everything above it is configuration; that one is the test.

If you would rather not own this, it is part of what a WordPress care plan covers — offsite backups, monitored, with restores tested rather than assumed. Our breakdown of maintenance costs sets out what that runs to, and whether it is worth paying for goes through the arithmetic honestly.