Backup existence is not restore evidence
A recent file can be incomplete or unreadable. Observability separates successful job completion, archive freshness, size, and restore-verification results. An untested backup should not be labeled recoverable solely because its timestamp is recent.
Destructive boundaries
Adoption never formats a disk or replaces existing data. Restoration is explicit and scoped. Copying an entire baseline over a running machine risks reverting unrelated updates and credentials, so missing-file recovery and targeted rollback are distinct mechanisms.
Failure ordering
If the tunnel fails, GitHub cannot perform normal SSH repair. If the host fails, the portal cannot serve diagnostics. Cloud history and the independently hosted wiki remain useful, but neither substitutes for a LAN or console recovery path.
Stale evidence
A collector may continue exporting an old success or failure. Compare the collection timestamp with the job timestamp and cloud-object evidence. Keep failed outcomes distinct from absent metrics, and never infer restore success from a nonzero archive size.