WordPress Backups: How to Back Up Your Site and Test a Restore

In October, stolen UpdraftCentral keys were used to plant backdoor plugins on WordPress sites. TeamUpdraft says backups in customers’ own remote storage weren’t touched.

That’s the case for backups in one week.

The copy that saves you is the one off the server, older than the problem, and one you’ve restored before. Everything else is a nice feeling.

The short version: back up the database and files together, keep one copy away from your host, and restore one to a staging site before you need it.

The 7 steps at a glance

Here’s the order I’d set it up in. Most of it is a one-time job.

#	Step	Where you do it	About
1	Know what a full backup holds	Your backup tool or host	10 min
2	Find out what your host already keeps	Host dashboard, help docs	15 min
3	Decide how much work you can afford to lose	A note to yourself	5 min
4	Pick a backup tool you’ll keep running	Plugins, or your host	20 min
5	Send copies off-site and lock them down	Cloud storage account	20 min
6	Keep enough history, skip the junk	Backup settings	10 min
7	Restore one to staging	Staging site or local copy	1 hour

Step 1. Know what a full backup holds

A WordPress site lives in two places. WordPress.org puts it plainly: there are two parts, the database and the files, and “You need both to be able to fully restore” a typical site.

Part	What’s in it
Database	Posts, pages, comments, users, settings, plugin data, WooCommerce orders
Files	Uploads (your images and PDFs), themes, plugins, wp-config.php, .htaccess, WordPress itself

Back up the whole site, core files included. They can be downloaded again, but a full copy keeps the exact versions you were running.

The two halves also have to match. A database from Monday with files from Friday can break plugins or point at images that aren’t there, so treat each backup as one set from the same moment.

A few things live outside WordPress altogether: email at your host, DNS records, licence keys. Note where each one is kept.

Check it: open your latest backup and find two things, a database file (usually .sql) and the wp-content/uploads folder with recent images in it.

Step 2. Find out what your host already keeps

Most hosts take backups for you. How long they keep them, and where, varies a lot:

Host	What its docs say
WP Engine	Stores 30 days of backup checkpoints
Kinsta	Daily backups, “stored on the same host machine as your site”; manual ones kept at least 14 days
SiteGround	Up to 30 daily copies on shared hosting, up to 7 on Cloud hosting

Notice the Kinsta line? A copy on the same machine is fast to restore, but it shares that machine’s bad day. Kinsta sells an add-on that sends backups to outside storage.

Ask your host five questions:

• How long are backups kept?
• Do they include the database and files?
• Can you download one?
• Is there a fee to restore?
• And the one people forget: what happens to the backups if your account is suspended?

Check it: download one host backup to your computer and open it. If you can’t download it, it isn’t yours.

Step 3. Decide how much work you can afford to lose

Your schedule comes from one question. How much would you hate to redo? Here’s how I’d set it:

• A brochure site that changes once a month: weekly is fine.
• A blog: daily.
• A shop, a membership site or anything taking bookings: the database far more often than the files, because every order lives there. Check that your tool can do it, and test it (step 7).

Whatever the schedule, run one more backup right before every update. That’s when sites break.

The October backdoor at Rank Math arrived as an ordinary plugin update, for example.

The other half is time. How long can the site be down? If the answer is “an hour”, you need a restore you’ve practised (step 7).

Check it: the gap between two backups is shorter than the work you’d be willing to lose.

Step 4. Pick a backup tool you’ll keep running

There are three ways to do it: your host’s backups, a plugin you control, or a paid backup service that runs from outside your server. I’d use your host’s backups plus one you control.

Here are the plugins most people choose from, with the active installs WordPress.org shows today:

Plugin	Installs	Worth knowing
All-in-One WP Migration	5+ million	Free version backs up any size, but your host’s upload limit decides how big a file you can import
UpdraftPlus	4+ million	Free version sends backups to Dropbox, Google Drive, Amazon S3, FTP or email
Duplicator	1+ million	Free version includes encrypted archives, one-click restore and cloud storage
WPvivid	900,000+	Scheduled backups, cloud storage and migration in one plugin
BackWPup	400,000+	Database and file backups to local or cloud storage
BlogVault	80,000+	A service: backups are processed and stored on BlogVault’s own cloud
Jetpack VaultPress Backup	20,000+	Daily backups plus real-time ones, stored by Jetpack; no multisite

Pick one for your site. Two backup plugins running at the same time can slow a site and fill the disk.

Check it: the plugin’s log shows a finished scheduled backup with a recent time, the database and files both included, a destination, and no warnings.

Step 5. Send copies off-site and lock them down

The rule backup people use is 3-2-1. CISA’s version: keep 3 copies of any important file (one primary, two backups), on 2 different types of storage, with 1 copy off-site.

For a website that means the live site, a host backup, and one copy somewhere else entirely: Google Drive, Dropbox, Amazon S3, Backblaze.

Then protect that storage like the site itself:

• Use a separate login with two-factor authentication, not the same email and password as your hosting.
• Never leave backup archives in a public folder on the site. They hold your whole database, customer details included.
• Turn on encryption if your tool offers it.
• When a service you’ve connected is breached, revoke and reconnect its access, the way TeamUpdraft told UpdraftCentral users to re-authorise their remote storage.

Check it: log into the storage account directly, not through WordPress, find this week’s backup and download it.

Step 6. Keep enough history, skip the junk

Hacks are often found weeks late. Keep only seven days and every copy might be infected.

So keep at least 30 days of daily backups, and add one monthly copy for a few months. Then a hack you find in week six still has a clean copy from week five waiting for it.

Leave out what you can rebuild, like caches, logs and old backup files in wp-content. But keep anything unique, such as uploads or a plugin’s data folder.

Check it: your oldest restore point is more than 30 days old, and backup sizes don’t jump without a reason.

Step 7. Restore one to staging

Almost everyone skips this one. A finished backup only proves the job ran. It doesn’t prove the archive opens, or that the site boots from it.

So restore one, to your host’s staging site or a local copy made with a tool like LocalWP. Never test on the live site.

Restore the files and database from the same backup, then click through:

• the homepage and a few posts, with their images
• logging in to wp-admin
• a contact form, sending a test message
• for a shop, a test order through checkout

Write down the date, the backup you used and how long it took. That’s your real recovery time, and it’s usually longer than people expect.

Check it: you have a note with the restore date, the backup you used, the time it took, and what broke.

When wp-admin won’t load

A hacked or broken site often won’t let you log in. A restore button inside WordPress is no use then. Here are your options, easiest first:

1. Your host’s restore tool, from the hosting dashboard.
2. Your plugin’s own recovery route, if it has one that works without wp-admin. Check its docs now, while the site works.
3. By hand: upload the files over SFTP, import the database through phpMyAdmin or wp db import, and make sure wp-config.php has the right database details.

WordPress.org’s typical restore order is files first, then the database.

Did the domain change? Use wp search-replace instead of editing the SQL file, because it handles WordPress’s serialized data.

Keep your SFTP, database and hosting logins in a password manager, so you can still reach them when the site is down.

For developers: a manual backup

With SSH and WP-CLI, a basic backup is two commands from the site’s folder:

• wp db export backup.sql writes the database to a file
• zip -r site-files.zip . -x "wp-content/cache/*" packs the files, skipping the cache

Download both and keep them together. Then delete backup.sql from the server, so nobody can download it from the web.

What’s overrated

• The “backup complete” email. It tells you a job finished, nothing about whether it restores.
• One backup on the same server, which disappears with the account or the disk.
• Backing up every hour on a site that changes weekly. It fills storage and buries the copy you want.

Why it matters

Updates, plugins and hosts all fail at some point, and the October incidents showed that even a trusted tool can become the way in to a site that did everything right.

A backup is the one fix for all of them, from a bad update to a deleted page to a full hack. It only works if you can get it back.

Doing just one thing this week? Make it step 7. You’ll learn more in that hour than from a year of “backup complete” emails.

The rest is in the WordPress security checklist.

Common Questions

How often should I back up my WordPress site?

Match it to how often the site changes. Weekly suits a brochure site, daily suits a blog, and a WooCommerce shop needs its database backed up many times a day. Always run one more backup right before updating plugins or WordPress.

Are my web host’s backups enough for a WordPress site?

Rarely on their own. Host backups often sit on the same server or account as the site, and retention varies from a week to a month. Keep at least one extra copy in storage you control, such as Google Drive or Amazon S3.

Can I back up WordPress without a plugin?

Yes. Your host’s backup tool, or WP-CLI’s wp db export plus a zip of the site’s files over SSH, gives you the same two parts a plugin does. A plugin mainly adds scheduling and off-site uploads for people who don’t use a command line.