Information checked: 21 July 2026.
Restoring a website is a controlled recovery operation. Before overwriting anything, confirm the incident, preserve evidence and decide how new orders, enquiries or content created after the backup will be handled.
In brief: Restore into a trusted environment and explicitly reconcile data created after the selected backup.
Prepare the recovery
- Identify the failure and stop unsafe changes.
- Preserve the current system and relevant logs where possible.
- Choose a backup from before the failure or compromise.
- Verify the backup’s contents and integrity.
- Prepare an isolated or clean target environment.
- Document the point in time and expected data gap.
Restore in a safe order
Typical restoration sequence
- Infrastructure
- Supported runtime, permissions and network controls
- Files and application
- Known-clean code and required uploads
- Database
- Compatible schema and expected records
- Configuration
- Correct environment, URLs and secrets
- Integrations
- Email, payments, booking and scheduled tasks
- Public traffic
- DNS, TLS, redirects and monitoring
Protect data created after the backup
For transactional sites, export or reconcile orders, payments, bookings and enquiries created after the recovery point. Do not blindly overwrite live data with an older database.
Acceptance check
Before reopening, test administration, public pages, forms, account access, payment or booking, email and monitoring. Record what was restored, what was replayed and what remains uncertain.
Control reopening
Restoration is not complete when the home page loads. Use a release gate covering administration, forms, transactions, email, redirects, security controls and monitoring. Reopen public traffic only after the designated owner accepts residual risk.
Records to keep
- Selected recovery point and reason.
- Data reconciliation worksheet.
- Functional and security test results.
- Reopening approval and monitoring period.
Owner test: Have a second reviewer follow the checklist and confirm that no test payment, email or scheduled task can affect real customers unexpectedly.
Use a clean-room check after suspected compromise
When recovery follows a security incident, restore into an isolated environment first. Inspect administrators, scheduled tasks, redirects, injected content and unexpected outbound connections before connecting the service to normal traffic. A backup can be technically intact while already containing the attacker’s persistence.
Sources and date checked
This practical guidance was checked against the following primary sources. Date checked: 21 July 2026.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.