Restore a website: match files, database and configuration

Restoration is a data-changing operation. A backup from yesterday can recover code while also removing today’s orders or enquiries if the database is replaced without a plan.

Plan the recovery

1. Identify the affected website, document root and database. Record the reason for restoration and the desired recovery time.
2. Preserve a private copy of the current state where feasible, including logs needed to investigate an incident.
3. Confirm the backup’s date, scope and integrity. Restore into an isolated test destination first when possible.
4. Use the host’s supported restoration method. Ask support for full-account restores requiring WHM.
5. Check configuration paths, database credentials, file ownership and PHP requirements in the restored copy.
6. Test login, content, uploads, forms and important transactions before reopening service.

After recovery

Review how recent data will be reconciled. A file-only restore may not repair a database migration; a database-only restore may not match newer code. Restore compatible components together.

If compromise caused the outage, address the entry point and rotate affected credentials through a secure process. Otherwise, the recovered site may be compromised again. Do not publish backup archives or leave temporary recovery tools accessible after finishing.