---
title: "WordPress Backups: How to Back Up Your Site and Test a Restore"
description: "How to back up a WordPress site: what a full backup holds, what your host keeps, where copies should live, and how to test a restore before you need one."
url: https://publishmyblog.com/guides/wordpress-backup/
section: "Guides"
author: "Saeed Shahriar"
published: 2026-10-31T18:49:19.243Z
---

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

A backup you've never restored is a hope. Seven steps to backups you can actually bring back, including the day wp-admin won't load.

In October, stolen UpdraftCentral keys were used to [plant backdoor plugins on WordPress sites](https://publishmyblog.com/website-tools/updraftplus-updraftcentral-breach/). 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](https://publishmyblog.com/seo/rank-math-pro-backdoor/), 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](https://publishmyblog.com/guides/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.