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

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:

1. Restore the files followed by the matching database.
2. Confirm administrator access, important pages, media, redirects, and navigation.
3. Submit a test form and check where the result arrives.
4. For commerce or membership sites, test accounts, products, orders, and access rules.
5. Check scheduled jobs, integrations, security controls, and outgoing email.
6. 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.

Related on GrN.dk

• JavaScript-Heavy Service Pages Still Lose Leads: A 2026 Rendering Audit
• Fixing Website Email Deliverability in 2026: A Practical Checklist for Business Sites
• MariaDB 10.6 EOL: quiet CMS hosting debt needs a real upgrade plan before July 2026

Need help with this kind of work?

Review your WordPress backup setup with Greg Get in touch with Greg.

Sources

• WordPress Advanced Administration Handbook: Backups
• WP-CLI Command: wp db export
• Jetpack VaultPress Backup Documentation
• CISA #StopRansomware Guide