Define the decision
Define the recovery target before the test: release version, required records, media, configuration and the journeys users must complete. Record the backup’s date, source and integrity evidence. Identify which secrets or external services are required without exposing them in reports. An archive’s successful creation is only one part of recoverability.
Build a usable record
Restore into an isolated, authorised test environment. Confirm that database references, file paths and application versions agree. Exercise a representative public route and a private workflow where the delivered system supports it. Check an exported record, uploaded media and permission boundaries. Prevent test jobs from dispatching real messages or changing production records.
Check the evidence boundary
Record what the test demonstrates and what it does not. A static site restore does not prove recovery of a separately hosted database or identity service. Runtime dependencies must remain available from commissioned production infrastructure when the development host is offline. Keep the last working release until replacement and restoration evidence are verified.
Worked example — illustrative
In a fictional test, an archive restores the web pages but several linked media files are absent. The report marks the release incomplete and identifies the missing storage snapshot. After correcting the backup scope, the team repeats the relevant media and navigation checks. It does not describe the first archive as a verified full-system backup.
Put the method into practice
Use the restore checklist to record environment, release, checks, failures, responsible owner and evidence location. Schedule follow-up according to the commissioned operating process. Leaf’s template is a planning and evidence record; it does not itself create backups, restore services or guarantee a recovery time.
- Define the recovery target.
- Restore in an isolated environment.
- Test records and dependencies.
- Retain evidence of failures and recovery.
