WordPress Backup Solutions: A Recovery Plan for Real Sites

By Greg Nowak. Updated 22 July 2026.

A WordPress backup is useful only if it can return the site to service at the right point in time. For a business owner, operations lead, or agency, that means protecting more than pages and images. Orders, enquiries, user accounts, configuration, custom code, and the knowledge required to rebuild the environment may all matter.

Start with two business questions: how much recent data could you afford to lose, and how long could the site remain unavailable? Those answers define your recovery point objective and recovery time objective. They should drive the schedule and tooling—not whichever backup plugin happens to be popular.

Match the backup plan to the cost of data loss

Site profile	Practical starting point	Critical recovery check
Brochure site with occasional edits	Daily automated backup, plus an on-demand copy before significant changes	Pages, media, forms, redirects, and configuration
Lead-generation site	Daily files and database backups frequent enough to protect stored enquiries	Confirm whether form data also exists in email or a CRM
Editorial or membership site	Daily files with more frequent or change-aware database protection	New posts, accounts, access rules, and scheduled publishing
WooCommerce store	Transaction-aware or near-real-time protection alongside full restore points	A rollback must not silently remove newer orders
Agency-managed portfolio	Central monitoring, named owners, and a restore runbook for every site	Failed jobs, credential access, handover, and client-specific exceptions

Choose backup frequency according to acceptable data loss and recovery time, then verify the result with a restore.

Back up the recoverable system, not just WordPress files

A typical WordPress recovery needs a matched database export and file archive created at roughly the same time. The database contains content, users, settings, orders, and plugin data. Files include uploads, themes, plugins, must-use plugins, wp-config.php, web-server rules, and any custom code that is not safely held elsewhere.

Also record the surrounding environment: PHP version and extensions, scheduled jobs, DNS and CDN configuration, outgoing-mail setup, storage mounts, licences, and any services called by the site. WordPress core can normally be downloaded again, but undocumented infrastructure can turn a simple restore into a long investigation.

Check exclusions carefully. A backup product may omit cache directories sensibly, yet also miss custom database tables, files outside the usual WordPress tree, or a second installation in a subdirectory. “Full backup” is not a reliable specification until you know what it includes.

Choose the operating model your team can support

A reputable plugin sending backups to remote storage is often sufficient for a smaller site. A managed, change-aware service can be a better fit when orders or content change throughout the day and a fast point-in-time rollback matters. Hosting snapshots are convenient for rebuilding a server quickly, but they should not be the only copy if the same provider account controls both the live site and its backups.

Server-side automation offers control and avoids PHP execution limits, but it also creates an operational responsibility. Someone must monitor it, move copies away from the web server, manage retention, protect credentials, and maintain the script after hosting changes.

A practical WP-CLI backup example

WP-CLI reads the database credentials from wp-config.php and runs the export through mysqldump. The following is a starting point for a conventional Linux installation; adapt paths and included files to the actual site:

umask 077
site_root=/var/www/example-site
backup_root=/secure-backups/example-site
stamp=$(date -u +%Y%m%dT%H%M%SZ)

install -d -m 700 "$backup_root"
wp --path="$site_root" db export \
  "$backup_root/database-$stamp.sql" --add-drop-table

tar -C "$site_root" -czf \
  "$backup_root/files-$stamp.tar.gz" \
  wp-content wp-config.php

sha256sum "$backup_root"/*-"$stamp".* \
  > "$backup_root/SHA256SUMS-$stamp.txt"

Put tested commands in a root-owned script and let cron call the script:

15 2 * * * /usr/local/sbin/backup-example-site

This is preferable to hiding a long command inside the crontab. If an inline cron command contains date formatting, remember that traditional cron treats unescaped percent signs specially.

The local archive is only the first stage. Transfer it to separately controlled storage, verify that transfer, and apply deliberate retention. Restrict access because the database and configuration can contain personal data and secrets. For higher-risk sites, keep an encrypted or immutable copy that compromised site credentials cannot alter.

Test recovery as a business workflow

Run the first restore test immediately after setup, after major hosting changes, and periodically thereafter. Restore into an isolated staging environment that cannot send customer email, process payments, or appear in search results. Then:

Restore the files followed by the matching database.
Confirm administrator access, important pages, media, redirects, and navigation.
Submit a test form and check where the result arrives.
For commerce or membership sites, test accounts, products, orders, and access rules.
Check scheduled jobs, integrations, security controls, and outgoing email.
Record the recovery time, problems found, and exact steps needed next time.

A successful backup notification proves only that a job ran. A restore drill proves that the archive, credentials, documentation, and people can recover the service.

Make ownership explicit

Every site should have a named person who receives failure alerts, access to storage that survives staff or supplier changes, and a short restore runbook available outside WordPress. Agencies should include backup ownership, retention, testing, and handover in the service agreement. Otherwise, the system often fails at precisely the moment responsibility changes.

If your current arrangement is a mixture of hosting snapshots, an old plugin, and knowledge held by one developer, Greg can review it and turn it into a proportionate recovery plan your team can operate. Ask Greg to review your WordPress backup setup.