CBR 备份不是摆设：一次恢复演练暴露的三个问题

一、备份成功不等于能恢复

控制台上「最近备份成功」的绿色标记只能说明备份任务跑完了，不能说明这份备份可以被还原成可用业务。真正的判据只有一个：在隔离环境里把备份恢复出来，并让业务跑起来。我们这次演练的目标很明确——不追求全量恢复，只验证核心库与文件服务能否在预定时间内回到可服务状态。

二、第一个问题：恢复点选错了

按时间排序挑「最新」看似稳妥，实际踩了坑：最新备份发生在一次批量导入之后，数据本身是脏的。正确做法是按业务事件选点——选在批量任务开始之前的那一份，并在恢复前确认该备份的完成时间与业务时间线对得上。备份列表里的「完成时间」和「数据时间点」不是一回事，这一点必须在演练中确认过一次，否则真出事时一定选错。

三、第二个问题：恢复网络的带宽被忽略

恢复不是瞬间完成的，数据要从备份存储读出来再写回云硬盘。演练中我们按 200GB 估算，实际耗时比预期长了近一倍，原因是恢复流量与线上业务共用同一条出口，被限速。建议单独规划恢复网络，或在业务低峰执行，并把恢复速率上限显式配置，避免恢复过程把生产链路拖垮。

四、第三个问题：权限边界不清

备份属于高敏感资产，能创建备份的人不一定应该能删除备份。演练里发现运维账号同时具备创建与删除权限，一旦误操作，恢复点会被直接清掉。最小化的做法是把「创建」「恢复」「删除」拆成三个策略，删除动作单独审批，并对备份桶开启版本控制与对象锁，防止被批量清理。

五、演练之后要固化的东西

• 恢复点的选择规则写进 Runbook，按业务事件而不是按时间排序。
• 恢复耗时按真实带宽重算，写进 RTO，而不是照抄厂商标称值。
• 权限按动作拆分，删除类操作单独审批并留痕。
• 每季度至少一次真实恢复，演练记录与结论归档。

备份体系的价值不在备份本身，而在恢复那一刻能不能用。把这三件事固化下来，比多买几 TB 备份空间有用得多。