Jule restore process and checksum verification gaps

Short answer

Based on the behavior you describe, the default restore path treats checksum comparison as opt-in, not built-in. That means a restore that completes "successfully" is confirming that bytes were written to the target volume — not that the written bytes match the manifest. There is no native notification for a file that is written but would fail an integrity check, because no implicit check is being run in the default workflow. The recommended fix is to treat verification as a separate, mandatory post-restore stage that you orchestrate yourself.

Important caveat: Jule is not widely documented in public sources, and I cannot confirm the exact flag names or manifest format for your version. Treat the commands below as patterns to adapt after checking your installation's administrator guide or --help output. The verification workflow itself, however, is tool-agnostic and sound regardless of Jule's specifics.

Why silent corruption goes unnoticed

A restore engine's success criteria is typically "all objects in the snapshot/layer set were reconstructed and written." Media errors, truncated incremental layers, or bit rot in the snapshot store can all produce files that exist, have plausible sizes, and still contain wrong bytes. Without a checksum pass, nothing in the pipeline compares the result against the recorded SHA-256 values, so the failure mode is invisible until an application reads the data later — the worst time to discover it.

Recommended verification pattern

Run the restore, then run an explicit comparison pass against the manifest before declaring the recovery complete and before letting any application touch the volume.

1. Restore to a staging mount, not the production path, so a failed verification never exposes corrupt data to consumers.
2. If Jule exposes a verify mode (check jule restore --help or the admin guide for a flag like --verify or a separate verify subcommand), enable it and capture its exit code and report.
3. Regardless, run your own manifest comparison so the check is independent of the tool that did the writing.

If the manifest is a list of <sha256> <relative/path> entries, a portable check looks like:

cd /mnt/restore-target
sha256sum -c /path/to/manifest.sha256 --quiet \
  | tee verify-failures.log
test ! -s verify-failures.log

Exit non-zero on any mismatch, missing file, or unreadable path, and wire that into your automation so the restore job is marked failed — not merely annotated. Also compare the manifest's entry count against the restored file count; a checksum pass alone won't flag files that were never written at all if the manifest itself is the only source of truth you iterate over.

Validating the gap before you rely on it

To confirm whether your version does any implicit checking, do a controlled test: restore a small known dataset, deliberately corrupt one restored file (flip a byte with dd), then re-run whatever the default restore/verify command reports. If the default workflow reports success on the corrupted tree, you've confirmed verification is not implicit, and the post-restore pass above is mandatory for your runbooks.

One detail that changes the recommendation: if your Jule version's manifest uses a structured format (JSON with per-file records) rather than a flat sha256sum-compatible list, share a redacted sample entry — the parsing step changes, but the staging-then-verify architecture stays the same.