恢复系统天生比备份系统更容易被忽视，RPO和RTO是规划的两把尺子

备份系统往往打磨得比恢复系统好得多，这不是偶然的疏忽，而是有结构性 原因：备份必然先于恢复存在，注意力天然会先集中在”怎么把备份做出来” 上；备份是靠脚本和定时任务日常自动运行的，容易被顺手调优，而恢复 往往只在真正的危机时刻才会被使用，平时没有同等的重视和演练；唯一 熟悉整套备份/恢复设计的人，灾难发生时未必在场。书中给出一个真实的 警示案例：某客户发现给mysqldump加上-d选项后备份速度快得惊人， 一直很满意却从没有人指出为什么——因为-d选项的实际效果是”只导出 表结构、不导出任何数据”，这份”高效”的备份其实完全没有数据可以恢复， 只是因为从没有人真正尝试过用它做一次还原，这个致命问题才一直没有 暴露。规划备份/恢复策略时，与其从”怎么备份”这个角度想问题，更该先 从”允许损失什么、能等多久”这两把尺子来倒推：恢复点目标（RPO）回答 “能容忍丢失多少时间跨度的数据”（是必须做到故障发生前那一刻，还是接受 丢失自上次日常备份以来的所有工作）；恢复时间目标（RTO）回答”恢复过程 本身允许花多长时间完成”。把这两个目标先明确写下来、形成文档，再倒推 需要什么样的备份频率、备份方式和恢复流程，能避免”备份方案看起来很 完善，但从未验证过它真的能在需要的时间窗口内、恢复到需要的时间点” 这类隐患——而验证的唯一办法就是定期真的做一次恢复演练，而不是只 观察备份任务本身是否顺利跑完。