Create a local backup-and-restore rehearsal with checksums, recovery objectives and evidence that restored files match the fixture.
A fictional workshop keeps three small planning files. Backups are taken every 24 hours; the stated recovery-point objective is 24 hours and the recovery-time objective is 30 minutes. A local rehearsal restores into a new directory and compares hashes. No original file is deleted.
| File | Purpose |
|---|---|
| agenda.txt | session order |
| contacts.csv | synthetic contacts |
| checklist.txt | setup tasks |
Disaster-recovery architecture distinguishes the data-loss window from the time needed to restore service. The provider lesson uses Azure VMware as context; this project practices the concepts with local files and does not provision paid infrastructure. Define what must be recovered and how the result will be checked.
Write the recovery scope, RPO and RTO for the fixture.
Recovery objective sheet
Record your result and evidence here or in a separate file.
24 hours refers to the data window and 30 minutes to recovery time.
Label each objective with its meaning rather than only its acronym.
Record a file inventory and cryptographic checksums before packaging. A checksum detects byte changes; it does not prove the content is semantically correct. Keep the backup separate from the input directory and preserve timestamps in the log where useful. The reference only packages known fixture files.
Create the backup archive and a SHA256 manifest.
Backup and manifest
Record your result and evidence here or in a separate file.
All three expected files are present and the original hashes are recorded.
Compare the inventory with the intended recovery scope.
Restore into a newly created task directory and refuse to overwrite an existing destination. Validate archive paths before extraction so entries cannot escape the target. The exercise never deletes originals. Compare every restored file hash with the manifest and report missing or extra files.
Run the restore rehearsal and inspect the comparison report.
Restore evidence
Record your result and evidence here or in a separate file.
All three restored files match and no path outside the task directory is written.
Stop on an unsafe path or an existing destination.
A useful rehearsal includes a failure case. Modify one file in a separate restored test copy and confirm that the verifier detects it. A failed checksum should not be ignored because the filename looks right. Record the response and retain the original valid backup for comparison.
Alter the test-copy agenda and rerun verification.
Integrity-failure demonstration
Record your result and evidence here or in a separate file.
The changed file is reported as a mismatch.
Compare bytes or hashes rather than file names alone.
A runbook names the backup location, required tools, verification steps and decision owner. Timing a tiny local rehearsal does not establish a real system’s RTO. Record actual elapsed time only if measured and label the small scope. Plan periodic rehearsal without claiming that an external schedule was created.
Write the step-by-step recovery procedure and review checklist.
Recovery handoff
Record your result and evidence here or in a separate file.
The runbook distinguishes a planned objective from a demonstrated production recovery time.
Remove unsupported claims that the 30-minute objective was proven.
Deliver the fixture, archive, manifest, successful restore report, corrupted-copy detection and runbook. Explain what additional evidence would be needed for a real service recovery claim.
Restoration is isolated, originals remain intact and unsafe archive paths are rejected.
| Criterion | Points | Evidence |
|---|---|---|
| Evidence and correctness | 30 | Calculations, source use and results match the supplied case; limitations are honest. |
| Required artifacts | 30 | All five stage outputs and the capstone handoff are present and inspectable. |
| Reasoning and decisions | 20 | Choices, assumptions, alternatives and the case-specific critical condition are explained. |
| Reproducibility | 10 | A reviewer can follow the stated steps and distinguish expected from observed results. |
| Clear communication | 10 | Labels, units, structure and evidence references make the work easy to review. |
Score at least 80/100, supply every required artifact, and satisfy the path-specific critical condition. Rework missing evidence before marking complete.
A 24-hour backup interval can imply up to roughly 24 hours of lost changes under this simplified schedule, but missed backups would worsen it. Hash equality confirms byte-for-byte restoration of the three fixture files. It does not prove recovery of an application or its dependencies.
This is a local file-recovery rehearsal, not Azure deployment, a production backup or a validated business-continuity plan.