1. 课程导入与恢复目标设定

在开始学习任何备份工具或恢复命令之前，必须先回答一个更根本的问题：我们到底要防什么、恢复到什么程度、能容忍多长时间的数据丢失？如果这个问题没有答案，备份策略就只能靠"多备一点、多留几份"来碰运气，既浪费存储，又无法在真正出事时给出可验证的承诺。本章的目标，是建立一套可量化、可沟通、可验收的恢复目标语言，让后续所有备份方案、演练计划和容灾架构都有明确的判断依据。

备份恢复与灾难恢复不是同一件事

初学者最容易混淆的两个概念是"备份恢复"和"灾难恢复"。它们共享同一批数据副本，但关注的问题层次完全不同。

备份恢复（Backup & Restore）解决的是"数据被误删、被改错、被逻辑损坏之后，如何把数据找回来"。它的典型场景是：运维误执行了 DELETE FROM orders WHERE ...、程序缺陷写入了错误数据、勒索软件加密了文件。此时生产系统本身还在运行，机房、网络、服务器都正常，问题只出在数据层面。备份恢复的核心动作是"从历史副本中取回正确版本"，恢复范围通常是一个库、一张表、一批文件。

灾难恢复（Disaster Recovery，DR）解决的是"整个生产环境不可用了，如何让业务重新跑起来"。它的典型场景是：机房断电、存储阵列损坏、区域级网络中断、核心数据库主机彻底宕机。此时问题不是"数据错了"，而是"系统没了"。灾难恢复的核心动作是"在另一个可用环境重建服务能力"，恢复范围是整个业务系统，包括计算、存储、网络、依赖服务和数据。

两者的关系可以这样理解：备份恢复是灾难恢复的数据基础，灾难恢复是备份恢复的场景延伸。没有可靠备份，灾难恢复就是无源之水；但只有备份、没有切换和重建能力，遇到机房级故障时依然无法恢复业务。因此，一个完整的恢复体系必须同时覆盖"数据可回退"和"服务可重建"两条路径。

三个必须量化的恢复指标

把恢复目标从口号变成可验收的承诺，靠的是三个指标：RPO、RTO 和 MTTR。它们分别回答三个不同的问题。

RPO（Recovery Point Objective，恢复点目标）回答"最多能丢多少数据"。它用时间来度量数据的新旧程度：如果 RPO 是 15 分钟，意味着灾难发生时，我们最多接受丢失最近 15 分钟内产生的数据，恢复后的数据状态至少要是 15 分钟前的。RPO 直接决定备份频率和日志归档间隔——要满足 15 分钟 RPO，就必须有不超过 15 分钟一次的数据保护手段，例如每 15 分钟一次增量备份，或持续归档数据库日志。

RTO（Recovery Time Objective，恢复时间目标）回答"最多能停多久"。它从故障发生那一刻开始计时，到业务重新可用为止。RTO 是 30 分钟，意味着从宕机到服务恢复必须在半小时内完成。RTO 决定的是恢复架构：本地磁盘恢复可能只要几分钟，从异地磁带取回可能要几小时，主备切换可能只要几十秒。RTO 越短，对冗余架构和自动化切换的要求越高，成本也越高。

MTTR（Mean Time To Repair，平均修复时间）回答"我们实际能做到多快"。它是历史恢复事件耗时的统计平均值，是实测值而非目标值。RTO 是承诺，MTTR 是兑现能力。如果某系统 RTO 定为 30 分钟，但过去三次真实恢复分别用了 25、40、55 分钟，MTTR 约为 40 分钟，说明当前能力尚未稳定达标，必须通过演练找出瓶颈并改进。判断恢复能力是否合格的核心不等式是：MTTR ≤ RTO。

需要特别强调：RPO 和 RTO 不是技术参数，而是业务决策。它们应该由业务方根据损失承受能力来定，再由技术方评估实现成本。一个订单系统丢 15 分钟订单和丢 2 小时订单，业务损失差异巨大；一个内部报表系统停 4 小时可能完全可接受。因此，恢复目标必须按业务系统分级设定，而不是全公司一刀切。

如何为业务系统定义恢复目标

定义恢复目标的过程，本质是把业务影响翻译成技术指标。可以按以下思路推进。

第一步，识别业务系统并分级。先列出所有需要保护的系统，按业务重要性分为核心、重要、一般三级。核心系统如交易、支付、订单，直接产生收入或影响合规；重要系统如客户管理、库存，短时中断可容忍但影响较大；一般系统如内部报表、测试环境，可接受较长中断。

第二步，评估数据丢失与中断的业务代价。对每个系统问两个问题：丢失最近 1 小时数据会造成什么后果？停机 1 小时会造成什么后果？答案可能是收入损失、客户投诉、监管处罚、数据不可重建等。这一步的输出是业务方对 RPO 和 RTO 的初步要求。

第三步，把要求转化为可实现的技术指标。业务说"不能丢订单"，技术要追问"是 1 分钟都不能丢，还是 5 分钟可以接受"。业务说"尽快恢复"，技术要追问"是 15 分钟还是 2 小时"。模糊表述必须被逼成具体数字，否则无法设计也无法验收。

第四步，评估成本并确认平衡点。RPO 越接近 0、RTO 越短，所需的技术投入越高。把每个系统的目标与预估成本并列，与业务方共同确认最终值。确认后的目标应写入文档，作为后续备份策略和演练验收的依据。

下面给出一份可直接参考的恢复目标定义示例表。表中数值为教学示例，实际项目应根据业务评估结果填写。