Technology · PRACTICAL GUIDE
Rclone crypt remote integrity check? Audit hashes before trusting --checksum
A successful command is not the same as complete verification. Prove the crypt topology and backend hash capability, choose cryptcheck or download comparison deliberately, capture every report class, and keep errors or unsupported objects out of the verified total.
An encrypted backup can look healthy while its verification has quietly degraded to names, sizes or an incomplete set of objects. That risk is highest when a plaintext source, a crypt wrapper and an underlying storage backend are treated as one endpoint even though they expose different hashes.
Rclone's dedicated cryptcheck command crosses that boundary by reading each destination object's nonce, encrypting the source file with the same nonce and comparing the resulting ciphertext checksum with the checksum exposed by the underlying encrypted backend. The method is strong only when that backend actually provides a usable checksum for every object being counted.
The integrity-comparison stage is read-only: it does not sync, copy, purge or delete remote data. A separate sampled restore is a different operation and must use an isolated path. Every in-scope object must end in exactly one recorded class; a read/hash error, unsupported checksum, skipped object or unexplained count prevents a claim of complete verification.
1. Freeze the scope and draw the three-layer topology
Write down the plaintext source, the configured crypt remote, and the crypt remote's underlying storage path. Record the exact rclone version, configuration names, subpaths, filters and whether the source is local or another remote. Do not expose passwords, obscured credentials or tokens.
Confirm the direction before running a command. In `rclone cryptcheck source:path cryptedremote:path`, the second endpoint must be the configured crypt remote, not its raw underlying storage path. Comparing two raw ciphertext stores or two decrypted views answers a different question and cannot be substituted without saying so.
Create an expected inventory from the authoritative source: object count, total bytes, filter set and any known exclusions. That denominator will later prevent a clean-looking log from hiding files that never entered the check.
2. Prove that the encrypted backend can supply the required hash
The official cryptcheck reference requires the underlying remote of the crypt destination to support some checksum. Verify the backend and object class rather than assuming that the crypt wrapper's existence provides a hash.
Use read-only capability and metadata inspection appropriate to the installed rclone version, and save the relevant output. A checksum available for small objects does not automatically prove the same coverage for multipart, chunked or otherwise special objects.
If rclone reports that hashes could not be checked, if the backend exposes no compatible hash, or if a class of objects lacks checksums, stop the cryptcheck acceptance claim for those objects. Record the exact unsupported count and choose a separate verification path.
3. Choose the comparison method for the question you actually have
Use cryptcheck when the authoritative source is plaintext and the destination is a crypt remote whose underlying backend exposes a checksum. A local source lets rclone encrypt and hash locally after reading each destination nonce.
If the source is another remote, the official reference warns that cryptcheck can involve downloading all source files. Estimate transfer, egress, time and local resource costs before treating the same command line as a cheap server-side comparison.
Use ordinary `rclone check` for a non-destructive inventory and common-hash comparison between ordinary endpoints. Its `--download` option compares downloaded data when hashes are unavailable, but that is a separate bandwidth-heavy method. Size-only comparison is a useful inventory signal, not byte-integrity proof.
4. Run a small canary before the full read-only check
Select a representative canary set that includes a small file, a larger file, a same-size changed file if one can be prepared safely outside production, and any object class suspected of different hash behavior. Keep the files and paths non-sensitive.
Run cryptcheck only on that fixed set and write separate combined, match, differ, missing-on-source, missing-on-destination and error reports. Preserve the command, start and end times, version and exit status with the reports.
Interpret the combined markers literally: `=` is an identical object, `-` exists only at the destination, `+` exists only at the source, `*` differs, and `!` means a read or hashing error. An exclamation mark is not a mismatch and never counts as verified.
5. Scale the check without weakening the evidence
When the canary proves the intended hash path, run the full in-scope command with the same endpoint direction and filters. Set checker concurrency conservatively enough that rate limits, memory pressure or backend throttling do not turn coverage errors into background noise.
Decide whether `--one-way` matches the recovery question. It verifies that source files exist and match at the destination but intentionally does not report extra destination-only objects. If stale or unexpected ciphertext matters, do not use one-way acceptance.
Keep the reports as immutable run artifacts. Redirecting only standard output is insufficient if warnings and notices carry the evidence that a hash was unavailable or a fallback occurred.
6. Reconcile a coverage ledger before saying verified
Reconcile each source object exactly once: matched, different, source-only, affected by a read/hash error, or unverified because its hash is unsupported or it was skipped. Account explicitly for documented exclusions. Destination-only objects are a separate branch; overlapping reports must not double-count an object.
A complete pass requires zero differences, zero unexpected missing files, zero read or hash errors, zero unsupported objects, and an explained denominator. The command's exit status and summary are supporting evidence; they do not replace object-class accounting.
If counts do not reconcile, narrow the scope and rerun only after identifying filters, permission failures, invalid names, rate limits or objects without hashes. Never move an unresolved object into the match total to make percentages look complete.
Ledger class: Match (`=`); Meaning: Source and encrypted destination verified identical; Acceptance treatment: Counts as verified
Ledger class: Different (`*`); Meaning: Both exist but verified content differs; Acceptance treatment: Fail and investigate
Ledger class: Missing on destination (`+`); Meaning: Source exists without destination object; Acceptance treatment: Fail backup completeness
Ledger class: Missing on source (`-`); Meaning: Extra destination object; Acceptance treatment: Investigate unless intentionally excluded
Ledger class: Read/hash error (`!`); Meaning: Data could not be read or hashed; Acceptance treatment: Unverified; fail the run
Ledger class: Unsupported checksum; Meaning: Required backend hash is unavailable; Acceptance treatment: Unverified; use another method
7. Separate transfer safety from restore confidence
The July 2026 community incident shows why transfer options and verification need separate evidence: a no-common-hash notice allowed a checksum-driven sync to fall back to size-only, and a same-size edit remained stale until cryptcheck exposed the difference. Treat such a report as a real topology warning, not a universal claim about every backend.
Cryptcheck proves equivalence between the chosen source bytes and encrypted destination objects at one time. It does not prove that the source is the desired historical version, that credentials can be recovered, or that an application-level restore will succeed.
As a separate recovery test, restore a sample into an isolated path, decrypt it through the intended configuration, and validate application-visible files without overwriting the source. Record the cryptcheck ledger and restore evidence separately.
8. Build a support-ready, non-secret record
Retain the sanitized topology, rclone version, backend types, exact read-only command, filters, expected counts, report counts, unsupported-object count, exit status and run timestamps. Include whether the source was local or remote and whether one-way mode was used.
Exclude configuration passwords, tokens, account identifiers and private filenames. When sharing a reproduction, use generated test files and redacted configuration output.
Escalate only after the endpoint direction, backend hash capability, filters, object classes and report denominator are explicit. That lets maintainers distinguish a real rclone defect from an unavailable checksum, a costly remote-source path or an incomplete inventory.
Frequently asked questions
Does `rclone check` verify a crypt remote's plaintext hashes? Not by itself. The official check reference directs crypt users to cryptcheck for encrypted-file checksum comparison. Ordinary check can still provide read-only inventory signals, and `--download` is a separate content-comparison path with transfer cost.
Does cryptcheck download every file? With a local plaintext source, rclone can read and encrypt the source locally after obtaining the destination nonce. The official reference says using another remote as the source can require downloading all source files.
What does `!` mean in the combined report? It means rclone hit an error reading or hashing the source or destination. It is not a content mismatch and must remain unverified until the error is resolved.
Is `--one-way` enough for backup verification? Only if the acceptance question excludes extra destination-only objects. One-way checks require source files to exist and match at the destination but intentionally do not report extra files on the destination.
Can a successful summary prove every encrypted byte was checked? Only when the expected inventory reconciles with the report classes and there are no unsupported checksums, skipped objects or read/hash errors. Keep a denominator-based ledger rather than relying on a single success line.
