Backups and Disaster Recovery

The official backup guide splits the job into the database (content, users, settings) and the files (core, themes, plugins, uploads, wp-config.php, .htaccess). Neither half is useful without the other: uploads without the database have no posts pointing at them, and a database without wp-content references themes, plugins and images that are gone.

Some paths under wp-content are regenerable or temporary and only make backups larger and slower:

A complete disaster recovery also needs what is outside the WordPress directory: the web server and PHP configuration, TLS certificates (or the means to reissue them), system cron entries such as the one that replaces WP-Cron, DNS records and the credentials for the off-site storage. Keeping those in configuration management or infrastructure-as-code is cheaper than backing them up by hand. A WXR export from Tools > Export is not a backup either: it omits settings, password hashes, themes, plugins and media files; see Importing, Exporting and Migrating.

Two numbers turn "regular backups" into a plan:

The official guide suggests weekly backups for small, quiet sites, daily backups for busy ones, a backup before every upgrade or move, and keeping at least three to five recent backups in several places. Frequency should follow the RPO and the part that changes: for Lumen Press the database changes all day and is small, the uploads change a few times a day and are large, and code changes only through deployments.

The 3-2-1 rule is a useful minimum: three copies of the data, on two different kinds of storage, one of them off-site (another provider or region, with separate credentials). The target RTO for Lumen Press is one hour; the restore test later on this page shows how much of that the restore itself consumes.

The files part is wp-content, wp-config.php and .htaccess. Core is better downloaded again at the recorded version, which also guarantees that the restored core is unmodified. A compressed tar archive keeps owners, permissions and timestamps and can exclude the regenerable paths listed earlier:

Source: Advanced Administration: Backing Up Your WordPress Files

On the test site the uploads directory held 82 MB of JPEG files plus a 29 MB page cache. The archive was 17.5 MB and contained 866 entries, none of them under wp-content/cache/ and no debug.log. Already-compressed media (JPEG, WebP, AVIF, MP4) barely shrink, so for sites with tens of gigabytes of uploads an incremental copy (rsync to a backup host, or an object-storage sync with versioning) is far cheaper than a nightly full archive, and the archive then covers only code, configuration and drop-ins. FTP/SFTP downloads and sync tools such as WinSCP, which the official guide also lists, work for small sites but are manual.

The script below is what the Lumen Press server runs every night. It exports the database first (as the official guide recommends), archives the files, records what is needed to rebuild the site, writes and immediately verifies SHA-256 checksums, tests the gzip stream, and deletes local backup directories older than the retention period. Archives are created with umask 077 because they contain wp-config.php and personal data. It needs WP-CLI, GNU tar, gzip, sha256sum and find, and runs as the user that owns the site files.

Source: Advanced Administration: Backing Up Your WordPress Site, WP-CLI: wp db export, WP-CLI: wp core version

A run on the test site took about 5 to 11 seconds and printed:

Source: Advanced Administration: Backing Up Your WordPress Site

set -o pipefail is essential: without it a failed wp db export piped into gzip still exits 0 and leaves a valid, empty-looking db.sql.gz. The retention step was checked by adding a directory dated 2026-10-01; the next run with RETAIN_DAYS=14 removed it and kept the two runs from 2026-10-28. Retention on the local disk only bounds disk usage: the long-term copies (monthly, yearly) belong in the off-site store, with its own lifecycle rules.

Schedule the script with the system cron, not with WP-Cron. WP-Cron only runs when someone visits the site, so on a quiet night a WP-Cron backup can be hours late, and it runs inside a web request with PHP time limits (see WP-Cron and Scheduled Tasks).

Source: Plugin Handbook: Hooking WP-Cron Into the System Task Scheduler

The % signs are escaped because cron treats an unescaped % as a newline. Naming the hourly files by hour (hourly-00 to hourly-23) gives a rolling 24-hour window without a separate clean-up. Monitor both jobs: alert when the newest backup is older than the RPO or when its size drops sharply, which is how a silently failing backup is usually noticed.

A backup on the same server, disk or account as the site does not survive the failures that matter most: a lost server, a deleted hosting account, ransomware or an attacker with the site’s credentials. After each run, copy the backup directory to storage in another provider or region, with credentials that the web server cannot use to delete it.

Source: rclone copy

--immutable makes rclone refuse to modify files that already exist on the remote. On the storage side, enable object versioning or an object lock (write once, read many) with a retention period, so that a compromised server can add backups but not erase them. Further protections:

The official order is: restore the files, then import the database, and update wp-config.php if the database credentials changed. The restore script below does exactly that into an empty web root and an empty database: it refuses a backup whose checksums do not match, downloads the core version recorded in the manifest (the package without default themes and plugins), unpacks wp-content, wp-config.php and .htaccess, points wp-config.php at the replacement database server when NEW_DB_* variables are set, imports the database and runs the post-restore checks.

Source: Advanced Administration: Backing Up Your WordPress Site, WP-CLI: wp core download, WP-CLI: wp db import, WP-CLI: wp core verify-checksums

The core package is downloaded by URL because --skip-content cannot be combined with a URL download (WP-CLI 2.12.0 answers "Skip content and locale options are not available for URL downloads"); the -no-content package is the one WordPress.org builds for that purpose. Using the exact version matters: a newer core would run database upgrades on the restored data, and an older one would refuse to work with a database written by a newer version. wp core update-db is a no-op when the versions match, as the output below shows, and finishes the job after a deliberate core upgrade.

The site was restored with the database password changed on the new server:

Source: WP-CLI: wp config set

Source: WP-CLI: wp core update-db, WP-CLI: wp rewrite flush

The restored site had 3,000 lp_book posts, 60 attachments with 360 files in wp-content/uploads/2026/10/, lumen-catalog active, the /%postname%/ permalink structure, and book permalinks such as https://lumenpress.test/books/post-2999/. A backup with one altered byte in files.tar.gz was rejected at the first step (files.tar.gz: FAILED, exit status 1) before anything was written.

The manual upgrade instructions say to verify that the backups exist and are usable, and call that essential. A checksum proves the archive was not damaged after it was written, and a backup plugin’s "verification" usually proves the same; neither proves the archive contains what is needed. Only a restore does. Schedule a restore test (monthly for Lumen Press, and after any change to the backup scripts, the hosting or the database version) into an isolated environment, then check content counts, a login, the editor and a few pages, as above.

The test also produces the RTO figure. On the test site the restore took about 10 seconds; the parts that grow with the site are the downloads of the backup from off-site storage (network-bound, roughly proportional to the uploads), the database import (index rebuilds, which dominate above a few gigabytes) and cache warm-up. The parts that do not show in a scripted test are often longer: noticing the outage, getting access to the off-site storage and the decryption key, provisioning a server and changing DNS (whose old records stay cached for their TTL). Write the steps down as a runbook, time a full drill once or twice a year, and compare the total with the RTO; if it does not fit, the answer is a standby environment rather than faster backups.

Plugins are the usual choice on shared hosting without SSH. Common ones in the directory are UpdraftPlus and BackWPup (scheduled database and file backups to remote storage), All-in-One WP Migration (whole-site export and import, mostly used for migrations) and WP-DB-Backup (database only, the example used in the official database guide). Jetpack VaultPress Backup is a commercial service with off-site, real-time backups; commercial products change names and owners over time (the BackupBuddy plugin named in one older book is sold under another name today). Whatever the plugin, check where archives are stored (not under the web root, not only on the same server), whether remote-storage credentials sit in the database where a compromise exposes them, that scheduling depends on WP-Cron, that large sites hit PHP time and memory limits, and that a restore works on a clean server.

Host backups (daily snapshots in the hosting panel) are a useful extra copy, and older books rely on them. They are usually kept on the same provider, sometimes the same infrastructure, for a limited time; restoring them may be a support ticket; and they disappear with the account. Find out the retention, whether they can be downloaded, and how long a restore takes, and keep an independent off-site copy as well. The official guide also notes that cPanel’s full account backups are archival and cannot be restored through cPanel itself.

The rollbacks WordPress performs on its own are not backups either. Since 6.3 a failed manual plugin or theme update is rolled back from wp-content/upgrade-temp-backup/, and since 6.6 a plugin auto-update that breaks the site is rolled back, but neither covers content, settings, a bad but successful update or a lost server (see Updates and Auto-Updates).

Disaster recovery is the plan for getting the site back after a major failure; failover is switching automatically to a standby component when the active one fails. Failover reduces RTO for infrastructure failures, but it replicates mistakes: a dropped table or a defaced page is copied to the replica within seconds. A standby never replaces backups.

For an RTO of minutes, Lumen Press would run a warm standby: a database replica and a synchronised copy of wp-content (or shared object storage for uploads) in a second location, web nodes built from the same images, and a health-checked load balancer or DNS failover in front. The design of stateless web nodes, shared uploads and database replication is covered in Scaling and High Availability; for containerised sites, the volumes that hold the database and wp-content are the data to back up (see Storage: Volumes, Bind Mounts and tmpfs).

On Multisite, the database contains the network tables and one set of tables per site, and uploads are under wp-content/uploads/sites/<id>/, so the whole-network backup above covers every site. Restoring a single subsite means importing its wp_<id>_* tables and its uploads directory while leaving the network tables untouched; see Multisite Networks.