The website stops taking inquiries. Someone opens the hosting dashboard and finds a successful backup from last night. Then comes the next question: who can restore it, and what will still be missing afterward?
That is a useful conversation to have while the website works. A recovery rehearsal gives the business a record of what it can recover, which accounts it needs, and where the process gets stuck.
The UK's National Cyber Security Centre recommends checking that backups contain the important data and knowing how to restore them. The website exercise below turns that principle into a practical handover between a business and its technical provider.
List what the website needs to function
Ask your provider to name the pieces behind the pages. These might include application code, uploaded images, a database, domain settings, and connections to services such as email or a booking platform.
Record where each piece lives and who controls access. A copy of the code might rebuild the layout while leaving the product catalog empty. A hosting snapshot might omit records stored in a separate service. Ask what each backup includes and excludes.
Use a fictional repair business as an example. Its recovery checklist could cover service descriptions, uploaded job photos, appointment requests, and the route used to deliver those requests. Each item needs its own check after restoration.
Agree on the business tolerance
Define how much recent work the business could reconstruct manually. Then identify how long it could operate with a temporary contact page or telephone number. Those answers help the technical team choose a backup schedule and recovery process.
Keep the assumptions specific. A site that publishes occasional articles has different recovery needs from a booking system accepting appointments throughout the day. Ask what happens to records created after the selected backup. Write down how staff would identify and reconcile them.
Avoid accepting a recovery time based only on how long a download takes. Restoring access, checking content, and reconnecting outside services also take time. Measure the complete exercise before making a promise to the team.
Rehearse in a separate environment
Have the provider restore a chosen backup into an isolated test environment. Keep the public website running. Agree on who authorizes the exercise and who stops it if an unexpected dependency appears.
Before opening the restored application, disable outgoing messages, payment actions, scheduled jobs, and other connections that could affect real customers. Use test credentials where available. Restrict access to the restored data and decide when the temporary copy will be deleted.
Ask the provider to explain this isolation in plain language. A rehearsal should never become an accidental second system sending appointment reminders or modifying live records.
Check the work a customer actually does
Open the restored site on a phone. Visit an important service page, inspect images, and follow the contact path. For systems with stored records, compare a selected record and its attachments against the expected backup date.
Record the result of each action. A homepage that loads tells you little about an appointment that cannot be retrieved. Ask the person who uses the system daily to take part, because they can spot missing details the technical team might overlook.
Use fictional submissions for any functional checks. Verify the intended test destination before pressing send. Keep real payment and customer notification systems disconnected throughout the rehearsal.
Leave instructions another person can follow
Save the backup reference, restore steps, required accounts, observed duration, and unresolved problems. Keep credentials in the agreed secure account system, separate from the instructions.
Name a backup contact for the person who normally manages the website. Confirm that the business can reach its domain and hosting accounts if the usual developer is unavailable. Set the next rehearsal around meaningful changes, such as a new booking service or a different hosting provider.
Bring the findings into your website maintenance plan. If you are rebuilding the site, include a demonstrated restore in the web development handover. The deliverable is a working recovered site, accompanied by instructions your team can use.