Test a restored database through the application

A database import can complete successfully while the restored application still fails. Missing permissions, mismatched application versions or an incomplete file backup can remain invisible until someone uses a feature.

A recovery test should therefore finish with the application, not with the import command's exit status.

Match the recovery set

Record the database snapshot time, application version and matching files. If uploaded images live outside the database, identify the backup that contains them.

A database taken yesterday and an application directory from last month may not describe one consistent recovery point.

Restore into isolation

Use a separate test database and appropriate credentials. Disable production emails, payment actions, scheduled jobs and webhooks before starting the recovered application.

Keep the original recovery copy intact so an unsuccessful experiment does not become the only remaining version.

Check representative records

Choose known data from before the backup: a recent post, an account, a purchase record or a plugin's saved state. Verify that the application can read and, where safe in the isolated test, update the expected records.

Inspect logs for permission or schema errors rather than relying only on whether the home page renders.

Document what is missing

If a table or attachment is absent, trace whether it was outside the backup scope or unavailable at capture time. Correct the backup plan and repeat the test.

MySQL's backup and recovery documentation covers database-specific approaches and consistency considerations. Your application's recovery procedure must add its own file, version and external-service checks.

The backup verification checklist gives a broader sequence. A good restore test proves that a useful workload can run again, not merely that bytes can be imported.