A checksum review tests whether archived bytes still match a trusted baseline. It does not prove that a file was correct when first archived, and a checksum stored beside the files is not protection against an attacker who can change both. Use checksums as one layer in a preservation process that also includes independent copies, access control, metadata, and recovery testing.
Define the archive set
List the files and folders in scope, archive identifier, owner, storage locations, expected file count and size, checksum algorithm, manifest path, baseline date, verification schedule, and escalation owner. Freeze or version the set before calculating the baseline so ordinary edits do not look like silent corruption. Include filenames and relative paths in the manifest, not only hashes.
The Library of Congress describes routine data-integrity reviews that compare files with cryptographic hash values and notes that BagIt structures contain checksum manifests; see its data integrity management guidance. RFC 8493 defines BagIt manifests that map file paths to checksums and distinguishes a complete bag from a valid bag whose manifest checksums all verify. The RFC also warns that checksum manifests are designed for confidence against corruption, not by themselves for defense against active tampering.
Create a trustworthy baseline
- Scan the source set for expected files and obvious transfer errors.
- Generate a manifest with a currently supported algorithm and record the exact tool and version.
- Verify the manifest immediately against the same set before calling it the baseline.
- Store a protected copy of the manifest separately from at least one archive copy.
- Record the baseline date, source, operator, file count, total bytes, and any intentional exclusions.
Verify without overwriting evidence
Run checks read-only. Test after migration, restoration, media replacement, synchronization faults, or unexpected shutdowns, as well as on a schedule appropriate to the archive. Capture the tool result, time, storage copy, manifest version, and counts of missing, unexpected, and mismatched files. Do not regenerate the baseline merely because verification fails; that would erase the evidence needed to investigate.
Handle mismatches
Quarantine the affected copy, confirm the manifest itself is trusted, and compare another independently stored copy. Determine whether the cause is corruption, an incomplete transfer, an authorized update, filename normalization, or a path change. Restore only from a verified source, then rerun the complete manifest rather than checking one repaired file in isolation. Preserve the original failure record.
Review the procedure when algorithms, tools, storage providers, operating systems, or filename conventions change. A useful archive log shows that checks were performed and that a clean result refers to a specific manifest and copy. The checksum value alone is not the preservation program; repeatable verification and recoverable independent copies make it operational.
Sources
- Data Integrity Management — Library of Congress
- RFC 8493: The BagIt File Packaging Format — RFC Editor, Oct. 1, 2018