The short answer
Restore into a separate fresh folder and check the project you actually need, not just whether an archive opens or its declared hashes match. Confirm the intended version, required source files and a small real reading/recalculation task before replacing a working copy. Keep partial or wrong-version recoveries labeled as such.
What you’ll take away
- An intact backup can still contain the wrong version or omit a needed dependency.
- Keep the current working folder while checking the recovered copy separately.
- Reopen the source fields you need; file existence is only one check.
Define what you need to recover before opening the backup
For a recap, this might be the final draft, the source metrics, the chart’s editable brief and the source note behind a claim. Write the intended version and required dependencies before selecting an archive. A folder labeled “latest” does not tell you whether it contains the approved text, the same observation window or the files needed to make a later correction.
NCSC’s backup guidance says to know how to restore a backup and check that it contains important data. Our exercise applies that limited idea to a small original publishing package. It does not test a storage provider, device backup, account recovery or disaster response. Keep real private material within your authorized storage and access arrangements; the public packet uses only constructed files.
Recover to a separate target and preserve the current copy
Choose an empty new destination and keep the existing working files until the recovered package has been checked. If your restore route would replace the current folder, pause and use the tool’s separate-location option where available. Record a refusal or unavailable option rather than treating an overwrite as a necessary part of proving recovery.
Inspect the archive’s origin and contents before extraction. Python’s ZIP documentation describes reading members and checking archive CRCs; it also warns about extracting untrusted paths. Our supplied checker accepts no real archive or working-folder argument. It generates only its own tiny known fixtures in a fresh temporary directory, uses a fixed filename list and removes those scratch copies afterward. This is a bounded demonstration, not a general untrusted-archive security tool.
- Name the intended version and the files needed for one actual editing or reporting task.
- Keep the working copy and select a separate fresh recovery target.
- Recover only authorized material through the supported restore route.
- Compare recovered identities, version and required dependencies.
- Open the relevant draft/data and perform the declared reading or recalculation check.
- Record complete, partial, wrong-version or unresolved recovery before replacing anything.
Separate declared file identity from project readiness
A manifest can list filenames, sizes and hashes. Matching it helps answer whether the recovered bytes match those declarations. It does not establish who created the manifest, that it describes the intended version, that its source is true or that every needed dependency was listed. An internally consistent older package can pass that check perfectly.
Keep an independent task contract: intended version, required source list and a small check that uses those sources. W3C’s version-indicator and version-history guidance supports explicit dataset versions and explained changes; it does not certify our recovery procedure. For this exercise, the task needs V2, five named files, the original UTF-8 draft and a readable three-row CSV with 300 impressions at 24 hours.
| Check | What it can establish here | What remains outside it |
|---|---|---|
| ZIP CRC | Archive members match their stored CRC/header checks | Correct project, version or complete dependency list |
| Manifest bytes | Listed files match declared bytes and hashes | A truthful or complete manifest |
| Version and required list | The declared exercise’s V2 and five files are present | Truth or permission of their contents |
| Reading/recalculation | Original draft text, expected CSV fields and 300 total can be read | Compatibility with every professional editor or reader success |
The exercise’s task gate is deliberately explicit; it is not a universal definition of a complete backup.
Read every planned controlled result
Before running the checker, we fixed seven cases. A–F create six separate recovered copies from original constructed archives. G is a destination-protection check with no extraction. Each archive can have a clean ZIP CRC while still failing the declared file or task contract. We retain all cases rather than reporting only the successful copy.
A restores the complete V2 and passes both checks. B restores a complete V1 whose own manifest matches; it fails the intended-version task. C is missing a declared metrics file, and D has different metrics bytes; both fail identity and task checks. E omits a required source note from both archive and manifest; F has the wrong CSV headers but a matching manifest. E and F pass the manifest check yet fail the independent task.
G proposes an already occupied destination containing an original exercise marker. The checker refuses to extract there, and the marker’s bytes remain unchanged. This is an observed guard result, not a successful recovery and not a test on anyone’s real working files. Across A–F, four of six pass declared-byte checks, while only A meets the specified source-reading task.
| Case | Controlled condition | Declared bytes | Specified task |
|---|---|---|---|
| A | Complete V2 | Pass | Pass |
| B | Complete V1; matching own manifest | Pass | Fail: wrong intended version |
| C | Declared metrics.csv absent | Fail | Fail: required data missing |
| D | Metrics bytes differ | Fail | Fail: identity/data disagreement |
| E | Required note omitted from manifest and archive | Pass | Fail: dependency missing |
| F | Wrong CSV headers; matching manifest | Pass | Fail: source fields incompatible |
| G | Destination already occupied | Not executed | No extraction; original marker preserved |
These are six actual controlled copies and one actual guard check, not seven independent reader trials or a failure-rate estimate.
Reproduce the exercise without using a real backup
The download contains the protocol, the complete checker and observed results. With suitable Python already installed, run python3 check-restores.py in the extracted exercise folder. It creates original Markdown, CSV and JSON sources, constructs the declared cases, restores them into its own separate temporary folders, checks the results and deletes those temporary copies. No network, database, account access or additional package is required.
The saved result records the actual run time, Python version, protocol and script identities, and each case’s missing or mismatched fields. We ran it locally on 1 November 2026. Execution time describes that run only; it is not a provider benchmark or a claim about recovery time saved. The files were selected to show specific failure modes, so these counts cannot estimate how often real backups fail.
Close the recovery with a useful private record
Keep a minimal source reference, intended version, recovery destination, required dependencies, actual identity checks and the reading/recalculation result. Where a source is unavailable, retain that gap. A recovered export may be useful as a reference without restoring the editable source that produced it. A readable file also does not establish that its factual claim or permission is correct.
Decide whether to adopt the recovered copy only after the needed checks. Keep original and recovered versions distinguishable under your existing retention policy; do not delete a real backup merely because the exercise finished. The private worksheet leaves complete, partial, wrong-version, refused and unresolved states separate. The exercise does not establish reader success, customer outcomes or security certification.
Sources & product references
Product details reflect the publication date. External features and interfaces may change.
