Choose a recoverable business journey
Start with the information a customer needs to resume work, not a screenshot of the backup setting. For an invoicing product, recovery may require invoices, customer records, attachments and the links between them. List those components before the exercise. A database backup can have a different scope from file storage or external systems; Supabase explicitly documents limitations around stored objects. Verify the coverage of your actual provider and configuration.
Prepare an isolated destination
Plan a restore into a separate environment with controlled access. Prevent the recovered application from sending real emails, charging customers or triggering production jobs. Use an authorised operator and document the starting point. The exercise should test recovery without accidentally replaying business actions. Decide in advance which representative records can be inspected and how the restored copy will be protected and eventually removed.
Inspect relationships, not just row counts
Check a small set of meaningful workflows after restoration. Can the application open the invoice, resolve its owner and retrieve the expected attachment? Does a synthetic customer have the correct permissions? A row count helps detect gross omissions but does not establish that the product works. Record failures with the component involved so that the team can distinguish an application configuration issue from missing recovery data.
Measure the observed result
Record when the exercise began, when usable service was available and the latest information present in the restored system. Compare that observation with the recovery commitment the business intends to make. Do not substitute the provider’s advertised capability for a rehearsal of your own workflow. Include time spent finding credentials, reconstructing configuration and checking data, because those steps affect the actual customer interruption.
Make the next exercise easier
Update the runbook with the exact gaps found and assign owners. Rehearse again after material changes to data stores, encryption, storage or deployment architecture. A successful exercise is evidence for the tested conditions, not a permanent guarantee. The next person responding should be able to find the procedure and understand its limits without relying on the engineer who originally enabled backups.
Sources & further reading
Reference material for the guidance and examples above. Where included, community discussions provide context rather than verified incident evidence.
Retrospective weekly fieldnote, prepared with AI assistance and published on 12 September 2026. Examples are illustrative; this is not a client case study or a claim about events in the assigned week.