How to Check an Offline Diary Backup with File Checksums
To check that an offline copy of a digital diary matches its source byte for byte, create a SHA-256 checksum manifest and file inventory from the intended source, then verify the backup against that protected baseline. A matching checksum supports a claim about the bytes of listed files; it does not show that the list is complete, the original files were correct or readable, or that an untrusted baseline is authentic.
What a checksum check tells you
A checksum is a value calculated from a file’s contents. If the contents change, the calculated value is expected to differ. Comparing a backup against a reference value can therefore help identify changes during copying or storage. The Digital Preservation Coalition describes checksums as a way to check successful transfer and ongoing file fixity, and stresses comparison with a reference known to be correct ([Fixity and checksums](https://www.dpconline.org/handbook/technical-solutions-and-tools/fixity-and-checksums)).
The reference matters: if you calculate both the baseline and the comparison from the same already damaged copy, the match does not establish what the earlier file contained. A match also does not prove that a diary entry opens properly, that the source was complete, or who created the files. Treat this as a byte comparison for a deliberately chosen set of files.
Choose and record the source set
Identify a stable exported diary folder that should be backed up, and finish any edits before hashing it. This example covers regular files, including hidden files; it does not follow symbolic links or capture a live application database consistently. Export linked material into the selected folder when needed and check the application’s export instructions. Store the generated inventory and manifest outside that folder.
These examples require Bash and GNU findutils/coreutils, as on Ubuntu Linux; they are not commands for an unmodified macOS or Windows terminal. The example uses fictional local paths and new output filenames. Use an existing parent directory for the records; choose unused filenames so earlier baselines are not overwritten. Replace them with paths on your own computer; keep the private diary and generated records local. The Ubuntu manual documents `sha256sum` generation and its `--check` option for verifying a prior output ([sha256sum manual](https://manpages.ubuntu.com/manpages/noble/man1/sha256sum.1.html)).
```bash ( set -euo pipefail set -C cd "/home/example/Diary" find . -type f -print0 | LC_ALL=C sort -z > "/home/example/diary-inventory.nul" xargs -0 -r sha256sum < "/home/example/diary-inventory.nul" > "/home/example/diary-source.sha256" test -s "/home/example/diary-source.sha256" ) ```
The subshell stops on a failed directory change or pipeline, refuses to overwrite existing record files, and rejects an empty checksum manifest. If it reports an error, do not use partial outputs as a baseline. The inventory uses NUL separators so filenames containing line breaks remain distinct. Both records stay outside the selected folder. Review the source set against the diary export before trusting it; a manifest cannot reveal an attachment omitted before it was created.
Protect the baseline and copy the files
Store the manifest and inventory somewhere separate from both the working source and the offline backup. Protect them from accidental edits, and retain a second protected copy if practical. A checksum comparison only has value as a reference check when you have reason to trust and preserve the baseline. Preservation guidance likewise treats fixity information as something recorded and used for auditing; NARA describes recording fixities, tracking file actions, and creating manifests and logs in its digital preservation program ([National Archives digital preservation](https://www.archives.gov/preservation/digital-preservation/about)).
Copy the selected diary folder to the backup drive using your usual file-copy method. Keep the backup disconnected when it is not being checked. The commands here do not perform the copy; they check files already copied. Avoid editing, renaming, or reorganizing the backup before checking it, because path changes can prevent the manifest from finding the expected files.
Verify the copied bytes
Mount the offline drive and change into the copied diary folder. Run the check against the baseline manifest, using the same SHA-256 algorithm and relative paths recorded at the source:
```bash ( set -euo pipefail cd "/media/example/DiaryBackup/Diary" sha256sum --check --strict "/home/example/diary-source.sha256" ) ```
The manifest stores relative paths beginning with `./`, so verification runs from the copied diary folder. `OK` reports a match for that file. Missing or mismatching files, malformed checksum lines, and command errors require investigation; do not hide them with `--ignore-missing` or assume a few visible `OK` lines mean the entire check passed. The [Ubuntu manual](https://manpages.ubuntu.com/manpages/noble/man1/sha256sum.1.html) documents these options.
This check does not report additional files on the backup that were not in the manifest. Compare the backup’s file inventory with the saved source inventory as a separate step if you need to detect extras or unexpected directory contents. Inventory equality still cannot prove that your original selection included every diary item you meant to save.
Investigate mismatches without replacing evidence
If a file mismatches, record its path and keep both copies unchanged. Confirm the intended manifest and working folder, then compare the source and backup separately. Check whether editing, renaming or an incomplete copy explains the discrepancy. Preserve the mismatching copy while investigating; automatically overwriting it would remove evidence.
Digital preservation guidance describes using a known-good copy to replace a copy whose fixity has been lost, which depends on having another trustworthy copy available ([Digital Preservation Coalition](https://www.dpconline.org/handbook/technical-solutions-and-tools/fixity-and-checksums)). For a personal diary, that is a decision to make only after comparing the available evidence. Checksums detect differences; they do not repair files or choose the correct version.
Limits and a practical record
Keep a short local record of the source folder, baseline date, algorithm, manifest location and each check result. For later checks, retain the established baseline rather than recreating it from the backup being assessed. After an intentional edit or conversion, document the new version separately. Continue occasional opening and restore checks: byte fixity alone cannot tell whether your diary remains usable.