Choose the recovery point carefully
The oldest backup is not automatically the best choice, and the newest is not necessarily clean. Establish the failure timeline, the content to keep and any enquiries, orders or other records created since the proposed recovery point.
What we need to understand
- The current condition and when the problem began.
- Whether the backup includes files and the database.
- When it was created and whether restoration has been tested.
- Recent data that a restore could overwrite.
Test before switching
Where the environment allows, a backup can be checked in an isolated test environment. Pages, images, login and key functions can then be assessed before agreeing the live-site work. Data replacement needs explicit agreement.
If a complete backup is unavailable
Existing files, the database and available content can still be assessed to establish what can be retained and what may need rebuilding. Recovery feasibility depends on the actual material available.
Protect recent business data before restoring.
A full-site restore may replace articles, enquiries, memberships or orders added since the backup. We first identify what is still being updated, what has stopped working and whether content and system files can be handled separately.
A recovery process you can follow.
- Review available data: establish the dates and scope of hosting backups, files and databases.
- Choose a suitable version: compare the failure timeline with recent business activity.
- Test key functions: where possible, check pages, images, logins and forms in a test environment.
- Plan the release: agree how data, backups and the switch to the live site will be handled.
Prepare for the next update or incident.
We can help define backup frequency, retention, updates and routine checks. The person responsible should know where backups are held, what they contain and how to verify a restore.
Read: five questions before restoring a backup ↗