backup-restore-test-evidence
Use this at least once per review cycle the company has set, rotating across critical services, and after any major change to the backup setup. You get two documents in a new folder, ./backup-restore-test-evidence/: a test plan written before anyone touches a backup, with the service, the scenario and the pass criteria (test-plan.md), and after the test a record with the measured times, the results, the findings and a sign-off line for the system owner (test-record.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The reader's team runs the restore; the agent plans and records.
Inputs to gather
Read the business impact analysis or wherever recovery objectives are written (recovery time objective, how long the service may be down; recovery point objective, how much data may be lost), the backup policy, the architecture overview, and, read-only, the backup configuration and job history. Read earlier restore test records. Ask the reader, in one message: which service matters most if lost, who can run a restore, which isolated environment is available, and who signs off the result.
Step 1: choose what to restore
Pick the service with the tightest objectives or the most important data, and rotate to the next one in the following cycle so every critical service is tested over time. Restore what the business actually needs to run: the database, the file storage, the configuration and the secrets the application needs to start. Restoring one file proves the backup tool works; it does not prove recovery. Once a year, plan a restore into a clean environment that does not rely on anything in production, which is the situation after ransomware. List what the restored stack depends on (DNS, certificates, secret store, identity provider, email or payment endpoints) and which of those the test actually exercises.
Step 2: write the plan before the test
The test plan (test-plan.md) holds: the service and its objectives; the backup set to use and its age; the declared time of the simulated failure, so data loss is measured against a fixed scenario rather than the last convenient backup; the target environment, isolated from production, with its access controls stated; the people and their roles; open findings from the last test, to check; the success criteria, set now and not after the result is known (row counts within a stated tolerance, checksums, the application starts, a user can sign in, one business transaction completes); stop conditions; and how the restored copy is deleted or secured afterwards, because it contains production data. Get the system owner's approval of the plan before anything runs.
Step 3: record the run with timestamps
During the test, record times for: start, backup located, data retrieved, restore complete, application running, verification complete. Measured recovery time is start to verified. Measured data loss is the gap between the backup point used and the moment the simulated failure happened. Note every manual step, every missing piece of documentation, and every credential that only one person had.