A local test with synthetic data
WordPress backup restore test: what we checked.
In a separate local installation, we deliberately changed a test page and setting, then removed a test file. We restored the backup and compared the result with the original state.
We ran this test on 6 October 2026 in WordPress Playground using synthetic data. It was not a recovery test of our production server or a client website.
Test scope
What did the backup contain?
The fresh test installation used WordPress 7.1.2, PHP 8.3.33, SQLite and Hiperlink Digital theme 0.1.2. It ran only on the computer’s local address. Email delivery and external WordPress HTTP requests were blocked. We did not copy production data or credentials.
After checking the initial state, we stopped the test process and archived the entire local installation, including its SQLite database. The backup contained 3,816 files. We recorded SHA256 checksums for the archive and individual files.
In this environment, the SQLite database lives inside the installation directory. A typical WordPress host usually keeps MySQL or MariaDB data separately, so the database needs its own backup. Downloading the website directory alone therefore does not prove that the database is included. The official WordPress backup guidance explains both parts.
Method
Introduce faults, then restore.
01
Record the original state
We created one synthetic page, a separate test setting and a text file. We checked the data through WordPress and retrieved the page and file through the local web server.
02
Deliberately change three things
We replaced the page text with an alteration marker, changed the test setting and removed the test file. The checks had to detect these differences before we attempted the restore.
03
Extract the backup into a fresh directory
We preserved the damaged test installation. We extracted the archive into a new, empty directory and compared every file checksum before starting WordPress.
04
Check the running website
Once the restored installation was running, we repeated the checks of the page text, setting, file and web output. Starting the server was one step in verification, not its completion.
Results
What was restored?
Page text and setting
The restored page contained the original text, and the test setting held its initial value. The deliberate alterations were no longer present in the restored installation.
The test file
The file existed again. Both its checksum on disk and the checksum of the content retrieved through the local web server matched the original value.
Backup integrity and web output
Before startup, the checksums of all 3,816 restored files matched the archived copy. After startup, all 14 defined checks of data, web output and local safeguards passed. That count describes this small test scenario, not a complete assessment of a production website.
Want help applying this to your website? See Website security or tell us about your project ↗
A finding that changed the check
HTTP 200 was not enough.
After we removed the test file, the local server still returned HTTP 200 with HTML content at its address. A simple availability check would therefore have missed the absence of the expected file.
Checking that the file existed and comparing its content detected the fault. After the restore, the same request returned the expected data again. This finding applies to the local test environment; we did not establish the same behaviour on the production server.
For an important page, record what it must contain and which action it must support. For a file, check the expected content. Forms, sign-ins and orders need separate functional tests with an agreed scope and consideration of any side effects.
Limits
What did this test leave out?
We did not restore the Hetzner server, a MySQL or MariaDB database, production accounts, Polylang translations, Rank Math settings or the other production plugins. We did not test email delivery, payments, external integrations, DNS, TLS or behaviour under load.
The backup and restored installation were on the same computer. This test does not demonstrate recovery after losing that computer or the availability of a backup stored elsewhere. We did not measure a recovery target for a customer website and make no recovery-time promise from this result.
A WordPress XML/WXR content export is also not a complete backup of the database, plugins, settings and media files. Before attempting recovery, establish exactly what the chosen backup method saves.
Plan your own check
What should you record first?
Identify the backup date, its contents and location, the person who can access it, and a separate restore destination. Agree which changes made after the backup may be lost and how you will identify them.
Set success criteria before you start: expected text and files, important user actions, access and integrations. Define what would stop the test, who decides the next step, and how the original state will be preserved. Use synthetic data wherever possible.
Record the steps taken, differences found, final result and unresolved questions. Repeat the check when important dependencies or the agreed scope change. Testing frequency and recovery objectives need to be set for the individual website.
For related planning, see the SEO migration checklist and our hosting selection guide. The development tool used here is described in the official WordPress Playground documentation.
Next step
Define a check for your website.
As part of WordPress maintenance, we can define the scope of backup and restore checks. Send your website address, how backups are currently made, and which functions matter to you. Do not send passwords, database backups or personal records through the contact form.