Back up WordPress the right way

Backing up WordPress is the difference between a hack that costs you half a day and a hack that costs you your site. The day an intrusion breaks everything, a clean backup lets you roll back in minutes. Without one, you rebuild from scratch, sometimes without the content you spent years building up.

The good news: a proper backup is set up once and runs on its own. You still need to back up the right things, in the right place, and confirm it works. Here’s how.

back up the files AND the database

A WordPress site is two separate pieces.

• The files: the WordPress core, your themes, your plugins, and above all the wp-content/uploads folder that holds all your images and media.
• The database: all your posts, pages, comments, settings, and user accounts.

If you back up only the files, you get the shell but no text. If you back up only the database, you get the text but not a single image. Either way the restore is useless. A real backup contains both, dated to the same moment.

This is the most common mistake I see: people convinced they’re covered because they export their posts using WordPress’s built-in export tool. That export includes no images, no settings, and no accounts. It is not a complete backup.

how often to back up

How often depends on how fast your site changes. The simple rule: you should be able to afford to lose everything that happened since the last backup.

• Brochure site, rarely edited: one backup a week is enough, sometimes one a month if you never touch it. Still, run a manual backup right before a major update or a theme change.
• Blog or site that publishes regularly: one backup a day. You don’t want to rewrite three posts because the last backup was from Monday.
• E-commerce, or any site with orders, bookings, or customer accounts: daily at the very least, possibly hourly. Every lost order is a real order, with a real customer behind it.

For most sites, a daily automatic backup is the right default. It’s rarely too much, and it means you never have to think about it.

store the backup somewhere other than the server

This is the part almost everyone gets wrong, and it’s the one that matters most the day you get hacked.

A backup stored on the same server as your site does not protect you. If an attacker takes over your hosting, they reach your backups at the same time as your site. They can encrypt them, delete them, or infect them. You end up with a broken site and backups you can’t use. Same thing if your server fails for some technical reason: it all disappears at once.

The rule: at least one copy of your backup must live off the server. In practice, send your backups to external storage:

• a cloud service like Google Drive or Dropbox, or object storage such as Amazon S3 or Backblaze;
• a remote server separate from your hosting;
• at a minimum, a regular download to your own computer, as a supplement.

Most backup tools can send files to these destinations automatically. Set up that transfer once, and your off-site copy builds itself.

the tools to automate it

You have three main options, and they combine well.

your host’s backups

Most hosts offer automatic backups, sometimes included, sometimes as a paid add-on. They’re a good safety net, but they come with two limits: they’re stored at the host (so not really “off-site”), and you depend on their frequency and retention, which you don’t always control. Check what your host actually keeps, and for how long. Don’t rely on it as your only protection.

a backup plugin

This is the most flexible option, and the one I recommend for staying in control. UpdraftPlus is the go-to free choice: it backs up files and database, schedules the automation, and sends copies to the cloud of your choice. Others do the same job, like BackWPup or Solid Backups. The typical setup: a daily or weekly backup depending on your site, automatic upload to external storage, and one-click restore from the dashboard.

the occasional manual backup

Before any risky operation (a major update, a theme change, work on the code), run a manual backup. It takes two minutes and gives you an immediate point to fall back to if something goes wrong.

keep several dated versions

A single backup, overwritten every time, isn’t enough. Here’s why.

A hack isn’t always caught right away. A site can stay infected for days or weeks before you notice. If your only backup is from yesterday, it may already contain the attacker’s backdoor. You restore, and you reinstall the infection along with your content.

The fix: keep several dated copies over a long enough window. For example, the last 7 daily backups plus a few weekly ones. That way you can go back to a version from before the infection. Most tools handle this retention automatically: you set the number of copies to keep, and the oldest ones drop off as new ones come in.

That depth in time is exactly what lets you restore your content the day of a hack from a clean version, instead of re-injecting the problem.

test your restores

A backup that’s never been tested isn’t a backup, it’s a guess.

People often discover a backup is corrupted, incomplete, or impossible to restore at the worst possible moment: during the emergency. The file had been empty for three months, the upload to the cloud had silently failed, the database wasn’t included. Nobody noticed because nobody had tried to restore.

Get in the habit of testing a restore now and then, two or three times a year. The cleanest way: restore your backup to a staging site (a test site, separate from the real one), and check that everything is there, that pages render, that images load. Many hosts and plugins let you spin up that kind of test environment in a few clicks. If you don’t have one, at least open the backup archive and confirm it contains the files plus a database export of a reasonable size.

frequently asked questions

Is a backup enough to protect me from a hack? It lets you roll back, but it doesn’t fix the hole that let the attacker in. If you restore without changing anything, the site can be re-compromised through the same door. After a restore, follow the full hardening checklist to close the entry point.

How long should I keep my backups? At least a few weeks of depth. The idea is to be able to go back before an infection that may have gone unnoticed for a while. A month of dated copies is a good starting point for a typical site.

My host already backs up, do I need anything else? Yes. A backup at the host stays in the same environment as your site and is outside your control. Add your own backup, sent to external storage, where you control the frequency and retention.

if the damage is already done

All of this is about getting ready before the incident. If your site is already compromised, don’t waste time improvising a backup on top of the infection: first see what to do if the site is already hacked.

And if you’d rather hand off the cleanup, that’s exactly what WP-Detox does. The scan is free and tells you where you stand. If you start the cleanup, we remove the backdoors and the injected content, get the site back in shape, and take a backup before any work so we can roll back if needed. Figure about 30 minutes, €149 all-in, and refunded if we can’t fix it.