2. Pure Storage数据保护架构总览

要理解 Pure Storage 的数据保护体系，不能只记住“快照”和“复制”两个功能名，而要先看清它们在整体架构中的位置。FlashArray 与 FlashBlade 虽然都提供快照与复制能力，但两者的数据组织方式、复制引擎和策略模型并不完全相同。FlashArray 以卷（Volume）为核心，围绕 Purity 操作系统提供块级快照与 ActiveCluster、ActiveDR 等复制能力；FlashBlade 以文件系统和对象存储为核心，围绕 Purity//FB 提供文件/对象级快照与异步复制。两者共享“快照是本地保护、复制是远程保护、策略是自动化编排”这一总体分层，但具体实现落在不同的引擎上。

从整体架构看，Pure Storage 的数据保护可以分成四层：最底层是存储介质与元数据层，负责数据落盘和快照指针管理；其上是快照机制层，负责在本地生成时间点副本；再往上是复制引擎层，负责把快照或增量数据传到远端；最上层是保护策略层，负责定义“谁、何时、保留多久、复制到哪里”。这四层不是并列关系，而是逐层依赖：没有快照，复制就没有可传输的源；没有复制，快照只能防本地逻辑错误，无法防站点级灾难；没有策略，快照和复制就只能靠人工触发，难以满足 RPO 和合规要求。

先看快照机制。FlashArray 的快照建立在 Purity 的元数据指针之上。创建卷快照时，系统并不复制全部数据块，而是记录当前卷的元数据映射关系，后续写入采用写时重定向（redirect-on-write），新数据写到新位置，旧数据块保留给快照引用。因此快照创建几乎瞬时完成，占用空间取决于后续变化量。FlashBlade 的快照则面向文件系统和对象存储，快照点保证文件系统元数据的一致性，恢复时可以按目录或文件粒度进行。两者共同点是“快照不是完整拷贝，而是时间点引用”，这也是 Pure 能把快照做得密集且低成本的原因。

再看复制引擎。FlashArray 的复制分为同步与异步两条路径。ActiveCluster 提供同步双活，两个阵列之间的卷组成 Pod，写入需要同时确认到两端，RPO 接近零，适合对可用性要求极高的数据库或关键业务。ActiveDR 提供异步复制，本地先确认写入，再按周期把增量传到远端，适合跨城或跨区域容灾。FlashBlade 的复制以异步为主，通过 replication link 在源和目标 FlashBlade 之间传输快照数据，支持文件系统和对象存储的远程保护。这里的关键区别是：FlashArray 的复制单位更接近卷和一致性组，FlashBlade 的复制单位更接近文件系统或对象桶。

保护策略层是把快照和复制自动化的关键。在 FlashArray 上，保护策略通常绑定到卷或 Pod，策略中定义快照计划（例如每 15 分钟一次）、保留规则（例如保留 24 小时、7 天、4 周）以及复制目标（例如把快照复制到远端阵列）。在 FlashBlade 上，策略绑定到文件系统或对象存储账户，定义快照频率、保留时长和复制链路。策略的价值在于把“什么时候做快照、保留多久、要不要复制”从人工操作变成声明式规则，从而稳定满足 RPO 和合规保留要求。

下面用一个教学示例说明策略参数如何影响实际保护效果。假设某业务使用 FlashArray 卷 vol-app01，要求本地 RPO 不超过 15 分钟，远端 RPO 不超过 1 小时，本地保留 24 小时，远端保留 7 天。可以设计如下策略：快照计划每 15 分钟一次；本地保留 96 个快照（15 分钟 × 96 = 24 小时）；复制目标为远端 FlashArray，复制周期 1 小时；远端保留 168 个快照（1 小时 × 168 = 7 天）。这样本地可以快速回滚到最近 15 分钟内的任意时间点，远端可以应对站点级故障。若业务写入量较大，还需要关注快照空间占用和复制带宽，避免保留策略过密导致空间或链路压力。

从整体架构位置看，快照机制位于复制引擎之下，是复制的数据来源；复制引擎位于策略层之下，是策略的执行者；策略层位于最上方，决定保护节奏和保留边界。三者共同依赖底层的存储与元数据层。理解这个分层后，遇到具体问题时就能快速定位：如果本地回滚点不够密，检查快照计划；如果远端数据落后，检查复制链路和复制周期；如果快照占用空间异常，检查保留策略和写入变化量。架构总览的意义，正是让后续每一章的具体操作都有明确的归属位置。