A completed backup job does not tell you whether you can rebuild a working website. A restore rehearsal gives you a controlled way to check the backup, practise the steps, and discover missing pieces before an emergency. Keep the exercise separate from your live site: restore into a private destination, check representative functions, and record what needs fixing. The steps below use WordPress details where relevant.
1. Define what recovery must achieve
Write down two targets before touching the backup. Your recovery point objective is the maximum amount of recent work you can afford to lose, expressed as time. Your recovery time objective is how long you can allow for restoring usable service. Choose targets based on how your website is used.
For a fictional publishing site, you might aim to recover content no more than 24 hours old and complete a rehearsal within two hours. These are planning targets, not promised outcomes. Compare the selected backup’s timestamp with your recovery point target, then time retrieval, preparation, restoration, and verification separately.
Name the person performing the restore and the person checking the result. If you need your host to supply a backup or prepare a destination, confirm the process and include that dependency in your notes.
2. Inventory the complete backup set
For a typical WordPress site, you need both files and a database export. Downloading the website directory alone usually does not capture the database. Treat files and database copies made around the same time as one backup set.
Check the contents before starting. An archive’s presence is not enough; establish which components it contains and whether you can open it. Keep the original backup intact and work from a separate copy.
- Files: WordPress core, themes, plugins, custom code, configuration, and rewrite rules.
- Uploads: images, documents, and any media stored outside the usual uploads folder.
- Database: the export containing posts, settings, and other site data, with its backup time recorded.
- Dependencies: required database access and any separately stored components you must obtain.
3. Prepare a private destination and stop external actions
Use a separate local environment or a restricted test installation with its own directory and database. Protect access before importing anything. A hard-to-guess address or a request for search engines to stay away does not make a copy private. Keep the live domain and its routing unchanged.
Before the restored application can execute, block outbound email and external service connections in the test environment. Disable payment integrations, webhooks, scheduled jobs, and application cron on the copy. Check both hosting-level schedules and application settings; do not assume one switch covers everything.
Have the destination’s administrator establish these controls if you cannot verify them yourself. Restored settings can bring back active integrations, so check the controls again after import and before browsing. Use dummy records and dedicated test accounts for exercises; keep any sensitive restored content restricted to authorised testers.
4. Restore only into the test environment
Before each restore operation, confirm the destination directory and database name. The database user should be limited to the test database. Stop if the restore tool’s target is unclear.
For WordPress, the usual sequence is to restore files and then import the database. Update the copied wp-config.php to use the test database connection. Ensure the copy cannot connect to the production database before allowing it to run.
Adjust the copied site’s WordPress Address and Site Address for the test location. Other stored references may also need changes. Use a WordPress-aware replacement method that handles serialized data, and preserve post GUIDs. Review copied redirects and permalink rules so they do not send your checks back to production. WordPress Multisite requires a procedure specific to that setup.
5. Verify pages, uploads, and logins
Confirm you are viewing the test destination throughout the checks. A page that loads an image from production has not demonstrated that the image exists in your restored uploads.
Choose a small, repeatable sample that covers different parts of the site. Record expected and observed results, with evidence that excludes private records and credentials.
- Open the homepage, an older article, a recent article, and a page using a different template.
- Check several images and a downloadable file against the backup inventory.
- Follow internal links and check permalink behaviour for unexpected redirects.
- Sign in and out with authorised test accounts; confirm the expected administration access.
- Create and remove a dummy draft to check database writes. Keep email, payments, and scheduled actions disabled.
6. Record gaps, then protect and retire the copy
Record the backup timestamp, elapsed time, missing components, failed checks, and manual fixes. Assign each gap an owner and a follow-up test. Distinguish failures in the backup from differences introduced by the test environment.
Document functions you deliberately left untested, including live payments and email delivery. A successful page check does not establish that every integration will recover.
Keep the copy access-controlled while investigating. When finished, remove the test files, database, temporary accounts, and exported data under your retention rules. Preserve the original backup and a concise rehearsal record without secrets. Repeat the exercise after correcting significant gaps.
Plan your next step
Use the rehearsal record to improve your recovery instructions: what to restore, where to restore it, what to verify, and who handles each unresolved dependency.
Compare the current shared hosting options and confirm the requirements for your own website before ordering.
Related: our practical guide to the next step.
Source notes
WordPress backup documentation · Recovery objectives: RTO and RPO. Sources checked 2026-09-27.