A recoverable WordPress backup needs the site's database and relevant files. The database holds posts, settings and other stored content. Files include uploads, themes, plugins and configuration. A content export alone is not a complete site backup.
Choose a backup method
Your host may provide scheduled backups and a restore tool. Check what they include, how long they retain copies and whether you can download one. A backup plugin can provide a separate route, but it also needs working storage and a documented restoration process.
For a basic site, choose a method you can actually restore. For a shop, ask how frequently orders are captured and how recovery preserves recent transactions. Set the schedule around the amount of data you can afford to lose, not around a generic daily recommendation.
Make a complete copy
- Start a fresh backup through your host's tool or chosen plugin.
- Include the database, uploads, active theme and child theme, plugins, and relevant configuration. Check the tool's exclusions.
- Wait for completion and inspect the backup log for errors or missing components.
- Store a copy separately from the server it protects. An account failure or full disk can affect both the site and a same-server backup.
- Record the date, site address, tool and restore instructions alongside the files. Protect credentials and personal data inside the backup.
Keep more than one recovery point. If a problem goes unnoticed, the newest backup can already contain it. Check storage capacity and retention rather than accumulating files without a plan.
Verify restoration on an isolated site
A restore test is stronger evidence than a successful-upload notification. Use an isolated staging environment or ask your host to perform a recovery drill. Do not restore over your live site merely to check that a backup works.
Follow the tool's documented restoration procedure. Confirm that the restored site has the expected pages, uploads, settings and accounts. Inspect a form or other important feature. If the staging address differs, follow the tool's supported URL-adjustment process; avoid a blind database search-and-replace.
Disable indexing and outbound production integrations on the test copy. Backups can contain customer records and login credentials, so the restored site needs the same care as production.
Write down the emergency steps
Record where to log in, where backups are stored, who can restore them and how long recovery is expected to take. Keep this information accessible even when WordPress is unavailable.
A plugin restore that requires a working admin screen can be awkward after a fatal error. Check whether your provider supports restoration through hosting access or another recovery route.
Before a real restore
Take a copy of the current state when practical, even if it is broken. Identify data created after the selected backup, including orders, submissions and uploads. Plan how to preserve it before replacing the database.
After restoration, verify public pages, login and critical flows, then fix the original cause. Restoring a vulnerable plugin without addressing the vulnerability can repeat the incident.
Sources & verification
Sources checked September 30, 2026. Documented behavior is distinct from hands-on testing.