灾难恢复的基本概念
1.1 定义与目标（RTO、RPO、业务连续性）
灾难恢复（Disaster Recovery，DR）是一套在突发事件发生后，保障关键系统与数据在预定时限内恢复可用、并把业务中断影响控制在可接受范围内的方法、流程与技术组合。其核心不在于“是否做了备份”，而在于恢复能力是否经过验证、是否能在真实压力下按预案执行。
在实践中，常用两项目标来描述恢复效果：
- RTO（Recovery Time Objective，恢复时间目标）：从灾难发生到业务恢复到可运行状态所允许的最大时间。RTO决定了组织需要采用的容灾强度、自动化程度与恢复顺序。
- RPO（Recovery Point Objective，恢复点目标）：允许丢失的数据时间跨度或数据量上限。RPO决定了备份频率、复制延迟与数据一致性处理策略。
- 业务连续性（Business Continuity）：强调在中断发生时仍维持关键业务能力。DR通常是实现业务连续性的一部分，但业务连续性还可能覆盖人员、流程、替代工作方式等更宽的范围。
DR的目标可以概括为：在满足RTO/RPO的前提下，尽快恢复关键能力，并让恢复过程可预测、可度量、可审计。
1.2 与备份、容灾的关系
DR、备份与容灾常被放在同一讨论框架中，但三者侧重点不同。
- 备份：解决“数据丢失后如何恢复”的问题，通常以数据副本为核心。
- 容灾：解决“灾害发生后如何继续提供服务”的问题，包含基础设施、网络、应用、数据等多层能力，强调可用性和切换能力。
- 灾难恢复（DR）：把备份、容灾、流程与演练串联起来，形成端到端的恢复方案与治理体系，强调在现实故障下能否按预案恢复业务。
可理解为：备份提供素材，容灾提供承载环境，DR则规定“如何在事件发生时把素材装进承载环境，并在时间目标内交付业务”。
1.3 常见灾难类型与影响面
灾难并不只指自然灾害。通信技术与IT基础设施场景中，常见影响来源包括：
- 自然与物理事件：例如机房断电、温湿度异常、设备故障、区域性停电或灾害导致的基础设施不可用。
- 系统与平台故障：数据库损坏、存储阵列失效、虚拟化平台不可达、操作系统或中间件失灵等。
- 网络与连接中断：路由变更错误、跨域链路故障、域名解析异常、VPN或专线中断等。
- 安全事件与恶意行为：勒索软件导致的加密破坏、账户被盗后的篡改、数据被清除等。
- 人为误操作：配置错误、误删、错误的发布回滚、批处理执行失误等。
影响面通常不仅是“系统是否还在”，还包括：数据是否完整可用、恢复后业务是否可达、性能是否满足需求、以及恢复过程中是否产生额外风险（例如安全事件扩散）。
1.4 灾难恢复的关键原则
高质量DR方案通常遵循以下原则：
- 可用性优先：面向业务目标确定恢复顺序与资源配置，而不是单纯追求技术指标最大化。
- 可验证的恢复能力：通过演练、自动化测试与恢复链路验证，证明“按计划能恢复”。
- 分层保护与最小化恢复依赖：数据保护、计算资源、网络连通与访问控制要分层设计，减少单点依赖。
- 一致性与时间点控制：恢复并非只把数据“还原到某个时刻”，还要处理应用层一致性、事务边界与时序要求。
- 安全与完整性贯穿恢复全过程：恢复期间同样需要访问控制、审计与数据验证，避免“恢复了但引入新问题”。
- 持续改进与配置可治理：DR不是一次性工程，随着系统变化与风险演化，需要定期更新计划与度量。
灾难恢复的体系架构
2.1 备份策略与数据保护层次
DR的基础通常来自数据副本与保护层次。架构设计上，常见做法是把“备份类型、频率、存储介质、保护强度”组合成可执行的保护方案。
2.1.1 完整备份、增量备份与差异备份
三类常见备份策略在恢复效率与存储占用之间存在权衡：
- 完整备份：恢复路径通常更直接，但存储成本与备份窗口压力较大。
- 增量备份：只记录自上次以来的变化，存储更省，代价是恢复时需要按时间链路逐步拼接，恢复步骤更复杂。
- 差异备份：记录自上次完整备份以来的变化，介于两者之间：恢复时通常少于增量的链路复杂度，但比完整备份更省资源。
在通信与IT基础设施场景中，策略选择往往取决于RPO、备份窗口、恢复人员技能与自动化能力。
2.1.2 备份加密、签名与不可篡改思路
为了避免备份本身成为攻击目标，数据保护通常会加入更强的安全机制：
- 加密：在传输与存储阶段保护机密性，减少数据泄露风险。
- 签名或校验：用于检测备份内容是否被篡改，提升恢复时的数据可信度。
- 不可篡改思路（如保留/锁定策略）：通过权限与生命周期控制，降低“删除或覆盖备份”的风险，使恢复更具确定性。
需要强调的是：安全不是“加在最后”。备份的加密密钥管理、签名校验流程与恢复时的验证动作，都应纳入DR演练与验收范围。
2.2 复制与同步机制
备份偏向“事后恢复”，复制偏向“接近实时的可用性”。在DR架构中，两者常结合使用。
2.2.1 近实时复制与一致性要求
近实时复制通常通过较短延迟把数据持续同步到远端，目标是把恢复点误差缩小到可接受范围。其挑战在于一致性：
- 复制延迟决定RPO表现。
- 一致性要求决定恢复时能否正确重建应用状态，例如事务边界、索引与日志位置等。
- 故障场景下的恢复策略需要清晰：复制中断时如何选择恢复点、如何处理未完成写入。
因此，复制机制不仅是技术开关，更与应用架构与数据模型强绑定。
2.2.2 异步复制与恢复窗口取舍
异步复制允许写入在本地提交后再异步传输到远端，优点是对生产写入性能影响相对可控。缺点是：
- 远端可能落后于本地，灾难发生时丢失量取决于复制延迟。
- 恢复窗口（需要完成复制补齐、启动服务与一致性修复）可能更长。
在设计时，组织通常会以RTO/RPO目标为约束，评估异步复制带来的恢复点偏差是否可接受，并把补救措施（例如日志回放策略或一致性检查）纳入计划。
2.3 容灾部署模式
容灾部署模式决定了切换时的可用资源准备程度，从而影响RTO与运维成本。
2.3.1 热备、温备与冷备
常见三种模式可从“资源就绪程度”理解：
- 热备：关键服务与数据处于持续可运行状态，切换速度快，但资源成本高、运维复杂。
- 温备：部分资源或环境预配置就绪，通常比热备省成本，但切换与恢复仍需要额外步骤。
- 冷备：资源不常态运行，更多依赖备份与初始化流程，成本最低但RTO通常较长。
选择往往取决于业务对中断的容忍度、系统复杂度以及可接受的恢复节奏。
2.3.2 主备/多活与切换边界
切换边界需要明确，例如：哪些服务必须立即切换、哪些可以降级运行、切换时是否允许部分数据落后，以及切换期间如何避免“双写”等风险。
2.4 恢复站点与资源编排
DR不仅涉及“数据从哪里来”，还涉及“服务如何在新位置以正确顺序启动”。
2.4.1 本地恢复与异地恢复
- 本地恢复：适合应对机柜级故障或局部中断，优势是时延低、恢复链路短。
- 异地恢复：用于区域性不可用或更广泛的灾害场景，优势是避免单区域失效带来的系统性中断。
许多组织采用混合策略：本地提升短故障恢复速度，异地承担区域级风险。
2.4.2 云上恢复与混合场景
云上恢复常用于提升弹性与扩展能力，例如在灾难发生时快速拉起计算与存储。混合场景强调：
- 混合网络连通（VPN/专线/互联）在灾难时是否可达。
- 数据迁移与复制链路是否稳定。
- 镜像、配置与依赖项是否可在云侧复现。
关键在于把“可部署性”落实到自动化与配置管理上，避免灾难时只能手工拼装。
4.3.3 自动化资源调度与弹性扩缩
为缩短RTO，资源编排通常需要自动化支持，包括：
- 灾难触发后按顺序创建网络、计算实例、存储挂载与应用依赖。
- 根据目标性能自动扩缩资源，保证服务恢复后能满足SLA。
- 通过基础设施即代码（Infrastructure as Code）保证环境一致性。
自动化的本质是把“经验”变成可重复的流程，把“人脑”变成可执行的脚本。
流程与作业：从演练到切换
3.1 灾难恢复计划（DR Plan）构成
DR Plan是执行层面的蓝图，决定了谁在何时做什么，以及如何验证恢复结果。
3.1.1 角色分工与联络机制
计划通常需要明确责任边界与沟通路径，例如：
- 指挥/决策角色：负责启动与升级判断。
- 技术执行角色：负责数据恢复、系统启动、网络连通等具体动作。
- 验证与质量角色：负责恢复后业务连通性与数据一致性验证。
- 安全与合规角色：负责审计留存、访问控制恢复与证据保存。
联络机制强调可用性：包括电话/即时通讯/应急联络表等备份渠道，避免依赖同一通信链路。
3.1.2 资产清单与依赖关系梳理
资产清单不仅是“有哪些系统”，还包括：
- 应用与数据的映射关系
- 依赖链（例如数据库依赖消息队列、上游依赖DNS解析等）
- 恢复优先级与最小可用功能集（降级方案）
依赖梳理能显著降低切换时“启动顺序错误”造成的连锁故障。
3.1.3 恢复步骤与检查清单
恢复步骤需要可操作、可勾选、可复核。常见检查项包括：
- 数据恢复完成标志（例如校验通过、关键日志位置对齐）
- 网络与名称解析可达性
- 关键应用的启动状态与健康检查
- 业务层验证（核心接口可用、关键流程可跑通）
- 安全控制已就位（权限、审计、密钥与凭据恢复）
清单化的目的在于把“知道怎么做”变成“按步骤做且可核验”。
3.2 故障检测与决策流程
DR的切换不是“看到告警就立刻切”。需要判断故障范围、持续性与影响程度。
3.2.1 告警来源与验证手段
告警可能来自监控平台、日志聚合、链路探测或业务探针。验证手段通常包括：
- 多源交叉验证（监控 + 日志 + 业务探针）
- 关键指标检查（例如延迟、错误率、资源耗尽）
- 变更关联（最近发布、配置变更、权限变更与故障时间线是否匹配）
通过验证减少误切换，避免“切过去也不能用”。
3.2.2 切换触发条件（技术与流程）
触发条件一般分为技术条件与流程条件：
- 技术条件：关键服务不可用达到阈值、复制中断超过上限、存储不可访问等。
- 流程条件：是否进入升级流程、是否需要安全事件确认、是否满足演练后的决策时机等。
触发条件应尽量可量化，降低主观判断波动。
3.3 故障切换（Failover）与回退（Failback）
切换与回退都属于高风险动作，需要清晰的技术步骤与控制策略。
3.3.1 切换的技术步骤概览
常见切换步骤包括：
- 确认故障范围与可切换对象
- 按顺序启动网络连通与名称解析
- 完成数据恢复/挂载/一致性校验
- 启动应用与依赖服务
- 执行健康检查与业务验证
- 更新路由与访问入口，确保客户端指向新环境
- 记录证据并进入稳定运行监控
在复杂系统中，步骤顺序往往决定成败。
3.3.2 回退的风险控制
回退是把业务从临时环境切回原环境。常见风险包括数据再次冲突、配置不一致、恢复点差异导致的业务异常。控制措施通常包括：
- 回退前进行数据一致性评估与差异分析
- 必要时采用只读窗口或锁定关键数据写入
- 明确回退期间允许的降级能力
- 预设回退失败的应对策略（例如继续留在临时环境）
回退不宜“为了恢复而恢复”，而应以业务稳定与安全为优先。
3.4 恢复演练与持续改进
演练是把计划变成现实能力的关键环节。
3.4.1 桌面演练与技术演练
- 桌面演练：通过推演方式验证决策流程、角色协作与信息流正确性，成本较低。
- 技术演练：在受控环境中执行实际恢复链路，包括备份提取、资源部署、切换步骤与业务验证。
结合两类演练可以同时覆盖“会不会决策”和“能不能跑起来”。
3.4.2 演练复盘与度量指标
复盘通常围绕：
- 是否按RTO完成关键节点
- RPO是否达到恢复点目标
- 恢复步骤执行时间分布（哪里最慢）
- 错误与偏差原因（配置、权限、依赖、自动化缺陷）
- 安全审计与证据留存是否齐全
基于度量持续迭代，才能让DR能力随着系统演化而保持有效。
通信技术场景下的灾难恢复要点
4.1 网络与连接的恢复策略
通信系统的恢复往往首先决定“能不能连通”，因此网络层策略通常需要更细的优先级设计。
4.1.1 DNS与域名解析的容错
DNS是连接建立的基础组件。容错设计常包括：
- 多域名服务器或跨站点冗余
- 解析缓存与健康探测策略
- 域名解析失败时的降级方案（例如使用备用解析路径）
恢复时需要验证解析结果与目标地址是否匹配，避免“域名能解析但指错地方”。
4.1.2 负载均衡与会话保持
负载均衡恢复涉及两类问题：
- 新连接分发：后端可达性与权重配置是否正确
- 会话保持：对需要粘性会话或依赖会话状态的应用，需评估切换后会话丢失的业务影响，并制定容忍策略或重新建立机制。
4.1.3 VPN/专线与路由切换
灾难恢复期间可能出现隧道不可用或路由策略错误。常见做法包括：
- 预配置备路由与故障切换逻辑
- 对关键互联链路进行健康检查与自动重连
- 验证路由方向与NAT策略是否在新环境生效
避免出现“应用起来了但客户端走不进来”。
4.2 关键通信系统的优先级
不同通信能力对业务的影响程度不同，因此恢复排序需要基于业务优先级。
4.2.1 交换/路由平台的恢复路径
交换与路由平台的恢复通常包含：
- 控制面与数据面的恢复次序
- 配置与路由表的校验
- 与上层应用的接口重新建立
在某些场景下，先恢复控制面再恢复数据面可降低不可预期的路由抖动风险。
4.2.2 语音与实时数据的时延敏感性
语音、实时采集等对抖动与时延敏感。恢复后需关注：
- 时延是否回到可接受范围
- 队列积压是否导致延迟雪崩
- 编解码与传输路径是否正确恢复
因此对实时业务，DR的验证通常需要比普通HTTP探测更细的指标。
4.2.3 消息队列与时序一致性处理
消息队列在恢复后经常影响系统“事情发生的先后顺序”。设计上需考虑：
- 是否需要保证特定顺序或幂等处理
- 消费位点与恢复点对齐方式
- 恢复期间消息重放的策略与去重逻辑
良好的时序策略能减少“恢复后业务逻辑乱套”的问题。
4.3 带宽、延迟与恢复性能评估
恢复过程本身会产生额外流量与资源争用，因此需要性能评估。
4.3.1 恢复阶段的带宽规划
关键环节包括：
- 数据复制/回放阶段的带宽与并发控制
- 应用启动阶段的网络连接突发
- 多系统并行恢复时的带宽分配与限流
带宽不足可能导致RTO失效，即便数据本身恢复成功。
4.3.2 恢复过程的性能瓶颈分析
常见瓶颈包括：
- 存储IO与挂载延迟
- 加密解密开销与校验耗时
- DNS与证书链路验证导致的连接慢启动
- 应用依赖外部系统的“级联等待”
通过预演与日志分析，可以定位瓶颈并优化步骤顺序或并发策略。
4.4 可靠性与安全的结合
恢复期间的安全姿态不可忽视，尤其在面对恶意软件与数据篡改风险时。
4.4.1 恢复期间的访问控制与审计
恢复阶段通常需要更严格的访问控制：
- 采用最小权限原则启用关键服务
- 恢复后立即恢复审计与日志归档
- 对管理接口、密钥与凭据进行严格的访问隔离
这样可以避免“恢复成功但难以追责”。
4.4.2 勒索软件防护与恢复“隔离”思路
针对勒索软件等威胁，常见策略是恢复环境隔离与证据保全：
- 备份与恢复链路与生产网络隔离，降低二次感染概率
- 对恢复出来的数据进行校验与受控导入
- 在确认清洁状态后再逐步放开对业务的写入权限
“先验证、再接管”的思路能减少把污染带回生产的可能。
4.4.3 数据完整性验证与回放策略
数据完整性验证通常包括：
- 校验备份可恢复性（可读、可挂载、可启动）
- 对关键数据进行哈希校验或结构一致性检查
- 对回放或补齐的操作进行范围控制，避免无限重放导致的业务扰动
恢复策略应在安全与正确性之间取得平衡。
工具与技术选型
5.1 备份与恢复产品形态
备份与恢复工具在部署形态上存在差异，选型需要与系统规模、运维能力、恢复目标匹配。
5.1.1 代理式备份与无代理方案
- 代理式备份：通过在主机侧安装代理采集与处理数据，部署灵活但维护成本更高。
- 无代理方案：借助API、快照或存储侧能力完成数据保护，运维简化，但对平台适配要求更高。
无论哪种方案，都需要验证在灾难场景下的恢复链路是否稳定、是否能在RTO内完成关键步骤。
5.1.2 快照与镜像恢复
- 快照恢复：通常速度快，适合需要较短RTO的场景，但对一致性处理有额外要求。
- 镜像恢复：更接近“整机还原”，便于还原环境完整性，但在更新与差异管理上更具挑战。
最佳实践往往是：快照/镜像用于快速恢复计算与状态，配合备份数据用于更细粒度的一致性验证。
5.2 自动化与基础设施即代码
自动化是把DR从“靠人记步骤”升级为“按规则执行”的关键。
5.2.1 策略驱动的恢复编排
策略驱动编排关注“何时触发、恢复顺序、资源配置规则”。典型内容包括：
- 根据告警或触发条件选择恢复路径
- 依据依赖关系确定启动顺序
- 根据业务优先级分配资源与带宽
- 失败时的回退策略与升级流程
5.2.2 配置一致性校验
恢复环境一致性是避免“恢复出来但行为不一致”的关键。校验通常涵盖：
- 配置项版本与参数一致性
- 证书、密钥与权限配置正确性
- 网络策略与路由规则对齐
配置一致性建议纳入演练与发布流程的检查项。
5.3 可观测性与故障定位
可观测性帮助在恢复期间回答两个问题：恢复是否成功、为什么成功或失败。
5.3.1 日志、指标与追踪在恢复中的作用
恢复中建议保留并串联关键信号：
- 日志：用于复盘每一步的执行结果与错误码
- 指标：用于判断恢复阶段是否超过时间预算、资源是否饱和
- 追踪：用于跨服务验证依赖链路是否顺畅
5.3.2 恢复前后的对比验证
对比验证可以包括：
- 性能对比（延迟、吞吐、错误率）
- 功能对比（关键接口可用、核心流程可达）
- 数据对比（关键表一致性、摘要校验通过）
通过对比减少“看起来能用但其实有偏差”的隐患。
5.4 演练“脚本化”与可复现环境
脚本化让演练可重复，减少人为差异带来的结论偏差。
5.4.1 灰度恢复验证
灰度恢复是在小范围或低风险条件下验证恢复步骤正确性，例如先恢复非关键功能、或先验证数据一致性后再放开服务。其价值在于提前发现问题，避免全量切换时“满盘皆输”。
4.4.2 恢复链路的端到端测试
端到端测试强调从故障点到业务结果的闭环验证，包括：
- 从入口到后端的连通性
- 数据访问与事务处理正确性
- 关键消息流的完整性与时序正确性
DR演练若只测“服务器起来了”，往往就会发生经典翻车：演了个寂寞。
指标、合规与治理
6.1 RTO/RPO与SLA的对齐
DR指标需要与对外SLA或内部承诺对齐。RTO/RPO是恢复目标，但SLA通常还包含性能、可用性、错误率与响应时间等要求。治理应确保：
- DR验收指标能覆盖SLA关键条款
- 演练结果能反映真实业务表现而非仅技术完成
- 对不同业务类型设置不同恢复等级，避免“一个方案全都覆盖”导致成本失衡或效果不足
6.2 风险评估与业务影响分析（BIA）
BIA用于识别：
- 业务中断的影响范围与严重等级
- 关键系统与依赖链对业务的作用
- 可接受的停机时间与数据丢失上限
通过BIA确定恢复优先级，组织才能把有限预算花在真正“打断就要命”的环节。
6.3 合规、安全与审计要求
DR的合规与安全要求包括证据可追溯与控制可执行。
6.3.1 数据主权与跨境恢复注意事项
当恢复站点涉及跨境或跨区域数据流动时，需要关注：
- 数据存储与处理位置是否符合法规要求
- 访问与运维是否触发额外的合规义务
- 备份加密与密钥管理是否满足审计要求
DR治理需要把这些限制前置到架构设计阶段。
6.3.2 变更管理与审批机制
灾难恢复环境与生产环境密切相关，因此变更必须纳入治理：
- DR相关配置变更需走专门审批或风险评估
- 镜像、脚本、网络策略与密钥的变更需与演练计划联动
- 变更后必须验证可恢复性，避免“改完就不能恢复”
变更管理的目标是减少“越修越不可靠”的情况。
6.4 成本模型与投资权衡
DR投资通常不是简单买设备，而是对时间、风险与资源的综合定价。
6.4.1 备份频率与存储成本
更高频备份意味着更小RPO、更低数据丢失，但也会带来：
- 备份窗口压力
- 存储成本上升
- 校验与管理成本增加
因此需要在RPO目标与成本之间找到平衡点。
6.4.2 容灾资源冗余与运维成本
容灾强度越高，通常意味着更高的冗余资源与更复杂运维。权衡通常包括：
- 热备带来的资源占用与运维复杂度
- 自动化与脚本维护成本
- 演练频率带来的时间与验证成本
一个可行的原则是：对不同业务分级设置不同DR等级，而不是“一刀切”。
常见问题与故障排查（带点“梗”但不误事）
7.1 “备份有了但恢复不了”的典型原因
常见原因往往不是“备份没做”，而是恢复链路缺失或条件不满足，例如：
- 备份可读性未经验证，恢复时发现兼容性问题
- 权限不足导致无法挂载或启动
- 加密密钥丢失或轮换后恢复环境无法使用
- 应用一致性处理缺位，恢复后业务无法正确运行
- 演练频率太低，配置更新后恢复步骤未同步
7.2 恢复慢：从网络到镜像的排查路径
恢复慢通常可从瓶颈链路逐级定位：
- 网络：带宽不足、DNS异常、隧道不稳定
- 存储：IO瓶颈、快照/镜像挂载耗时
- 安全：加解密或校验耗时
- 应用：依赖服务启动慢、线程或连接池耗尽
- 编排：脚本或编排等待条件设置不合理
排查要尽量按时间顺序复盘每一步的耗时，而不是凭感觉猜。
7.3 数据不一致：时间点选择与一致性策略
数据不一致常见于以下场景：
- 复制延迟导致恢复点不符合期望
- 多源备份或多表恢复缺少一致性协调
- 消息队列与数据库恢复点未对齐
- 事务日志或回放策略不匹配
解决思路一般是明确一致性等级：哪些业务必须强一致，哪些可接受最终一致，并在恢复策略中把规则落实到实现与验证。
7.4 演练翻车：如何避免“演了个寂寞”
演练翻车的典型信号包括：只做了“开机动作”，没有完成业务验证；恢复后只检查技术状态未检查用户体验；或者演练脚本与实际环境差异过大。
避免“演了个寂寞”的关键做法是：
- 设定可量化验收标准（RTO/RPO与业务探测）
- 在接近真实约束的条件下执行（依赖、带宽、权限）
- 演练后固化改进项并追踪闭环
参考术语与相关概念
8.1 高可用（HA）与灾难恢复（DR）的区别
- 高可用（HA）强调在故障发生时尽量降低中断时间，通常针对单站点或局部故障，目标更多是“持续可用”。
- 灾难恢复（DR）强调在更大范围不可用时，把系统与数据恢复到可运行状态，目标更偏向“跨故障域恢复”。
简言之：HA更像“短时间不断”，DR更像“坏了也能回来”。
8.2 业务连续性（BCP）与灾难恢复（DR）的关系
- 业务连续性（BCP）涵盖流程、人员、沟通、替代运作方式等更广的连续能力。
- 灾难恢复（DR）提供IT与数据层面的恢复方案，是BCP落地的重要技术组成部分。
BCP决定“业务要怎么继续”，DR决定“技术要怎么恢复”。
8.3 关键系统、依赖链与恢复优先级
恢复优先级通常基于：
- 对业务收入或服务能力的影响程度
- 与其他系统的依赖关系（谁先谁后）
- 数据一致性的约束（哪些必须先恢复或必须一致）
- 恢复后的最小可用功能集（先恢复“能用的核心”，再恢复“完整形态”）
依赖链梳理是优先级正确性的基础。
8.4 故障模型与切换术语（failover/failback等）
常见术语包括：
- Failover（故障切换）：在主系统不可用时切换到备选系统以提供服务。
- Failback（故障回退）：故障恢复后切回原环境或更合适的环境。
- 切换窗口：从触发切换到恢复稳定运行的时间段。
- 恢复点：恢复所对应的数据时间状态，用于界定RPO与一致性策略。
术语的统一有助于在演练与排障时减少沟通歧义。