repo/verify发现损坏后怎么办？

仓库读取报错时，最危险的反应是立即运行带删除参数的修复。Kubo repo verify提供了一条更稳妥的顺序：先只读扫描并确定哪些块校验失败，再证明数据可从备份或网络恢复，最后才决定是否删除或heal。

默认模式是取证起点

repo verify逐块读取本地数据并按CID验证完整性；不带参数时是只读检查。

运行前保存Kubo版本、仓库路径、磁盘健康、进程状态、最近错误和备份点。只读检查仍会读取大量数据，可能产生I/O压力，因此要在维护窗口限制并发并监控磁盘延迟；不要把“只读”误解为“没有运行风险”。

输出中的每个损坏CID都进入事件清单，附首次发现时间、错误、是否被关键pin引用和是否存在远端副本。命令返回非零时保留原始退出码，不用统一的“任务失败”覆盖损坏已被发现这一事实。

—drop会删除损坏块，—heal会先删除再从网络重新获取，并隐含drop。

模式	是否修改仓库	前置条件	主要风险
verify	否	有足够I/O窗口	扫描期间性能下降
—drop	是，删除损坏块	已确认可丢弃或可恢复	唯一副本永久消失
—heal	是，删除后尝试重取	网络在线且有提供者	重取失败后仍保持删除

heal隐含drop，不能把它理解成“先复制一份再修复”。真正的保护来自事前备份、CAR副本、另一节点或可验证的远端提供者。执行前把恢复来源写进工单，而不是只写“网络上应该还有”。

只读模式发现损坏会返回非零退出码；heal无法重新取得某块时，该块会保持删除状态。

在独立节点查询provider并实际读取目标块，保存返回字节与CID校验结果。findprovs有结果但无法连接，或能连接却取不到块，都不满足heal前置条件。对DAG根还要遍历关键子块，不能只验证根CID。

如果数据属于业务唯一副本，优先从离线备份恢复到隔离仓库并验证，再安排生产修复。无法证明恢复来源时，保持原仓库只读、复制磁盘镜像并升级人工处置；不要让自动任务扩大损失。

暂停会持续写入仓库的批量导入与GC，确认只有一个受控修复任务操作同一数据目录。持续记录CPU、内存、磁盘队列和错误速率；超过资源阈值时安全停止，并确认仓库仍可重新打开。

Kubo RPC具备管理员权限。远程运维通过受控通道完成，不把5001端口直接开放公网；输入CID、仓库信息和日志也按最小必要范围分享，避免暴露内部拓扑或访问凭据。

第一层再次运行只读verify，确认损坏清单已经收敛；第二层读取受影响pin或DAG，核对内容哈希和业务字节；第三层从独立节点取回，确认提供与网络路径恢复。仅命令退出码为零不足以证明业务完整。

若有块无法heal，把结果标为部分恢复，列出缺失CID与受影响根，不要把整个任务显示为成功。恢复报告保留操作参数、版本、备份点、删除清单、重取来源和复验结果。

介质错误、异常关机、文件系统问题、同步软件干预或硬件故障都可能造成损坏。修好块并不等于根因消失；检查SMART、文件系统日志、电源与部署流程，必要时迁移仓库并更换介质。本文只提供防御性完整性处置，不包含攻击或绕过方法。

默认只读verify适合确认范围；drop和heal都是破坏性选择。没有备份、没有远端副本或无法接受数据缺失时，停止自动修复并转入人工恢复。

资料访问时间为2026-08-08。仍需按实际环境复核：能否heal取决于网络仍有提供者和可连接性；没有远端副本时不能承诺恢复。

相关站内主题：repo stat空间压力、dag stat共享大小、findprovs提供者排障。本文用于技术教育与防御性运维，不构成投资、收益、交易或资产安全承诺。