R2与restic备份监控：从保存成功到恢复验证

备份任务结束不代表所需数据可以恢复。本案例将内部运维经验一般化，分别评价保存、完整性、恢复和服务恢复，并非从另一备份服务完成迁移的案例。

固定snapshot ID和一个恢复目标

记录待验证的snapshot ID，将所需文件恢复到空的隔离目录。配置应检查引用位置与权限，数据库应在隔离环境测试加载，并记录用时。定期重复同样的检查，才能比较备份新鲜度与可恢复范围。

restic：恢复到隔离位置的步骤

定义数据来源和成功

方案使用restic加密与去重，通过R2的S3兼容API保存。所需操作应对照兼容表确认。对运行中的数据库，按需设计导出或暂停应用写入等一致性获取方式。

独立监控新鲜度

分别跟踪最新成功快照、延迟、失败，以及完整性和恢复检查结果。任务启动不等于成功，通知失败也需与备份失败区分。

检查完整性与提取

默认restic check与读取实际数据的检查范围不同。--read-data读取全部数据，部分检查则记录其范围。结合仓库检查、向隔离位置恢复，以及内容或哈希比对。提取文件并不验证应用启动。

通过restic管理保留

按restic保留策略选择快照，使用forget、prune、check，执行前确认将保留的内容。按对象年龄在R2统一删除可能破坏保留快照所依赖的共享数据。应遵循保留文档，不要与图片分发等其他用途的对象清理混淆。

剩余恢复检查

已进行定期运行、监控通知、保留处理和选定数据的提取及完整性检查。所有应用启动、配置和依赖恢复、独立保管凭据的取回仍需端到端验证；恢复时间和可接受的数据损失也需实测。本文不宣称完整灾难恢复或已证实的费用节省。

1. 1 成功快照与新鲜度 检查实际成功快照的时间及相对计划的延迟。仅启动作业不算成功。
2. 2 完整性与隔离恢复 记录检查范围，在独立位置运行 restore --verify，并核对目标文件与 hash，然后再检查保留策略和 prune。
3. 3 完整灾难恢复 所有应用启动、依赖数据和单独保存的凭据恢复仍未验证。恢复时间和可接受的数据损失也未测量。

2026年10月6日补充：过期lock与恢复检查占用

追加改进在同一主机取得操作独占权后使用普通 restic unlock，只处理过期lock，不用 --remove-all 清除活动lock。用有上限的 --retry-lock 处理竞争，恢复检查与prune失败后不无限重启。主机内独占不能单独证明没有其他主机竞争。

以 restore --verify 恢复到隔离的临时目录，检查目标所需文件与一致性后，记录验证snapshot及对应配置。先确认恢复，再检查保留目标并prune。备份新鲜度依据实际成功的snapshot，而不是启动或重试。

目标数据取出与包含所有应用启动、凭据恢复的完整恢复仍是不同范围。维护窗口及获取失败的处理见监控与故障调查。