How to Backup a WordPress Site in 2026: The Complete 3-2-1 Guide

If you want to backup a WordPress site the right way, you need more than a plugin that says “backup complete” once a week. You need copies of your files and your database, stored somewhere other than your web server, and you need proof that you can actually restore them. That last part is where most people get burned.

I have been building websites and online stores since 2010, and I run several WordPress sites for my own businesses today. Over that time I have learned that a backup you have never restored is really just a hope. Servers fail. Updates break things. Hosts close accounts. A plugin conflict at 2am can take a store offline in the middle of a sale.

This guide is the full playbook. I will walk you through what a WordPress backup actually contains, the 3-2-1 rule, the 4 main backup methods (host backups, plugins, manual SFTP plus database export, and WP-CLI), where to store copies off-site, how often to back up a blog versus an online store, how long to keep old copies, and how to restore and test a restore on staging. I will also cover the WooCommerce order-data problem that catches a lot of store owners off guard.

If you are brand new to hosting, start with my web hosting for beginners guide first. It explains hosting types, renewal pricing and why backups belong on your requirements sheet before you ever pick a host.

All right, let’s get into it.

Quick note: some links on Web Hosting Paradise may become affiliate links in the future. See our affiliate disclosure for details. My recommendations are research-based, and I never claim hands-on testing I did not do.

What a WordPress Backup Actually Contains

A WordPress site is really 2 things living side by side. There are the files on your server, and there is the database. A complete backup needs both, and they are stored in totally different places.

Your WordPress Files

The files are everything inside your WordPress folder on the server. That includes WordPress core, your themes, your plugins, the uploads folder with every image and PDF you ever added, and config files like wp-config.php and .htaccess.

The official WordPress backup documentation lists exactly these pieces. Core files can be downloaded again from WordPress.org, so they matter least. Your wp-content folder and wp-config.php are the parts you cannot easily replace.

Your WordPress Database

The database holds your posts, pages, comments, user accounts, settings, menus and plugin data. On a WooCommerce store it also holds orders, customers and product data. None of that lives in your files.

This is the part beginners forget. They download the wp-content folder over FTP, feel safe, and then realize later that all their actual content was in MySQL or MariaDB the whole time. The WordPress handbook has a separate page just for backing up your database for exactly this reason.

Why You Need Both Together

Files without the database give you a theme and a pile of images with no posts attached. A database without the files gives you posts that point at images that do not exist. You need a matched pair from roughly the same moment in time.

The usual restore order is files first, then the database import. Keep both in the same backup set, with the same date in the file name, so you never mix a Monday database with a Friday uploads folder.

The 3-2-1 Backup Rule for WordPress

The 3-2-1 rule is the simplest framework I know for not losing data. You keep 3 copies of your data, on 2 different types of storage, with 1 copy off-site. The US Cybersecurity and Infrastructure Security Agency recommends it directly on its page about how to back up business data.

Here is what that looks like for a normal WordPress site:

Copy 1 is the live site itself, running on your host.
Copy 2 is a backup on a separate cloud storage account, such as Amazon S3, Google Drive, Dropbox or Backblaze B2.
Copy 3 is a downloaded backup on your own computer or an external drive, refreshed every month or so.

That gives you 3 copies, at least 2 storage types (server and cloud, plus local disk), and at least 1 copy that has nothing to do with your hosting account.

CISA also recommends encrypted and offline copies, automated schedules, and regular restore tests. It suggests being able to roll back data at least 7 days. For a website, I treat 7 days as the absolute floor, not the goal.

Why Host-Only Backups Break the Rule

A lot of people think “my host does backups” covers them. Sometimes it does. But if the only backups live inside the same hosting account, you have a single point of failure.

If your account gets suspended over a billing issue, if the host has a major outage, or if a hacker gets into your control panel, the backups can go down with the site. Off-site means a copy you control in a separate account with a separate password.

Method 1: Backups From Your Web Host

Most hosts now include some form of automatic backup. The quality varies a lot, which is why I put backup details on the requirements sheet in my Start Here page before comparing any plans.

What to Check in Your Host’s Backup Policy

Before you rely on host backups, find the answers to these questions in the host’s documentation or by asking support:

How often do backups run? Daily is common. Some cheaper plans only run weekly or charge extra.
How many days are kept? 7, 14 and 30 days are all common retention windows.
Are files and the database both included?
Can you restore it yourself with 1 click, or do you need to open a ticket?
Is there a restore fee?
Are backups stored on a different server or data center than your site?
Can you download a full backup archive to your own computer?

This is where shared hosting and managed WordPress hosting often differ. I break that down in my comparison of managed WordPress vs shared hosting, and backups are 1 of the biggest practical differences.

The Pros and Cons of Host Backups

The upside is simple. Host backups run at the server level, they do not slow down WordPress, and they usually work even when your site is broken and you cannot log in to wp-admin.

The downside is control. The schedule, retention and storage location are set by the host. And watch out on budget plans. Some of the low intro prices you see in cheap WordPress hosting deals leave daily backups out or sell them as a paid add-on, so check what you actually get at renewal.

My rule: use host backups as your first layer and your fastest restore option, but never as your only layer.

Method 2: WordPress Backup Plugins

A backup plugin runs inside WordPress, zips your files, exports your database, and sends the result to a remote destination on a schedule. For most site owners this is the easiest way to get a proper off-site copy.

What a Good Backup Plugin Should Do

Look for these features when you compare options:

Scheduled backups of both files and the database, with separate schedules if possible
Remote storage destinations like Amazon S3, Google Drive, Dropbox, Backblaze or SFTP
A retention setting so old backups are deleted automatically
Restore from the dashboard, plus a way to restore when wp-admin is down
Incremental or real-time backups if you run a busy store
Encryption for database backups

Free versions differ more than you might think. For example, the free UpdraftPlus plugin already supports remote destinations like Dropbox, Google Drive and Amazon S3, while Duplicator Lite keeps scheduled backups and most cloud destinations for its Pro version. I compare the main options, prices and free tiers in my roundup of the best WordPress backup plugins.

Plugin Backups vs SaaS Backups

There are really 2 styles. Classic plugins like UpdraftPlus, BackWPup and WPvivid do the work on your own server and push the archive to cloud storage you own.

Services like Jetpack VaultPress Backup and BlogVault run most of the work on their own infrastructure and store the backups in their cloud. That takes load off your server and usually makes restores easier, but you pay a subscription and the backups live in their account rather than yours.

For a big site on cheap shared hosting, the SaaS style is often easier on the server. For a small blog, a classic plugin with free cloud storage is usually plenty.

Method 3: Manual Backup With SFTP and a Database Export

Even if you use a plugin, I think every site owner should do 1 manual backup at least once. It teaches you what is actually in a backup, and it is the method that still works when every plugin is broken.

Step 1: Download Your Files Over SFTP

Connect to your server with an SFTP client like FileZilla or WinSCP, using the SFTP credentials from your hosting dashboard. Use SFTP rather than plain FTP so your password is encrypted in transit.

Open your WordPress root folder. It is often called public_html or www. Download the whole folder to your computer. If the site is large, at minimum grab wp-content and wp-config.php.

If your host gives you a file manager in cPanel or a custom panel, you can also compress the folder into a zip on the server first and download 1 file. That is a lot faster than pulling 20,000 tiny files individually.

Step 2: Export the Database With phpMyAdmin

Log in to your hosting control panel and open phpMyAdmin. Select the database your site uses. If you are not sure which database it is, open wp-config.php and look at the DB_NAME line.

Click Export, choose the Quick method and the SQL format, and download the file. For most small and medium sites this works fine. Very large databases can time out in the browser, and that is where WP-CLI or a host backup becomes a better choice.

Step 3: Label and Store the Set

Put the file archive and the .sql export in 1 folder named with the site and the date, something like mysite-2026-11-03. Zip it, then upload a copy to your cloud storage and keep a copy locally. That is your 3-2-1 set in about 20 minutes.

Method 4: WP-CLI Backups for Developers and VPS Users

If you have SSH access, WP-CLI is the fastest and cleanest way to back up a WordPress database. It is the official command line tool for WordPress, and most managed WordPress hosts and VPS setups support it.

Exporting the Database With WP-CLI

The core command is wp db export. According to the WP-CLI db export documentation, it runs mysqldump using the credentials already stored in wp-config.php, so you do not need to type your database password.

A few useful patterns from the docs:

wp db export backup.sql writes the whole database to a file called backup.sql.
wp db export with no file name creates a file named after the database, the date and a random hash.
wp db export --exclude_tables=wp_options,wp_users skips specific tables.
Using a hyphen in place of the file name writes the dump to standard output, so you can pipe it straight into gzip.

Pair that with a file archive, for example tar -czf files.tar.gz wp-content, and you have a complete backup from 2 commands.

Restoring With WP-CLI

The reverse is wp db import, which loads a .sql file back into the database defined in wp-config.php. If you restore to a new domain or a staging URL, follow it with wp search-replace to swap the old URL for the new URL.

Automating It With Cron

On a VPS you can put those commands in a shell script, run it from cron every night, and push the result to S3 or Backblaze with a sync tool. That is basically what many backup plugins do, just without the dashboard.

I only recommend this route if you are comfortable on the command line. If a typo in a script would scare you, stick with a plugin or your host’s tools.

Where to Store Off-Site Backups

Off-site storage is the part of 3-2-1 that actually saves you in a disaster. Here are the common choices and how I think about them.

Storage option	Best for	Watch out for
Amazon S3 or S3-compatible (Backblaze B2, Wasabi, DigitalOcean Spaces)	Stores, larger sites, anyone who wants cheap scalable storage	Billing setup and access keys take some care
Google Drive	Small sites and bloggers who already pay for Google storage	Shared quota with your email and documents
Dropbox	Small sites, easy setup in most plugins	Storage limits on free accounts
Backup service cloud (Jetpack VaultPress Backup, BlogVault)	Hands-off owners, WooCommerce stores	Backups live in the vendor’s account, tied to your subscription
Local computer or external drive	Your third copy, offline protection	Easy to forget, refresh it on a schedule

Security Tips for Off-Site Storage

Create a dedicated storage account or bucket just for backups. Use a strong unique password and turn on 2-factor authentication.

If you use S3-style storage, create access keys that can only write to that 1 bucket. That way a hacked WordPress site cannot reach into the rest of your cloud account. And keep at least 1 copy offline or in a separate account, which is exactly what CISA recommends for ransomware protection.

How Often to Back Up: Blog vs Online Store

The right backup frequency comes down to 1 question: how much work can you afford to lose? The WordPress handbook suggests roughly weekly for small sites with few posts, daily for high-activity sites, and a fresh backup before every upgrade or move.

Here is how I set it up by site type:

Site type	Database backups	File backups	Retention
Personal blog, 1 to 4 posts a month	Weekly, plus before updates	Weekly or monthly	At least 30 days
Business brochure site	Daily	Weekly	30 days
Active blog or membership site	Daily	Daily	30 to 90 days
WooCommerce or other online store	Real-time or hourly	Daily	90 days or more

Blogs and Brochure Sites

If you publish a couple of posts a month, a weekly database backup plus a backup before every plugin or theme update is usually enough. The uploads folder only changes when you add media, so weekly or even monthly file backups are fine.

The key habit is the pre-update backup. Most of the broken sites I have seen over the years broke right after an update, not randomly.

Online Stores

Stores are different because the database changes every time someone places an order. A daily backup on a store doing 30 orders a day means you could lose up to 30 orders worth of data if you restore the wrong way.

That is why stores need real-time or hourly database backups, and why I treat backup frequency as a hosting requirement in my guide to the best WooCommerce hosting. More on the order problem in a minute.

Backup Retention: How Long to Keep Old Copies

Retention is how far back you can go. It matters more than people think, because many problems are not noticed right away.

Malware can sit quietly on a site for weeks. A plugin update might corrupt some data that nobody notices until a customer complains. If you only keep 3 days of backups, every copy you have might already be infected or broken.

My Retention Baseline

The WordPress handbook recommends keeping at least 3 to 5 recent backups. I think that is the minimum. My baseline looks like this:

Keep daily backups for at least 14 to 30 days.
Keep 1 weekly backup for 2 to 3 months.
Keep 1 monthly backup for 6 to 12 months, especially for stores.
Keep a permanent copy from right before any major change, like a redesign, a host move or a big WooCommerce update.

Most good plugins and services let you set retention rules, so you do not have to delete old archives by hand. Just watch your storage bill if you keep long histories of a big uploads folder.

How to Restore a WordPress Backup

Restoring is the whole point of backing up, so let’s talk about how it actually works with each method.

Restoring From Your Host

This is usually the fastest option. Log in to your hosting dashboard, open the backups section, pick a date, and choose whether to restore files, the database or both. Many hosts let you restore just the database, which is handy when content broke but files are fine.

Restoring From a Plugin

If wp-admin still works, open the plugin, pick the backup and click restore. Most plugins let you choose which parts to restore: database, plugins, themes, uploads or others.

If the site is completely down, you have 2 choices. Install a fresh copy of WordPress, install the same plugin, connect it to your cloud storage, and restore from there. Or use a standalone restore tool if your plugin includes 1. Check this before you need it.

Restoring Manually

For a manual restore, upload your files back to the server over SFTP, then import the .sql file through phpMyAdmin or wp db import. Make sure wp-config.php has the right database name, user and password for the database you imported into.

If you are restoring to a new server, that is basically a migration. My guide to migrating a WordPress site to a new host covers DNS, URL changes and testing step by step.

Test Your Restore on a Staging Site

Here is the habit that separates people who have backups from people who can actually recover. Test a restore on a staging site, on a schedule, before you ever need it.

Why Restore Testing Matters

Backups fail quietly all the time. The archive is incomplete because the job timed out. The cloud token expired 3 months ago. The database export is empty. You will not know until you try to restore, and the worst possible moment to find out is during an emergency.

CISA calls out regular restore testing, both full and partial, as part of a real backup plan. I agree completely.

How to Run a Test Restore

Create a staging site. Many managed WordPress hosts include 1-click staging. Otherwise use a subdomain like staging.yoursite.com with its own database.
Block search engines on the staging site so it does not get indexed.
Restore your latest backup to staging using your normal method.
Run a search-replace for the URL if your tool does not handle it automatically.
Click through the home page, a few posts, the contact form, and for stores, the cart and a test checkout in sandbox mode.
Log in to wp-admin and confirm plugins, users and settings came across.
Write down how long it took and anything that broke.

I do this at least once a quarter for sites that matter, and after any change to the backup setup. If you pick a host with built-in staging, this gets a lot easier. That is 1 reason staging shows up as a requirement in my guide to the best WordPress hosting.

WooCommerce Backups: The Order Data Problem

This is the section store owners should read twice. Restoring a WooCommerce backup is not like restoring a blog.

Why a Full Restore Can Wipe Recent Orders

When you restore a database backup, you replace the whole database with the version from the backup time. Every order, customer account, stock change and review created after that moment is gone from WordPress.

Say your daily backup ran at 2am. At 3pm an update breaks your checkout and you roll back to the 2am backup. Every order from 2am to 3pm disappears from your dashboard. The payments still happened in Stripe or PayPal, but your store no longer knows about them, which means unshipped orders and confused customers.

How to Protect Order Data

WooCommerce’s own guide on how to back up and restore a WooCommerce store recommends real-time backups so recent orders are captured as they happen. If you only have daily backups, the same guide suggests pausing orders and product edits, taking an on-demand backup, making your change, and restoring if something breaks.

Here is my practical checklist for stores:

Use a real-time or hourly backup solution for the database.
Take a manual on-demand backup right before every update.
Do updates on staging first, then push to live.
Run big updates during your slowest hours, not during a sale.
If you must roll back, export recent orders first, or pull them from your payment processor, so you can rebuild them.
Prefer restoring files only (plugins and themes) when the problem is a broken plugin, so the database and orders stay untouched.

That last point matters a lot. If a plugin update broke the site, you often only need to roll back that plugin’s folder, not the whole database.

A Simple WordPress Backup Plan You Can Copy

If you want a plan you can set up this afternoon, here is what I would do for most sites:

Confirm your host runs daily backups with at least 14 days of retention, and learn how its restore button works.
Install a backup plugin or service and send backups to a separate cloud storage account with 2-factor authentication.
Schedule database backups daily (real-time or hourly for stores) and file backups weekly or daily.
Set retention to at least 30 days, plus monthly copies for longer history.
Download a full backup to your computer once a month.
Take a manual backup before every update, redesign or host move.
Test a restore on staging every quarter.

That covers the 3-2-1 rule, it covers updates, and it gives you proof that your backups actually work.

Frequently Asked Questions

How do I backup my WordPress site for free?

You can use your host’s included backups plus a free plugin like UpdraftPlus that sends copies to Google Drive, Dropbox or Amazon S3. You can also do a manual backup by downloading your files over SFTP and exporting the database in phpMyAdmin. All of these cost nothing beyond your hosting and storage.

Do I need to back up the database and files separately?

They are stored separately, so they need to be backed up separately, but you should keep them together as 1 matched set. Most plugins and host tools grab both in 1 job. With a manual backup, you download the files and export the database as 2 steps.

How often should I back up my WordPress site?

For a small blog, weekly plus a backup before every update is usually fine. Active sites should back up daily. WooCommerce stores should use real-time or hourly database backups because orders change the database all day.

Are my web host’s backups enough?

They are a good first layer, but I would not rely on them alone. If the backups live in the same account as your site, a suspended account or a hacked control panel can take them out too. Keep at least 1 copy off-site in an account you control.

Where should I store WordPress backups?

Store at least 1 copy in cloud storage outside your host, like Amazon S3, Backblaze B2, Google Drive or Dropbox, and keep another copy on your own computer or an external drive. Never keep your only backups in the same server folder as the live site.

Will restoring a backup delete my WooCommerce orders?

A full database restore replaces everything with the backup’s version, so any orders placed after that backup are removed from WordPress. Use real-time backups, restore only files when you can, and export recent orders before any database rollback.

Your Next Step

Backups are boring until the day they save your business. The good news is that a solid setup takes about an hour: host backups as layer 1, an off-site plugin or service as layer 2, a local copy as layer 3, and a quarterly restore test to prove it all works.

If you are still choosing a host, write down your backup requirements first using the Web Hosting Paradise Start Here page, then compare hosts against that list. If you already have a host and want to speed things up while you are in there, read my guide on how to speed up a WordPress site next.

Trevor Fenner

Trevor Fenner publishes Hosting Paradise and Ecommerce Paradise. His guides cover web hosting, website migration, backups, and software for online businesses.