How to Back Up a WordPress Site and Prove You Can Restore It

A backup is useful only when it contains the required data, can be accessed during an incident, and restores into a working site. WordPress recovery normally requires both the database and files, plus the credentials and operational knowledge needed to reconnect them.

Inventory what must be recoverable

The database commonly holds posts, pages, settings, users, comments, orders, and plugin data. Files include WordPress core, themes, plugins, uploads, custom code, configuration, and server rules. Also record DNS, certificates, scheduled jobs, environment settings, mail configuration, external storage, API dependencies, and license access that an archive may not contain.

Choose recovery objectives

Recovery point objective asks how much recent data you can lose. Recovery time objective asks how long the service can be unavailable. A brochure site and a busy store need different schedules. Base frequency on change rate and business impact, not a generic “daily backup” badge.

Keep copies outside the failure boundary

A copy on the same hosting account may disappear with account compromise, disk failure, or accidental deletion. Keep at least one protected off-site copy under separate access. Limit who can delete backups, use multifactor authentication, encrypt sensitive archives, and document how authorized people recover credentials.

Automate, monitor, and retain deliberately

Automation reduces forgotten jobs but can also automate empty or corrupt copies. Alert on failed jobs, unexpected size changes, missing database exports, expired credentials, and retention failures. Keep a short set of recent backups plus older recovery points appropriate to the risk; do not allow unlimited archives to consume production storage.

Test restoration away from production

1. Choose a backup without modifying it.
2. Restore into an isolated environment.
3. Connect the correct database and files.
4. Update temporary URLs safely if required.
5. Test public pages, login, forms, search, media, scheduled tasks, integrations, and a critical transaction.
6. Scan for exposed secrets and block public indexing.
7. Record duration, missing steps, and owner.

A restore test is also a dependency audit. If the site cannot function without an undocumented DNS change, external secret, object store, or license portal, add that dependency to the recovery runbook.

Write the restore runbook while evidence is fresh

Record archive location, encryption and access steps, required software, database import order, configuration changes, URL handling, cache purge, DNS decision, validation routes, and the person authorized to declare recovery complete. Include a stop point for escalating instead of improvising on the only good copy. Review the runbook whenever hosting, domains, storage, or ownership changes.

Back up before controlled change

Create a verified recovery point before core, theme, plugin, PHP, database, domain, or infrastructure changes. A backup does not make a risky change safe by itself; you still need compatibility checks and a rollback decision. Review new backup plugins with the plugin evaluation guide, especially their storage access and deletion behavior.

Protect recovery privileges

Backup archives can contain credentials and personal data. Restrict access, log downloads, rotate exposed secrets, and separate routine editorial roles from backup administration using the least-privilege review.

Sources and further reading

Primary and contextual sources used to verify definitions or give readers a relevant next resource.

• WordPress backup handbook Official WordPress guidance covering both database and file backups.

IE

Prepared and reviewed by

Infortified Editorial Team

Research-led guides with explicit scope, source checks where facts require them, and an independence review before publication.