What a website backup restore test should prove

By Noe Guerrero III

Ask for a short report after a website backup restore test. It should identify what was restored, the recoverable data point, the checks performed, elapsed time and remaining gaps. A homepage screenshot is useful evidence for one page; it doesn't establish that the site's records, uploads and connected workflows are recoverable.

The report doesn't need to be complicated. It needs enough detail that you and your developer can decide what to fix and what to test next. Here's a practical way to scope that rehearsal without experimenting on the live business.

Name the parts you're trying to recover

Start with a component list. Depending on the site, that could include application files, the database, uploaded media, configuration requirements and instructions for rebuilding the running environment. Ask where each component is backed up and who can retrieve it.

Be specific about what “website backup” includes. The official WordPress backup guide explains that a typical WordPress site needs both files and its database for a full restore. Downloading the site's directory normally doesn't capture the separate database. Other platforms need their own coverage check.

Also list dependencies outside the backup. Your email provider, domain account, payment processor or external booking service may have its own data and recovery process. Record who manages each one. Recovering the website files doesn't demonstrate that those separate services have been recovered.

The component list should tell you what's included, what's excluded, what must be supplied separately and who owns the next step. Record where authorized configuration can be obtained; keep passwords and private keys out of the report itself.

Separate the data point from the recovery time

There are two business questions here: how much recent work could be missing, and how long it takes to restore the required service.

NIST's backup planning guide for service providers distinguishes the acceptable age of backup data from the desired restoration timeframe. Agree on both with the business before interpreting a rehearsal as a success.

Imagine a custom furniture workshop in McAllen that receives website quote requests with sketch uploads. This is a hypothetical example. Its chosen backup contains data through 9:00 a.m. Central, and the rehearsal begins at 10:00 a.m. The hour between those times is a potential data gap to discuss; it isn't the time the restoration took.

Have the developer identify the actual recoverable point. A backup job's start time, completion time and newest included record aren't interchangeable. If the database and media came from different captures, ask how their consistency was checked. A quote record that points to a missing sketch is an incomplete result even if the page opens.

Write down the business's agreed tolerance for missing work and the process for reconciling anything outside the restored copy. Don't quietly assume every inquiry can be recreated from an email notification.

Approve an isolated rehearsal

Have the developer prepare an access-restricted test environment before restoring the copy. Confirm that it cannot send customer emails, charge a card, create a real booking or trigger live integrations. Merely giving a cloned site a different address doesn't establish those boundaries.

Agree on the data permitted in the rehearsal. Use designated dummy records and test accounts for the checks where possible, and protect any copied business data under the same access expectations as the original. Search visibility settings alone aren't access control.

Ask for a clear scope statement: the test location, person responsible, backup reference, allowed actions and excluded connections. Verify the separation before anyone clicks through the workflow. This article describes what to request from the developer; it isn't an instruction to overwrite the production site.

For the workshop example, a controlled quote submission might save only to the rehearsal database and a designated test inbox. A disconnected live email service should be recorded as excluded, with a separate verification plan if email delivery matters to recovery.

Check a useful slice of the business

Choose the checks before the restore. Include representative public pages, an existing designated test record and any media attached to it. Then try one agreed workflow in the isolated environment. If the site supports English and Spanish, include both where restored content or navigation could differ.

For the hypothetical workshop, that could mean opening a service page, finding a dummy quote created before the backup point, opening its sketch, and submitting a new dummy request to the isolated copy. Have the developer inspect the saved result, rather than relying solely on the customer's confirmation screen.

The following is a fictional example of report entries, not evidence from a real customer test:

Keep pass, failed, excluded and unverified distinct. “We didn't check it” should remain visible. A missing attachment needs an owner and a correction even when the surrounding page looks right.

Measure the whole agreed exercise

Define the clock boundaries in advance. Did timing start when someone requested access, when the backup download began or when the restore command ran? Did it end when the homepage loaded or when the agreed checks finished?

Record those milestones separately. Include time spent retrieving the backup, obtaining authorized access, rebuilding missing configuration and checking the result. If someone prepared the environment beforehand, state that too. Otherwise, a fast rehearsal can conceal setup work that would still be necessary during an outage.

Report the observed duration and conditions. Don't turn one successful rehearsal into a promise that every future incident will take the same time. This test also doesn't establish that a backup is safe to use after a security incident; that requires its own assessment.

Finish with an owner and a retest

Close the report with unresolved gaps, the person responsible for each correction and what will count as a successful retest. For the missing sketch, the next task is to identify the media coverage problem, correct it and demonstrate the restored attachment from an appropriate backup set.

Keep the report with the recovery instructions and repeat the relevant checks after material changes to hosting, storage or the site's application. Our business app launch checklist places recovery alongside permissions and other launch checks; this rehearsal report gives the recovery discussion its own evidence.

Bring the component list and last report to your next maintenance conversation. They give you a much better question than “Are backups turned on?”: what can this business recover, and what still needs proving?