WordPress backup strategy: what to back up and how often

Most WordPress site owners think they have backups. They usually do not. They have a hosting panel option they clicked once, a plugin they installed and forgot about, or a folder on the same server the site runs on. None of those are a backup strategy. A backup strategy answers four questions in order: what to back up, how often to back it up, where to put it, and how to prove it still works when everything else is on fire. This article walks through all four and gives you a configuration you can run today.

The framing matters because the stakes compound. Automatic update rollback landed in WordPress 6.6 in July 2024 for plugin auto-updates that hit PHP fatal errors, and WordPress 6.3 added rollback for failed manual plugin and theme updates back in August 2023. Those safety nets catch a specific class of "update broke the site" failures. They do nothing for deleted content, ransomware, a hacked admin account, or a host that goes dark for three days. Only a backup you can restore from does.

In short

If you only remember five things from this article, remember these:

1. A backup is database plus files. Neither alone is enough. The database holds posts, pages, comments, settings, and users. The files hold uploads, themes, plugins, wp-config.php, and .htaccess. Restoring one without the other gives you a broken site.
2. Frequency follows content velocity. A brochure site with monthly edits is fine on weekly backups. A blog that posts daily needs daily backups. WooCommerce and multi-author publishers need hourly or every-four-hours backups because each transaction or post is unique data you cannot reconstruct.
3. At least one copy lives off your web host. On-server backups die with the server they sit on. The 3-2-1 rule is three copies, two storage types, one offsite.
4. Host backups are a useful layer, not a strategy. They help, but they are operated by someone else, on the same infrastructure as your site, with retention and granularity you may not control.
5. A backup you have never restored is not a backup. Run a restore drill to a staging environment at least once before you need one for real.

The rest of this article is the reasoning and the exact configuration that implements each of those.

Table of contents

• What a WordPress backup consists of
• Why hosting-provided backups are not enough
• How often to back up
• Where to store backups: the 3-2-1 rule
• Choosing a backup plugin
• Configuring UpdraftPlus for a 3-2-1 setup
• Backing up from the command line
• Testing your backup by restoring it
• The minimum floor: back up before every update
• Common myths worth burning

What a WordPress backup consists of

A WordPress site is two things living in two places, and a real backup copies both. The official WordPress backup guide is explicit about this: you need the database and the files, and neither alone is enough.

The database is a MySQL or MariaDB database accessible through the credentials in wp-config.php. It contains every post and page you have written, every comment, every user account and hashed password, the contents of wp_options (which is where almost every plugin stores its configuration), Customizer settings, menu structures, widget data, and for WooCommerce sites, every order, customer, product attribute, and stock level. When people say "I lost three years of blog posts", the thing they lost was the database. A database dump is typically a single .sql or .sql.gz file ranging from a few megabytes to a few hundred.

The files are the PHP, CSS, JavaScript, images, and configuration that live in the WordPress directory on disk. At minimum a real file backup covers:

• wp-content/uploads/: every image, PDF, video thumbnail, and media attachment a user has ever uploaded. This is usually the biggest single directory and the one that cannot be recreated from anywhere else.
• wp-content/themes/: your active theme, child theme, and any customizations made outside the Customizer. If you paid a developer to build a custom theme, this directory is your investment.
• wp-content/plugins/: all plugins, including commercial ones. Free plugins can be reinstalled from wordpress.org, but commercial plugins require a license lookup and sometimes a support ticket. Back them up.
• wp-content/mu-plugins/: must-use plugins load automatically and are a common place for host-specific hooks and custom drop-ins. If yours has anything in it, you need it.
• wp-config.php: database credentials, secret keys, and environment constants. Back it up, but store the backup encrypted or outside the web root because it contains secrets.
• .htaccess: on Apache hosts, this is where custom rewrite rules, security headers, and redirect blocks live. Easy to forget; annoying to recreate.
• robots.txt and favicon.ico: small, trivial, but if you customized them, include them.

The WordPress database backup guide states the split bluntly: database backups "do NOT back up your WordPress files (themes, plugins, uploads, wp-config.php, etc.)". If you have been running database-only backups, you have been backing up half of your site.

Why hosting-provided backups are not enough

Most managed WordPress hosts do take backups. Shared hosts like Hostinger or SiteGround do. Managed WordPress platforms like WP Engine and Kinsta do. That fact is real and genuinely useful, and this section is not arguing that host backups are worthless. It is arguing that they are a layer, not a strategy, and you should not treat them as your primary plan.

Three things go wrong when host backups are the only backups.

They live on the same infrastructure as your site. A host-level backup is typically a server snapshot or a block-level image stored on the same provider, sometimes the same data center, occasionally the same physical machine. When the failure mode is hardware loss, a ransomware infection that encrypted the host account, or the provider going out of business, the backup is lost with the site. The UpdraftPlus vendor explains the math at length in their off-site backup post, and the conclusion holds regardless of which plugin you use: single-provider redundancy is not redundancy.

Retention and granularity are not yours to decide. Hosts typically keep 7 to 30 days of backups, sometimes only the last 3 on cheaper plans. If you discover a compromise or a silent data corruption 40 days after it happened (which is common, because attackers try to stay quiet), the clean version is gone. Host backups are also often full-site snapshots rather than per-table or per-file restores, so recovering a single accidentally-deleted page means rolling the whole site back and losing everything that happened since. Recovering a single product in a WooCommerce catalog without losing new orders is often impossible through the host panel.

You depend on the host's interface and their support desk. Some hosts let you click "restore" in a dashboard. Others require a support ticket, a wait, and a fee. During an incident, the time spent negotiating with a support queue is time your site is down and you cannot touch. That is the worst possible moment to discover your recovery depends on someone else's response time.

The WordPress backup documentation is mild about this but unambiguous: automated backups should be supplemented with manual backups "to guarantee that the process is working". Translation: you need your own, off-host, under-your-control backup. Use host backups as the fast path for "the site broke during an update, restore me to an hour ago"; use your own backups for everything else.

How often to back up

The correct frequency is the rate at which your site changes. The right way to think about it is to ask yourself: if the site broke right now, how much new content am I willing to recreate by hand? Whatever answer you give is your maximum backup interval. The WordPress docs give the general shape; below are the categories that cover most real sites.

Two details matter here. First, files and database can be scheduled independently. A WooCommerce store's uploads directory changes slowly (new product photos), but the database changes constantly (new orders). UpdraftPlus exposes this split natively: file backups on one schedule, database backups on another, because treating them as one unit wastes bandwidth on slow-changing data.

Second, the "backup before every update" rule is non-negotiable and sits on top of whatever recurring schedule you choose. The WordPress upgrade guide lists "Backup your database" and "Backup ALL your WordPress files in your WordPress directory" as required steps before an upgrade. It is blunt about what happens when you skip them: "without a backup of your entire site and your database, made prior to your upgrade attempt, a successful rollback is near impossible." A nightly backup from 22 hours ago is not close enough if you are about to touch a plugin that runs on every request.

Where to store backups: the 3-2-1 rule

The 3-2-1 rule is the oldest, most quoted, and most ignored principle in backup design. It says: three copies of your data, on two different types of storage, with at least one copy offsite. Applied to WordPress specifically, it looks like this:

• Copy 1: the live site itself.
• Copy 2: a recent backup in a different location than the live site. "Different location" does not mean "a different folder on the same server". It means a different provider, a different account, or a different physical infrastructure. Google Drive, Dropbox, Amazon S3, Backblaze B2, or a separate server you control all qualify. A folder at wp-content/backups/ does not.
• Copy 3: an older backup, farther away. A local download on your laptop, an encrypted external drive, or a second cloud provider. This is the copy that survives "my cloud storage account got hijacked" and "my only provider had a billing dispute".

The UpdraftPlus vendor writes about this rule at length in their 3-2-1 backup post, and they apply it to their own product. The practical implication for WordPress is straightforward: pick one cloud storage destination that your backup plugin pushes to automatically, and once a month download a copy of the latest backup to your own device. Five minutes of friction every month buys you a recovery path that survives anything short of a fire.

Do not store the copy that lives offsite unencrypted if it contains user data. A WordPress backup includes hashed passwords, email addresses, IP addresses of commenters, and for WooCommerce sites, billing addresses and order histories. That is personal data under GDPR. UpdraftPlus, BackWPup, and BackupBuddy all offer backup encryption; turn it on, store the key in a password manager, and write the key down somewhere that is not the password manager in case you lose access to the manager itself.

Choosing a backup plugin

Three plugins dominate the WordPress backup space and they each make different tradeoffs. Here is the honest comparison.

UpdraftPlus is the most-installed backup plugin on the WordPress.org directory with three million active installs. The free tier supports Dropbox, Google Drive, Amazon S3 and compatible, Rackspace Cloud, FTP, DreamObjects, OpenStack Swift, and email as backup destinations. Free schedule options cover every 2, 4, 8, or 12 hours, daily, weekly, fortnightly, and monthly, with independent schedules for files and database. Restore is component-selective, meaning you can restore only the plugins directory, only the database, or only the uploads folder. The paid version adds Microsoft OneDrive, Azure, Google Cloud, Backblaze B2, SFTP, SCP, pCloud, WebDAV, plus incremental backups, pre-update automatic backups, multi-destination simultaneous backup, and backup encryption. The current stable version as of April 2026 is 1.26.2, and the plugin has been continuously maintained since 2011.

BackWPup is the second-most-common free option and is more comfortable for users who already know Dropbox, S3, FTP, and SugarSync by name and want a spartan interface that exposes more technical settings. It is less polished than UpdraftPlus and the free tier has fewer "it just works" guardrails, but it is completely free and has no feature gating on the core backup flow.

Duplicator is the pick if your primary use case is cloning or migrating a site rather than recurring backups. It packages the entire site into a single installer archive that drops into a new host and reconstructs itself. For pure recurring backups, UpdraftPlus or BackWPup is a better fit; for "I need to move this site to a new host this weekend", Duplicator is the one to reach for.

My default recommendation for almost every site is UpdraftPlus on the free tier, with Google Drive or Dropbox as the cloud destination for small sites, and S3 or Backblaze B2 for larger sites where the file count or storage cost makes Google Drive impractical. The reason is pragmatic: UpdraftPlus has the largest install base, which means the most community troubleshooting, the most tested restore paths, and the highest odds that whoever helps you during an incident has seen it before.

One detail to be accurate about. UpdraftPlus versions 1.24.x and 2.24.x (mid-2024) updated their Google Drive integration to comply with Google's Granular Consent requirement, which took effect on June 17, 2024. The update adds scope-level permission checks during authorization and prevents a PHP deprecation warning after Google Drive auth. It is not a new OAuth2 system; UpdraftPlus has used OAuth2 via a registered Google app since version 1.13.6 in September 2017. If you re-authenticate Google Drive after upgrading UpdraftPlus to 1.24 or later, you may see a revised Google consent screen. That is expected and not a problem.

Configuring UpdraftPlus for a 3-2-1 setup

Here is the exact configuration for a site with daily backups and a Google Drive offsite destination. Adapt the schedule to your content velocity from the table above.

Prerequisites:

• WordPress 6.0 or newer (UpdraftPlus 1.26.x requires WordPress 5.6 minimum, but 6.0+ gives you the current feature set).
• PHP 7.4 or newer (UpdraftPlus 1.26.x does not support older PHP).
• A Google account with at least a few gigabytes of free Drive storage, or an alternative destination if you prefer.
• FTP/SFTP or file manager access to your site, in case the plugin page itself is unreachable during recovery.
• Administrator access to the WordPress dashboard.

Steps:

1. In the WordPress dashboard, go to Plugins > Add New, search for UpdraftPlus, and install the plugin authored by UpdraftPlus.Com, DavidAnderson. Activate it.
2. Go to Settings > UpdraftPlus Backups. Click the Settings tab.
3. Set the Files backup schedule to Daily and Retain this many scheduled backups to 14. This keeps two weeks of file backups, which is the minimum sensible retention for content sites.
4. Set the Database backup schedule to Daily and Retain this many scheduled backups to 30. Database backups are small enough that a month of retention is cheap, and the extra history helps with discovering silent corruption late.
5. Under Choose your remote storage, select Google Drive. A Google Drive authentication link will appear further down the page after you click Save Changes.
6. Leave all file-type checkboxes checked under Include in files backup: Plugins, Themes, Uploads, and Others under wp-content. Do not exclude Others unless you know exactly what is in there and have a reason.
7. Scroll to the bottom of the page and click Save Changes.
8. At the top of the Settings tab, Google Drive will now show a yellow warning asking you to authenticate. Click the link, complete the Google OAuth flow, grant UpdraftPlus access to its own application folder (not your whole Drive), and confirm the redirect back to your WordPress site.
9. Return to the Current Status tab and click Backup Now. In the dialog, tick both Include the database in the backup and Include any files in the backup, and confirm. The first backup may take several minutes depending on site size.
10. When the backup finishes, scroll to the Existing Backups section. You should see one entry with Database, Plugins, Themes, Uploads, and Others columns, each with a green tick and a download link. Click the refresh icon next to Google Drive; the backup should show as uploaded to Google Drive.

Expected output: A new folder in your Google Drive called UpdraftPlus containing five files per backup: backup_YYYY-MM-DD-HHMM_sitename_hash-db.gz, and -plugins.zip, -themes.zip, -uploads.zip, -others.zip. If any file is missing, the backup is incomplete and needs to be investigated before you trust it.

Verify the final result: Run Backup Now a second time after the initial backup to confirm the schedule works on demand, then wait 24 hours and verify that a new backup appears automatically. Do not trust the schedule until you have seen it fire at least once.

Backing up from the command line

For developers and anyone running multiple sites, the command-line path is shorter and scriptable. The WP-CLI wp db export command wraps mysqldump using the credentials from wp-config.php, so you do not need to keep a separate MySQL password around.

Prerequisites:

• WP-CLI 2.10 or newer installed on the server (wp --info to check).
• SSH or local shell access to the WordPress root directory.
• A target directory for backups that is outside the web root, so an attacker with write access to WordPress cannot delete them. /home/deploy/backups/ is a common choice on a single-tenant server.

Steps:

1. SSH to the server and cd to the WordPress root (the directory containing wp-config.php).

2. Export the database with a timestamped filename:

   # Export the full database to a gzipped SQL file with today's date.
   # --add-drop-table makes the dump restorable over an existing database.
   wp db export - --add-drop-table | gzip > /home/deploy/backups/db-$(date +%F).sql.gz

3. Archive the WordPress files. wp-content is the only directory that contains data you cannot reinstall from scratch, but including wp-config.php and .htaccess makes a cleaner restore:

   # Tar the full WordPress tree excluding caches and the backup dir itself.
   tar -czf /home/deploy/backups/files-$(date +%F).tar.gz \
     --exclude='wp-content/cache' \
     --exclude='wp-content/uploads/cache' \
     --exclude='.git' \
     wp-content wp-config.php .htaccess 2>/dev/null

4. Push the archives to an offsite destination. If you use Amazon S3, the AWS CLI one-liner is:

   # Upload both backup files to an S3 bucket in the given region.
   # Requires aws configure or IAM role credentials.
   aws s3 cp /home/deploy/backups/db-$(date +%F).sql.gz s3://my-wp-backups/yoursite/
   aws s3 cp /home/deploy/backups/files-$(date +%F).tar.gz s3://my-wp-backups/yoursite/

5. Wrap the full sequence in a shell script and schedule it with cron. A sensible cron line for nightly 02:30 backups is:

   # m h dom mon dow command
   30 2 * * * /home/deploy/scripts/wp-backup.sh >> /home/deploy/logs/wp-backup.log 2>&1

Expected output: The database dump compresses to roughly 10–30 percent of the raw SQL size for typical WordPress content. A site with a 200 MB database produces a 20–60 MB gzipped dump. The file archive varies more because it depends on the uploads directory. Both files, once uploaded to S3, should be visible in the bucket with the expected sizes and today's date. Write the sizes down somewhere for the first week and watch them trend; a sudden drop usually means the backup is broken.

Verify the final result: Run the script once manually and inspect the output. Then wait for the next cron run and check the S3 bucket. Then extract one of the archives to a scratch directory (tar -tzf files-2026-04-08.tar.gz | head and zcat db-2026-04-08.sql.gz | head -50) to prove the archives are not empty and not corrupted.

Testing your backup by restoring it

This is the section most guides skip, and it is the one that separates a backup strategy from a backup habit. A backup you have never restored is a hope, not a control. Restore drills are how you turn a hope into a control.

The drill. Pick a staging environment you can break: a local Docker install, a second WordPress on a test subdomain, a DevKinsta or Local by Flywheel instance, or a scratch VPS. Do not restore to production. Restore to a throwaway environment the first time. Then:

1. Pick your most recent backup from the storage destination.
2. Install a clean WordPress on the staging environment with the same PHP and MySQL versions as production.
3. Restore the database dump first: wp db import db-2026-04-08.sql.gz if you use WP-CLI, or the UpdraftPlus Upload backup files flow followed by Restore if you use the plugin.
4. Restore the files next: extract wp-content/ from the archive into the staging WordPress's wp-content/, or use the UpdraftPlus component restore.
5. Run wp search-replace 'yoursite.nl' 'staging.yoursite.nl' --dry-run and then without --dry-run to update URLs in the database so the restored site works at the staging URL. Do not skip this; serialized PHP in WordPress options breaks if you try to replace URLs with a raw SQL query.
6. Visit the staging site and click through the home page, a blog post, the wp-admin dashboard, and a plugin settings page you recognize. If it looks like production, the backup works. If something is missing, find out what before you need to restore for real.
7. Time how long the whole procedure took. Write the number down. That is your recovery time for this backup strategy. If it is longer than you can tolerate, that is a problem to solve now, not during an incident. If the restore drill involves migrating to a different host or domain, the full procedure is in how to migrate WordPress to a new host.

Run this drill every three months. Sites change, plugins accumulate state in new places, and a drill that worked last quarter is not proof that your backups work today.

The minimum floor: back up before every update

If you do nothing else from this article, do this one thing: take a fresh backup immediately before every plugin, theme, or WordPress core update. Not yesterday's backup. Not the nightly scheduled one. A fresh backup, taken five minutes before the update, so that if the update breaks the site you can restore to the state thirty seconds before the breakage.

The WordPress upgrade guide requires this for major core upgrades and the logic applies to every other update for the same reason: once a plugin has written to the database during its own upgrade routine, there is often no way to undo that without a backup taken before the upgrade ran. Plugin A adds a new column to its table. Plugin B renames an option. A custom theme's functions.php crashes on PHP 8.3 where it worked on 8.2. Any of these can be recovered from with a backup taken five minutes earlier. Without one, you are debugging production.

The UpdraftPlus free version does not do this automatically; it is a paid feature called Backup before update. The workaround on the free tier is to click Backup Now manually before each session where you plan to update things. For sites with more than a handful of plugins, the paid version pays for itself the first time it saves an update.

The WP 6.3 manual rollback feature and the WP 6.6 auto-update rollback do catch the specific subset of updates that trigger PHP fatal errors during the update itself. They do not catch updates that succeed, install cleanly, and then break something two days later. They do not catch updates that change database schemas in ways that break a later plugin. A backup does, and that is the control you want.

Common myths worth burning

A short list of widespread beliefs that do not hold up, and why.

"My host has backups so I'm covered." Your host has a layer, not a strategy. You cannot control retention, you cannot choose granularity, and you cannot restore a single file without a support ticket. The official WordPress docs are explicit that automated backups should be supplemented with manual backups "to guarantee that the process is working". Take yours.

"The database is the only thing that matters." The database holds your content, but if you restore it into a WordPress without your uploads, every image on every post is broken. If you restore it without your active theme, the site looks nothing like it used to. If you restore it without your plugins, half the custom blocks render as placeholder boxes. Files and database are one backup, not two priorities.

"Backups in wp-content/backups/ are fine because the site is reliable." They are fine until the day they are not. Any compromise that gives an attacker write access to wp-content/ gives the attacker the ability to delete your backups. Any host failure that loses the server loses the backups with it. The rule is simple: backups live somewhere the site cannot reach, and the site lives somewhere the backups cannot reach.

"WordPress 6.6 added rollback, so I don't need backups anymore." WordPress 6.6 added rollback for plugin auto-updates that fail with a PHP fatal error during installation. That is a small, specific safety net. It does not roll back a successful update that later turns out to break something. It does not restore deleted content. It does not help after a compromise. A backup does all three.

"I back up once a month, that's enough for a small site." It is enough if you can comfortably recreate a month of work by hand. For most sites, even ones with slow editorial velocity, a month of lost comments, plugin setting changes, user registrations, and tiny content edits adds up to more work than the writer of the backup schedule imagined. Daily for active sites, weekly for static sites, and always before an update.

Where to go next

Now that you have a backup strategy, the natural next questions are about the recovery path and the broader security posture. Start with WordPress security hardening, which covers file permissions, 2FA, wp-config.php constants, and the other controls that make a backup less likely to be needed in the first place. If the reason you are reading this article is that an update already broke your site, the recovery path is in the critical error on this website and white screen of death in WordPress articles, both of which assume you have a backup to fall back on. If you are recovering from a compromise rather than a code error, the WordPress hacked / malware redirect cleanup article walks through the full incident response, where a clean pre-compromise backup makes the difference between a quick restore and a manual cleanup.