Choose a backup by a verified recovery requirement; buying another subscription without a restore rehearsal is insufficient.
A WordPress backup is useful when it can recover the website you need. Keep a matching database and file set, restore into a separate environment, and check content, media, access and important workflows before trusting it.
Before you start
This guide is for a site you own or administer with permission. You need access to its backup system and a separate restore destination. If the site accepts orders, appointments or membership changes, agree a recovery window with the person responsible for those records. Restoring yesterday’s database can remove today’s legitimate activity.
The WordPress backup handbook separates the database from files. A normal hosted MySQL database does not live inside your downloaded website folder. WordPress Tools Export transfers content; it is not a complete recovery image.
1. Decide what recovery must preserve
Write a small acceptance sheet before selecting a product. For a brochure site, losing a recent draft may be tolerable. For a store, losing payments or customer records may be unacceptable. The recovery requirement should determine the schedule and retention, rather than the number of backup features on a sales page.
- Which changes can you afford to lose, and how recently were they made?
- Who can access the backup if the hosting account is unavailable?
- Where will you restore it, and who can authorize that operation?
- Which services live outside WordPress, such as email, DNS or payment records?
2. Create one matching backup set
Use your host’s or plugin’s documented process to capture the database and required files. Record the time, site identity and versions. Pause changes or use a supported consistent snapshot when necessary. Keep the database export and its matching file copy together in a clearly named private folder.
Include uploads, themes, plugins and configuration. Configuration can contain credentials, and a database can contain personal information: restrict access and protect copies. Store at least one recoverable copy outside the failure boundary of the hosting account. A second folder on the same server is not independent recovery.
3. Restore into a separate destination
Create a private environment with its own database. Confirm its path and identity before importing anything. Follow the restoration instructions for the actual backup format; do not import a MySQL dump into an unrelated database simply because both systems have WordPress installed.
Keep mail delivery, payments, webhooks and scheduled jobs disabled or in sandbox mode. Use authentication to restrict access. A noindex setting discourages indexing but is not access control. Check URLs and storage paths so the copy cannot write to the original site.
4. Check the recovered result
| Check | What a pass looks like |
|---|---|
| Content | Recent pages, drafts and settings match the chosen recovery point. |
| Media | Images load from the recovered copy, rather than the original server. |
| Access | An authorized administrator can sign in without reusing an unsafe test password. |
| Workflows | Search and important forms work with test data; external delivery remains disabled. |
| Isolation | The original site’s content and database have not changed. |
When to pay for more backup capability
Pay for a documented requirement: independent storage, more frequent capture, longer retention or supported restoration. Skip an additional subscription if an existing service already meets and demonstrably restores your recovery requirement. Check retrieval fees and whether cancellation removes stored copies. Compare hosting backups with an independent backup before paying twice.
If the restoration fails
Keep the failed copy and error notes private. Check that files and database belong to the same set, then ask the backup provider about the specific failure. Do not experiment on production to make the test pass. A missing image, inaccessible administrator or silently empty database is a failed recovery check, even if a dashboard reports success.
Repeat the rehearsal after material hosting, plugin or storage changes. Keep the acceptance sheet with the backup procedure so a different administrator can follow it during an incident.
What we tested locally
On 7 October 2026, we restored a private copy of this portal using WordPress 7.1.2, PHP 8.3.33 and SQLite 3.51.0. In an isolated clone, we changed a test draft and removed its matching test upload. Restoring the offline backup into a second directory recovered both and rendered the draft. The 40 existing editorial records in that baseline retained the same content and metadata hash, and the main database bytes were unchanged.
This demonstrates a local database-and-file recovery rehearsal. It does not test a commercial hosting backup, live email, payments, MySQL restoration or a WordPress version upgrade.
What incomplete restores missed: our repeatable local test
On 8 October 2026, we created a fresh synthetic WordPress 7.1.2 installation with PHP 8.3.33 and SQLite 3.51.0. We saved a native draft and a linked text upload, stopped only that laboratory, and captured a matching offline database-and-file backup. We then changed the draft and deleted the upload. This run did not copy, mount, stop or reseed the editorial portal.
| Recovery copy | What actually returned |
|---|---|
| Matching database and files | The original draft, WordPress-rendered text and upload bytes returned. The full fixture recovery check passed. |
| Database only | The original draft and rendered text returned, but the linked upload still returned HTTP 404. The full recovery check correctly failed. |
| Files only | The upload bytes returned, but the draft and rendered text still contained the deliberate damage. The full recovery check correctly failed. |
These incomplete restores are intentional controls. We compared content and upload hashes and checked the actual WordPress HTTP output; a running process or a completed copy was insufficient. The untouched backup and damaged fixture were preserved separately.
To repeat the fixture, use the project source and its locked dependencies, then run npm run test:recovery -- --wordpress-zip PATH with the pinned WordPress 7.1.2 archive. The included method explains the hash and creates a new private laboratory for every run. The program refuses occupied ports and records failures; its private installations and databases are excluded from the distributable source.
This is a small local SQLite demonstration, not a test of a commercial host, UpdraftPlus or another backup product. It does not establish MySQL recovery, provider support, production recovery time, acceptable data loss, payments or email. Ask any backup supplier which parts it restores, how you retrieve them and what a separate restore rehearsal has proved. Use those answers when comparing hosting backups with an independent backup.
Costs alongside this guide
Backup & recovery
BlogVault · Personal · 1 site, current annual promotion
- Initial term & commitment
- Initial term amountUS$49.5012 months termannual subscription; current 50% promotion
- Renewal
Check local tax at checkout
Price observed 2026-10-07 · Recheck due
Plan details & sources
One modest WordPress site needing daily offsite backups and stated retention.
1 site; 20 GB; daily backups; 30-day retention; 1-day staging; offsite storage and migration; real-time backup on higher tiers.
Choose another option if: You need real-time backups, more than 20 GB or staging beyond one day.
Public USD reference; billing country unconfirmed · Check local tax at checkout
Exact annual amount published
Renewal: Future renewal amount and invoice duration not confirmed
Check local tax at checkout
Prices checked 2026-10-07 · recheck dueOfficial price source ↗- Backups & restore: Included. Daily offsite backups; 30-day retention
- Backups & restore, Plan allowance, Tradeoff ↗Features checked 2026-10-07
Observed 2026-10-07 · Recheck due
Official price evidence ↗Recorded prices can change. Check eligibility, taxes and the current full bill with the provider. Different currencies and services are shown separately.
Sources and verification
Editorial review 2026-10-08. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- WordPress backup setsChecked Both database and files are required; backup before upgrades.
Limits: General WordPress advice; not a test of any commercial backup service. - Backing up WordPress filesChecked Uploads, themes, plugins and configuration belong to the file backup.
Limits: A file copy does not normally include a MySQL database. - WordPress database backup and restoreChecked Database export and import are separate operations.
Limits: Instructions target MySQL/MariaDB; our local demonstration uses SQLite. - WordPress Tools ExportChecked Content export produces WXR for transferring editorial content.
Limits: A content export alone is not a full website recovery set.