Instruction 04-restic-or-borg-backup-implementation: Reading

A backup is useful only when its contents can be discovered, authenticated, restored, and compared with an expected state. Restic creates encrypted snapshots in a repository and uses content-defined chunking so unchanged data can be reused across snapshots. Deduplication reduces unnecessary duplicate storage, but it is not itself proof that a restore will work. The repository password is part of the recovery dependency: losing it makes the encrypted repository unusable, while exposing it allows anyone with repository access to decrypt the backups.

This lab deliberately backs up the absolute path /opt/lab-classroom/class73/data. Restic records that path in the snapshot. When the snapshot is restored with /opt/lab-classroom/class73/restore as the target, the source appears at /opt/lab-classroom/class73/restore/opt/lab-classroom/class73/data. It does not appear at /opt/lab-classroom/class73/restore/data. The lab therefore creates a source checksum manifest from inside the source directory, producing relative names such as alpha.txt. It then enters the actual restored data directory in a subshell and generates or checks the same relative names. The subshell prevents a directory change from leaking into later commands.

Verification has several layers. Snapshot JSON proves that both expected tags exist. Exact-content assertions provide an independent expectation for alpha.txt, beta.txt, and gamma.txt. A recursive file-list assertion detects missing or unexpected files. The normalized SHA-256 manifest detects byte-level differences between the source and restore. Finally, restic check --read-data reads repository data packs in addition to performing structural checks. A plain restic check is useful for repository structure and pack metadata or hash consistency, but it does not read every backed-up data blob. It must not be described as full verification of all backup data. Using --read-data is more thorough, although a real restore test remains essential because operational recovery includes path selection, credentials, permissions, and restore procedures.

Retention is separate from backup creation. The command restic forget --keep-last 1 --dry-run --json previews which snapshot would be removed while leaving the repository unchanged. The decisive evidence is a nonempty remove array in Restic's JSON output, followed by confirmation that the snapshot count remains unchanged. The Python program prints a sentence beginning with PASS only after inspecting that JSON. That PASS sentence is synthesized by the lesson's Python code; Restic itself does not print it. No prune or non-dry-run forget operation is performed in this lab.

The recovery workflow is intentionally fail-closed. A reset is first restored into reset-stage, and the staged absolute-path location is verified before the active source is moved. If restore or verification fails, the active source remains untouched. Clean reruns use a bounded quarantine under the class directory: the current repository and source are moved to repository.previous and data.previous, replacing only the corresponding older quarantine slots. All repository, cache, temporary, password, restore, evidence, and quarantine paths remain beneath /opt/lab-classroom/class73/.