The Backup You Never Tested Is a Coin Flip: A WordPress Backup Strategy Guide

Most people find out their WordPress backups don’t work at the exact moment they need them. A plugin update takes the site white, or a host migration corrupts the database, and the “backup” turns out to be a half-finished zip from four months ago that won’t import. By then it’s too late to fix the process.

A backup isn’t a file you have. It’s a restore you’ve actually done. Until you’ve watched your site come back from a backup on a clean install, you don’t have a backup — you have a hopeful guess sitting on a disk.

This guide walks through what a real WordPress backup includes, where to keep it, how to automate it, and the one step almost everyone skips: proving the thing restores before you need it to.

What a WordPress Backup Actually Has to Contain

A WordPress site is two very different things stitched together, and a backup that grabs only one of them is useless. There’s the database — every post, page, comment, user, setting, and most plugin configuration lives in MySQL tables. And there’s the filesystem — WordPress core, your themes, your plugins, and everything you’ve ever uploaded.

Miss the database and you restore an empty shell with no content. Miss the files and your posts point at images that no longer exist and plugins that aren’t installed. You need both, captured close enough together in time that they agree with each other.

The database

Your content and configuration sit in tables like wp_posts, wp_options, and wp_users. A database backup is a SQL dump — a text file of the commands needed to rebuild those tables. With WP-CLI it’s one line:

wp db export backup.sql

That runs mysqldump under the hood and writes a portable .sql file you can import anywhere with wp db import backup.sql.

The files

The part worth protecting most carefully is wp-content — it holds your uploads, active theme, and plugins. Core WordPress files you can always re-download from wordpress.org, but your uploads and any custom theme code are irreplaceable. Don’t forget wp-config.php either; it lives in the site root, not in wp-content, and it holds your database credentials and security keys.

The 3-2-1 Rule, Applied to WordPress

The most durable backup guideline predates WordPress by decades, and CISA still points to it: keep three copies of your data, on two different types of storage, with one copy kept offsite. It’s simple on purpose, because the failures it defends against are boring and common.

Here’s what that looks like for a WordPress site. Your live site is copy one. A scheduled backup stored on the same server is copy two — convenient, but worthless if the whole server dies or gets compromised. So copy three goes somewhere completely separate: an S3 bucket, Backblaze B2, Google Drive, a Dropbox folder, anywhere that isn’t the machine hosting your site.

The offsite copy is the one that saves you in the scenarios that actually happen. When a server’s disk fails or a host account gets suspended, a backup living on that same server disappears right along with it. Ransomware and webshells are worse: an attacker who owns your server owns any backup sitting next to the site. Offsite and, ideally, versioned storage is what keeps a bad day from becoming a permanent one.

Three Ways to Actually Make the Backups

Manual, with WP-CLI

If you have SSH access, WP-CLI is the fastest honest backup you can take. Two commands capture the database and the entire site tree:

wp db export backup.sql
tar -czf files.tar.gz wp-content wp-config.php

Copy both files off the server and you have a complete, restorable snapshot. This is perfect right before a risky update — take it, do the update, and if things break you’re one wp db import away from where you started.

A backup plugin

For most site owners, a scheduled plugin is the practical answer. Tools like UpdraftPlus, BackWPup, and the open-source WP-CLI-friendly options can run on a schedule, split large sites into chunks, and push copies straight to remote storage. Look for three things when you pick one: it backs up both database and files, it supports a real offsite destination, and it can restore — not just create — without you touching a terminal.

Host-level and server snapshots

Many managed hosts take daily or on-demand snapshots of your whole account, and DigitalOcean, AWS, and similar providers can snapshot an entire droplet or volume. These are excellent as a safety net, but treat them as a supplement rather than your only plan. You don’t always control retention, restores can be all-or-nothing at the server level, and if you ever move hosts, a proprietary snapshot doesn’t come with you. Owning at least one portable copy keeps you independent of any single provider.

Automating It So You Don’t Have to Remember

A backup you have to remember to run is a backup you’ll eventually forget. Automation is what turns good intentions into an actual safety net, and there are two common ways to schedule it.

The first is WordPress’s own scheduler, WP-Cron, which is what most backup plugins use. It’s easy and needs no server access, but it has a catch worth knowing: WP-Cron only fires when someone visits your site. A low-traffic site can quietly miss its scheduled backup for hours simply because nobody stopped by. For a site that matters, the sturdier approach is a real system cron job calling wp-cron.php on a fixed schedule, so timing never depends on traffic.

The second is calling WP-CLI directly from a server cron entry — a short script that runs wp db export, archives wp-content, and syncs the result to remote storage every night. It’s the most reliable option if you’re comfortable on the command line, because nothing about it depends on WordPress being loaded by a browser.

Whichever you choose, set a retention window. Keeping the last 7 to 30 daily backups plus a few monthly ones protects you against the sneaky failure mode where a problem — a slow database corruption, a quiet hack — is faithfully backed up every night until your only copies are all broken. Older, known-good snapshots are your escape hatch.

The Test Restore Everyone Skips

This is the step that separates people who have backups from people who think they do. A backup you have never restored is a hope, not a plan. The failure modes are quiet: a database export that silently truncated on a large table, a file archive missing a directory because of a permissions error, a remote upload that’s been failing for weeks while the dashboard cheerfully reported success.

The only way to know is to try. Every quarter or so, spin up a throwaway environment — a local install, a staging subdomain, a temporary droplet — and restore your latest backup into it from scratch. Import the database, unpack the files, load the site, click around. When the last cleanup we did came back from a bad plugin update that had white-screened a client’s site, the restore itself took ten minutes; the reason it was ten minutes and not a lost weekend was that the backup had been tested and we already knew the exact steps.

Pair the test restore with monitoring. Have your backup job email or ping you on both success and failure, and actually read those notifications. Silent success is indistinguishable from silent failure until the day you go looking for a file that was never there.

Frequently Asked Questions

The best time to set up real backups was before your last update. The second-best time is now — pick a tool, automate it offsite, and test a restore this week.

Built by amplifi.studio — see also how to set up a WordPress staging site.