1. 课程导入与灾备目标

在开始学习 HPE Alletra 的异地复制与灾难恢复之前，先建立一个判断标准：灾备不是“把数据再存一份”这么简单，而是当生产站点发生火灾、洪水、断电、勒索软件或人为误删时，业务能否在可接受的时间内、以可接受的数据损失继续对外服务。这个判断标准由两个核心指标决定——RPO 与 RTO。理解它们，是理解后续所有复制策略、一致性组和切换流程的前提。

一、RPO 与 RTO：灾备的两个“刻度尺”

RPO（Recovery Point Objective，恢复点目标）回答的是“最多能丢多少数据”。它用时间衡量：如果 RPO 是 15 分钟，意味着灾难发生时，允许丢失最近 15 分钟内写入的数据，恢复后数据应回到 15 分钟前的某个一致状态。RPO 越小，对复制频率和链路带宽要求越高。

RTO（Recovery Time Objective，恢复时间目标）回答的是“多久能恢复业务”。它从灾难发生或决定切换的那一刻开始计时，到备用站点业务重新可用为止。RTO 包含故障发现、决策、切换执行、主机重新挂载、应用启动和验证的全部时间。RTO 越短，越需要自动化切换和预先验证的流程。

两者常被混淆，但方向完全不同：RPO 面向“过去”，约束数据能回溯到多近；RTO 面向“未来”，约束业务多久能重新对外。一个常见的业务分级示例如下（示例参数，用于说明分级思路，非实测值）：

注意：RPO 与 RTO 不是技术指标，而是业务指标。技术方案必须服务于业务给出的目标值，而不是反过来让业务迁就技术。课程后续讨论的同步/异步复制、一致性组、快照与克隆，都是在为达成这些目标服务。

二、一致性组：多卷业务的数据“同一时刻”

真实业务很少只用一个卷。一个数据库可能由数据卷、日志卷、归档卷组成，三者必须保持写入顺序一致。如果只对数据卷做复制，而日志卷落后几秒，恢复后数据库可能无法启动或需要长时间崩溃恢复。

一致性组（Consistency Group）就是把存在写入依赖关系的多个卷绑定为一个逻辑单元，复制时保证组内所有卷在同一时刻点被捕获，形成“崩溃一致”或“应用一致”的恢复点。它的价值在于：恢复出来的不是一个卷的旧数据，而是一整套彼此匹配、可直接挂载启动的数据集合。

三、HPE Alletra 在灾备体系中的定位

HPE Alletra 是面向关键业务的存储平台，在灾备体系中处于“数据层”的核心位置。它向下承接底层介质与网络，向上为数据库、虚拟化和应用提供可复制的数据卷。它的灾备能力主要体现在三个层面：

• 本地高可用：通过 RAID、双控、多路径保证单点故障不影响业务，这是灾备的第一道防线。
• 远程复制：通过同步或异步复制，把数据持续送到异地站点，决定 RPO 能否达标。
• 快照与克隆：提供时间点副本，用于快速回滚、测试验证和逻辑错误恢复，弥补复制无法防“误删”的短板。

需要明确的是：存储复制只解决“数据到达异地”，不自动解决“业务在异地起来”。RTO 的达成还需要主机、网络、DNS、应用编排的配合。因此 HPE Alletra 的灾备方案通常是“存储复制 + 主机切换 + 应用验证”的组合，存储是其中最关键但也只是其中一环。

四、从目标到方案：一张图看清灾备决策链

下面这张图把本节的核心概念串成一条决策链：业务需求先转化为 RPO/RTO 目标，再据此选择复制方式与一致性组范围，最终落到 HPE Alletra 的具体能力上，并通过验证闭环确认目标是否真正达成。

五、一个可执行的目标梳理清单

在进入具体配置之前，建议先用下面这份清单把业务目标落到纸面。它可以直接作为灾备项目的输入材料使用：