A backup is not a recovery plan: how to test a website restore

Decide what “recovered” means for your business

For a brochure site, recovery might mean visitors can read service pages and submit an enquiry. For a booking system, it also means the correct appointments, availability, and customer records are usable. A homepage screenshot cannot demonstrate all of that.

Two terms help make the decision explicit. Recovery time objective, or RTO, is your acceptable interruption window. Recovery point objective, or RPO, describes the acceptable data loss measured in time. These are targets you choose, not promises that a backup product automatically delivers.

For example, a business might choose a four-hour RTO and a one-hour RPO for bookings. Those are illustrative targets, not recommendations for every business. Ask what losing an hour of bookings would require your staff to reconstruct, then have your provider show whether the recovery design can meet your chosen limits.

References: AWS: disaster recovery concepts, RPO, and RTO

Separate the website from the data behind it

AWS guidance includes data, application code, configuration, and infrastructure in recovery planning. Apply that distinction to your own site rather than assuming a ZIP file contains everything.

A static marketing website may be rebuilt from its repository and assets, provided the build instructions and required configuration are available. Its enquiry inbox, external form service, or booking platform is a separate dependency. Restoring the site does not restore those services or their records.

A database-backed website also needs a compatible database recovery point and any uploaded files. Code rollback alone will not undo a database change. Ask the person managing the system how they keep those pieces consistent.

References: AWS: backup and restore planning

Prepare a test that cannot act on real customers

Have your technical provider prepare a separate, access-controlled test environment before restoring the application. Keep production traffic and DNS unchanged. A hidden URL or a noindex setting is not access control.

Our suggested test boundary is strict: no production database connection, no live payment credentials, no outbound customer email or SMS, no active webhooks, and no background jobs that can update external systems. Use sandbox integrations or local capture tools where appropriate. Confirm these restrictions before starting the restored application, because scheduled jobs may run immediately.

Use synthetic or masked data where possible. If a real backup is necessary to validate recovery, restrict access and agree on retention and secure cleanup. Give the exercise a budget, a named owner, and stop conditions, such as any unexpected connection to a production service.

Run the restore and test the work people actually do

AWS recommends restoring to a new location and validating the recovered data, rather than treating a completed restore job as sufficient evidence. Have a reviewer follow written instructions so missing knowledge becomes visible.

1. Record the selected backup or code version, its timestamp, the test scope, and the exercise start time.
2. Verify isolation, then restore the files, application configuration, and database required by the chosen scenario.
3. Open representative pages, images, and documents. Check language variants and important links.
4. Run a test enquiry into the capture tool. For database applications, inspect agreed sample records and relationships, then test a harmless change in the isolated copy.
5. Confirm the newest expected record is present and check for missing or inconsistent data against the agreed reference.
6. Record when validation finishes, including time spent obtaining access or fixing instructions. Compare the observed duration and data gap with your targets.

References: AWS: perform periodic recovery to verify backup integrity and processes

Use an owner’s scorecard

Ask for a short evidence sheet, not just a “passed” message. Record each result as pass, fail, or not tested. A test that excludes DNS changes or a third-party booking provider cannot establish your full recovery time for those scenarios.

• Scenario: what failed, what was restored, and what stayed outside the exercise?
• Data: which timestamp and sample records were verified?
• Usability: which customer and staff journeys worked in the isolated copy?
• Timing: target, measured duration, delays, and excluded steps.
• Follow-up: each gap, its owner, and the date for a focused retest.

Turn the findings into a repeatable recovery plan

Update the instructions while the missing steps are fresh. Remove temporary resources and test data through the agreed cleanup process, keeping the evidence your business needs. Schedule another exercise after significant platform changes and at an interval suited to your risk and rate of change.

A passing exercise is evidence for the scenario tested. It does not guarantee recovery from every outage. Its value is practical: you learn which steps, permissions, dependencies, and decisions would otherwise slow the business down.