The backup report is green. The website’s owner still cannot answer a simpler business question: if the application disappeared, could a customer recover the service they have already paid for?
A restored home page leaves that question open. A customer might still be unable to sign in, find a booking or download its ticket. The database can contain the right reference while the file itself is missing. A copied background job could also send a confirmation or attempt a payment from the test system.
This happens to well-run teams. On 31 January 2017, GitLab.com’s daily database backups had been failing without anyone noticing: the job ran pg_dump 9.2 against a PostgreSQL 9.6 database, and the failure emails were rejected by the receiving mail server. When production data was deleted that day, the backup bucket was empty. GitLab’s postmortem describes restoring from a manual snapshot taken about six hours earlier and losing the changes made since then: roughly 5,000 projects, 5,000 comments and 700 new user accounts, by its own estimate.
The short answer: a useful backup restore test starts with one customer action. Recover its dependencies in isolation and check the expected permissions. Prevent live messages, charges and integration changes before application startup. Report observed recovery time, recovery point and untested dependencies separately from your objectives.
1. Choose the action that makes recovery useful
Consider an illustrative website selling professional training sessions. Customers pay online, receive confirmation and return to their account to download a ticket. The first recovery requirement is specific: an existing paid customer must be able to sign in, see the correct booking and download its ticket without paying again.
“The database import finished” is an intermediate milestone.
On a call with a CTO, we put it this way: “A backup report tells you a copy was made. A restore test tells you how long the business is down and what it loses. Only the second belongs in a commitment to a customer.”
The CNIL’s continuity and recovery guidance (in French) recommends a continuity and recovery plan, even a brief one, that lists the people involved, and regular testing of backup restoration and of that plan. The application owner should agree the required journey with the technical operator before the exercise, including any acceptable reduced service.
Cloud tooling does not choose your acceptance criteria. AWS Backup documents a separate validation workflow after restore completion; the resource still needs service-specific checks.
The proposed rehearsal below reports no executed recovery or client case.
2. Follow the booking beyond its database row
For the training website, the customer action depends on several things:
| Dependency | What the rehearsal must establish |
|---|---|
| Operator and customer access | The operator can retrieve the recovery material; the intended test identity can use the restored account. |
| Application and configuration | A compatible release, settings, permissions and decryption arrangements can be recovered through the agreed procedure. |
| Booking and entitlement | The recovered account links to the correct paid booking and the corresponding right to download. |
| Ticket file | The actual bytes are available, not just a database reference. |
| External services and queued work | Payment state, outgoing messages and pending jobs have explicit boundaries and handling. |
Platform documentation can reveal omissions before the test. Supabase’s backup documentation, for example, states that database backups do not include objects stored via the Storage API, and that daily backups do not store passwords for custom roles. A restored database therefore does not, on its own, demonstrate recovery of a downloadable ticket or every access dependency.
Cybermalveillance’s backup guidance (in French) also addresses the software needed to use recovered data. The ANSSI backup essentials (in French) advise including installation media and business-application configurations in backups. The practical question for each dependency is where it comes from and who can recover it if the original environment is unavailable.
Record missing access or configuration as a dependency gap. A procedure that requires someone to copy an undocumented setting from production has not yet demonstrated recovery without production.
3. Contain the copy before application startup
An isolated hostname is insufficient if the recovered application still holds live credentials or can reach production services. Ask the technical operator to demonstrate the containment before starting workers, scheduled tasks or the web application.
Use a separate destination with restricted access and outbound connections limited to the approved test dependencies. Keep production routing unchanged. Replace or disable live integration credentials, inspect startup tasks and queues, and verify that the copy cannot write to production databases or storage.
Route application email to a test capture service. Use synthetic recipients and check other messaging routes, including provider-generated notifications. Disable scheduled sends and external callbacks until their test handling is established. A switch in the application interface is weaker evidence than the deployed configuration and an observed captured message with no live delivery path.
For payment simulation, use a separate sandbox and test credentials. Stripe’s testing documentation describes transactions that do not move funds when using its test environment. That does not isolate your application’s email or every provider notification. Check those settings separately and never load live payment credentials into the rehearsal.
Prefer a pre-existing synthetic booking included in the selected backup. Creating it after restoration would test new behaviour without showing that old state survived. If representative real data is necessary, agree access, handling, protection and deletion with the responsible owner; CNIL development guidance (in French) describes the relevant test-data precautions.
If containment cannot be established, stop before application execution and record the blocker. “Preproduction” is a label; the actual permissions and connections determine the boundary.
4. Rehearse the existing paid journey
Agree the scenario: the original application environment is unavailable, and recovery uses the named backup set and documented dependencies. Record which failures are simulated and which services remain available.
The operator retrieves the backup and required access through the planned route, restores into the contained destination, applies the compatible application configuration and restores the ticket files. Record backup identifiers, component versions, timestamps and each manual intervention.
Before enabling the journey, inspect pending work. An old “send confirmation” job should not resume against a real address. An unresolved payment attempt should not be retried merely because its application record predates the backup.
Then use the approved test identity to open the existing booking and download its ticket. Check the booking-to-account link, entitlement and file content. Attempt the same access with a different unauthorised test identity. A successful download and a correctly denied download establish different parts of the requirement.
Suppose the booking appears but the ticket is absent. Record the failure before recovering the file through the documented secondary route and repeating the check. Keep both observations. If the file was recreated manually, say so: that may be an acceptable recovery dependency, but it does not prove the original file backup was complete.
For a missing role or setting, also preserve the failure, correction and subsequent result.
The minimum we would accept is that one paid customer journey works on the restored copy: sign in, see the right booking, download the file. A home page that loads shows the web server started, not that the business came back.
5. Test a new purchase separately from recovered entitlement
The existing booking checks recovered state. A new simulated purchase checks whether the rebuilt application can process new work. Neither test replaces the other.
Use a fresh synthetic identity and the payment sandbox for the new purchase. Exercise the expected callback, inspect the new booking and capture its confirmation. Keep test payment identifiers separate from the restored live-provider references; a sandbox cannot confirm the real status of an old charge.
Agree acceptance before interpreting the results:
| Check | Evidence to retain | What remains outside it |
|---|---|---|
| Existing booking and ticket | Linked record references and protected, redacted journey evidence | Bookings outside the selected recovery point or sample |
| Unauthorised ticket request | Test identity, attempted action and denied result | Unexamined roles and access paths |
| New simulated purchase | Sandbox event, application transition and captured confirmation | Live payment settlement and live account configuration |
| Outgoing-action containment | Effective settings, connection restrictions and observed test destinations | Untested integrations and jobs |
There is a further business gap: a customer may have paid after the application’s recovered data point. The payment provider and restored application can then disagree. Name who would reconcile that interval and how access would be handled before reopening service. Do not replay charges or manufacture booking records to conceal the discrepancy.
6. Report observations separately from recovery promises
NIST’s contingency-planning guidance defines the recovery time objective, or RTO, as the maximum time a system can remain unavailable before the impact becomes unacceptable, and the recovery point objective, or RPO, as the point in time to which data must be recovered after an outage. It also covers recovery testing and the validation of recovered data and functionality. It is US federal guidance, not a French legal requirement.
For this exercise, agree the timing boundary and record milestones: operator access available, restore started, data loaded, application started, customer action accepted. Include waits and manual corrections. Report the selected and actually recovered data points across the database and files, with any inconsistency.
A single prepared rehearsal cannot establish a guaranteed recovery time under every incident condition. List what it did not test: unavailable identity provider, lost backup access, production DNS change, real payment reconciliation, load or loss of another region, for example.
Where we draw the line: we do not promise a recovery time before a rehearsal has measured one. Afterwards, we report the time it took under those conditions, not a guarantee for every incident.
It also does not establish recovery from compromise. The ANSSI backup essentials (in French) warn that, after an incident, backups may contain the compromise vectors, and advise restoring from trusted sources. A functioning copy cannot prove that an attacker has been removed; that requires a separate, appropriately scoped security response.
7. Accept the bounded result and assign the gaps
Ask for a short evidence record: the customer action, restored components, observed results, recovery milestones, failures, corrections and remaining unknowns. Each blocking gap needs an owner and another check after correction. Close down the temporary environment and handle its data and credentials according to the agreed retention plan.
The decision may be to accept this journey under the tested conditions, fund a missing dependency or withhold acceptance until a blocker is resolved. A green status is useful only when its boundary is visible.
If the wider question is whether to stabilise or rebuild, start with IZZY’s guide to a slow or fragile website. For ongoing ownership, long-term support provides the operating context; a recovery exercise needs its own agreed scope.
Plan the rehearsal with us
To scope that exercise with IZZY, bring the paid customer action, backup arrangement and external dependencies to the Cloud, DevOps & Platform service. Agree the rehearsal, acceptance evidence and correction work before treating it as part of your recovery commitment.
Sources and limits
Sources checked on 10 November 2026. The training website and rehearsal are illustrative. Apart from GitLab’s published postmortem, no restoration, timing measurement, payment test or IZZY customer result is reported. The cited platform limits apply to those platforms; a technical operator must adapt the exercise to the actual system. This article does not provide an active-incident response runbook.