Methods & evidence · Study
The same files are not a restored system
Every selected file matched. The useful next question was not whether that counted as success, but exactly which success had been tested.
A selected account of a historical engineering rehearsal, not a recovery runbook or a fresh restore. Private operational details and archive contents are deliberately omitted.
What has been recovered when every file matches?
In a practical reconstruction study on 12 November, I rebuilt a preserved static publication from independently acquired source. The result matched all 75 payload files, 7,370,302 bytes, by both size and SHA-256. A separate HTTPS readback matched the same payloads. A second independent acquisition and reconstruction matched again.
That is a useful result. It does not mean the system was restored.
The prerequisite that the first attempt exposed
The builder used Python's standard library, but part of its selection came from historical Git objects. The qualified Python image did not contain Git. The first attempt with the original manifest therefore failed.
Calling the builder dependency-free would have hidden that gap. Instead, the accepted recipe separated two stages: acquire the exact source and export three pinned historical blobs, then build offline from a derived local-source selection. The original builder and original manifest were preserved unchanged.
The successful claim is two-stage reconstruction, not successful execution of the original Git-dependent manifest inside that Python-only image.
What made the comparison informative?
- Acquire rather than reuse: source payloads and Git objects came from the remote repository, not the convenient working checkout.
- Prepare explicitly: each historical dependency was pinned and checked before the offline build.
- Compare the full selection: every expected path, size and hash was checked, rather than opening only the homepage.
- Test a wrong answer: deliberately changing one expected hash caused exactly that file to be reported as a mismatch. Two wrong-root controls were rejected before acquisition.
- Repeat and clean up: a second acquisition/build matched, and owned temporary workloads and disposable trees were removed without changing the live publication.
What that success does not establish
Remote availability, authorised authentication and some operator/runtime prerequisites were still present. This was not a simulated loss of all access. No owner-held encrypted backup was decrypted; no replacement host was started; no DNS, certificate or service restoration or failover was performed. Published asset bytes were reconstructed, not every optional generator rerun.
The recorded build function was quick, but its duration excluded acquisition, preparation and workload lifecycle. It would be misleading to present it as recovery time.
Identical bytes establish a particular recoverable publication. A functioning service needs additional dependencies, configuration and behaviour; complete recovery requires its own exercised path. These are different tests, not increasingly flattering names for the same result.
The record, and the question left open
The selected evidence summary records the counts, method and negative controls without exposing operational identifiers or private archive data. I checked the preserved receipts again for this edition; I did not rerun the historical reconstruction. The public summary is an account of those records, not an independently auditable copy of the entire archive.
The return question is practical: which parts must be reconstructed, which must actually run, and which still depend on access that an emergency might remove? Answering it needs a separately scoped recovery exercise, not a stronger adjective for a checksum pass.
For a different kind of record, read Keeping the grass able to change and What a reading leaves elsewhere. These are connections between questions about evidence, not a claim that software recovery and material memory share one theory.