Rclone crypt 远端完整性怎么核验？信任 --checksum 前先审计哈希

1. 固定范围，并画出三层拓扑

写清明文源、已配置的 crypt 远端，以及该 crypt 远端指向的底层存储路径。记录准确的 Rclone 版本、配置名、子路径、过滤规则，并注明源是本地路径还是另一个远端；不要暴露密码、经过 obscured 处理的凭据或令牌。

运行命令前先确认方向。在 `rclone cryptcheck source:path cryptedremote:path` 中，第二个端点必须是已配置的 crypt 远端，不能直接用它的底层原始存储路径。比较两个原始密文存储或两个解密视图回答的是不同问题，不能在不说明的情况下互相替代。

从权威源建立预期清单：对象数量、总字节数、过滤集合和已知排除项。这个分母能防止一份看似干净的日志掩盖根本没有进入检查的文件。

2. 证明加密后端能提供所需哈希

官方 cryptcheck 参考明确要求 crypt 目标的底层远端支持某种校验和。应核对具体后端和对象类型，不要假设只要存在 crypt 包装层就一定存在哈希。

使用当前 Rclone 版本支持的只读能力与元数据检查，并保存相关输出。小对象能取得校验和，并不能自动证明分段上传、分块或其他特殊对象也有相同覆盖。

如果 Rclone 报告无法检查哈希、后端没有兼容哈希，或某类对象缺少校验和，就停止对这些对象作出 cryptcheck 验收结论。记录准确的不支持数量，并为它们选择另一条验证路径。

3. 针对真正的问题选择比对方法

当权威源是明文、目标是 crypt 远端，而且底层后端能提供校验和时，使用 cryptcheck。本地源让 Rclone 在读取每个目标 nonce 后，在本地完成加密和哈希。

如果源是另一个远端，官方参考警告 cryptcheck 可能需要下载全部源文件。不要把同一条命令误认为廉价的服务端比较；先估算传输量、出口费用、时间和本地资源。

普通 `rclone check` 适合在普通端点之间做无修改的清单与共同哈希比较。它的 `--download` 选项可在无哈希时下载数据进行比对，但这是另一种高带宽方法。仅按大小比较可以作为清单信号，却不能证明字节完整性。

4. 全量检查前先运行小型 canary

选择有代表性的 canary 集合，包括一个小文件、一个较大文件、一个可在生产之外安全准备的同大小已修改文件，以及任何疑似哈希行为不同的对象类型。文件和路径都应避免敏感信息。

只对这个固定集合运行 cryptcheck，并分别写出 combined、match、differ、missing-on-source、missing-on-destination 和 error 报告。连同报告保存命令、起止时间、版本和退出状态。

严格按 combined 标记解释：`=` 表示两端对象相同，`-` 表示只在目标存在，`+` 表示只在源存在，`*` 表示内容不同，`!` 表示读取或哈希出错。感叹号不是内容不匹配，更绝不能计为已验证。

5. 扩大全量检查时不要削弱证据

canary 已证明预期哈希路径后，再用相同端点方向和过滤规则运行完整范围命令。保守设置 checker 并发，避免限速、内存压力或后端节流把覆盖错误淹没在背景噪声中。

明确 `--one-way` 是否符合恢复问题。它检查源文件是否在目标存在且匹配，但会有意忽略只存在于目标的额外对象。如果陈旧或异常密文也重要，就不能采用单向验收。

把报告作为不可变的运行证据保存。只重定向标准输出并不够，因为警告和 NOTICE 可能正好承载哈希不可用或发生降级的证据。

6. 在宣称“已验证”前对齐覆盖账本

每个源对象只计一次，归入匹配、不同、仅源存在、涉及读取或哈希错误，或因哈希不支持、被跳过而未验证的类别。明确计入已记录的排除项；仅目标存在的对象单列分支。同一对象在重叠报告中出现时不能重复计数。

完整通过要求：零差异、零意外缺失、零读取或哈希错误、零不支持对象，而且分母得到解释。命令退出状态与摘要只是辅助证据，不能替代对象类别账本。

如果数量无法对齐，先查明过滤规则、权限失败、非法名称、限速或无哈希对象，再缩小范围重跑。绝不能为了让百分比好看，把未解决对象挪入匹配总数。

账本类别: 匹配（`=`）; 含义: 源与加密目标已验证相同; 验收处理: 计入已验证

账本类别: 不同（`*`）; 含义: 两端都存在，但已验证内容不同; 验收处理: 失败并调查

账本类别: 目标缺失（`+`）; 含义: 源存在，目标无对应对象; 验收处理: 备份完整性失败

账本类别: 源缺失（`-`）; 含义: 目标存在额外对象; 验收处理: 除非有意排除，否则调查

账本类别: 读取/哈希错误（`!`）; 含义: 无法读取或计算哈希; 验收处理: 未验证；本轮失败

账本类别: 不支持校验和; 含义: 所需底层哈希不可用; 验收处理: 未验证；改用其他方法

7. 把传输安全与恢复信心分开

2026 年 7 月的社区案例说明，传输选项与验证必须分别留证：一条“无共同哈希”的 NOTICE 让基于 checksum 的同步退化为仅按大小判断，同大小修改一直保持陈旧，直到 cryptcheck 才暴露差异。应把它当作真实拓扑警告，而不是对所有后端的普遍结论。

cryptcheck 证明的是某一时刻所选源字节与加密目标对象等价。它不能证明源就是想要的历史版本、凭据一定可恢复，也不能证明应用级恢复会成功。

另做样本恢复测试：把样本恢复到隔离路径，通过预期配置解密，并在不覆盖源的前提下核对应用可见文件。cryptcheck 覆盖账本与恢复证据应分开记录。

8. 建立可交给支持人员且不泄密的记录

保留已脱敏拓扑、Rclone 版本、后端类型、准确只读命令、过滤规则、预期数量、各报告计数、不支持对象数量、退出状态和运行时间。注明源是本地还是远端，以及是否使用 one-way。

排除配置密码、令牌、账号标识和私有文件名。共享复现时，使用生成的测试文件和脱敏配置输出。

只有在端点方向、底层哈希能力、过滤规则、对象类型和报告分母都明确后才升级问题。这样维护者才能区分真实的 Rclone 缺陷、不可用校验和、高成本远端源路径或不完整清单。

常见问题

`rclone check` 会验证 crypt 远端的明文哈希吗？ 不会自动做到。官方 check 参考把 crypt 用户引向 cryptcheck，以比较加密文件的校验和。普通 check 仍可提供只读清单信号，`--download` 则是有传输成本的另一条内容比对路径。

cryptcheck 会下载每个文件吗？ 当源是本地明文时，Rclone 可在取得目标 nonce 后于本地读取并加密源。官方参考说明，如果把另一个远端作为源，可能需要下载全部源文件。

combined 报告中的 `!` 是什么意思？ 它表示 Rclone 在读取或计算源/目标哈希时遇到错误。它不是内容不匹配，错误解决前必须保持“未验证”状态。

`--one-way` 足够用于备份验证吗？ 只有当验收问题明确排除只在目标存在的额外对象时才够。one-way 要求源文件在目标存在并匹配，但会有意忽略目标上的额外文件。

一行成功摘要能证明每个加密字节都检查过吗？ 只有预期清单与所有报告类别完成对齐，而且不存在不支持的校验和、被跳过对象或读取/哈希错误时才可以。应保存带分母的覆盖账本，而不是只依赖一行成功信息。