A backup dashboard can be green while a website remains impossible to recover. Files may be intact but the database incomplete, credentials unavailable, or the application dependent on a service nobody documented.
Define the recovery target
Choose one website and record what must return: application files, database, uploaded media, configuration, scheduled jobs, and DNS settings. Keep secrets in a controlled store rather than a public recovery document.
Decide how much recent data the business can lose and how long recovery may take. These are different questions. A daily backup may meet a recovery time target while losing more orders than the business can accept.
Restore somewhere isolated
Create a separate test environment with access restricted to the team. Disable outgoing email, payment processing, webhooks, and scheduled jobs before allowing the restored application to run. A copied production database can otherwise trigger real actions.
Restore the files and database from the same recovery point where possible. Confirm permissions, runtime requirements, environment variables, and storage paths.
Test business functions
Open more than the homepage. Check login, search, media, and the administrative area. For a store, test checkout using a sandbox payment method. Compare important record counts with the expected backup date.
Record the elapsed time, missing components, and manual steps. Update the runbook and repeat after major architectural changes.
What counts as success?
A successful restore reproduces the functions the business needs within its agreed recovery targets. The existence of an archive alone does not establish that.
Published for Alif Host. Related hosting resources are available on the Alif Host website.
