📚 课程目录第4章创建与管理本地快照

4. 创建与管理本地快照

本地快照是 Pure Storage FlashArray 数据保护体系中最基础、使用频率最高的能力。它基于 Purity 的元数据指针机制，在卷（Volume）、文件系统（File System）或卷组（Protection Group）层面记录某一时刻的数据状态，几乎不占用额外空间，也不影响生产 I/O。理解快照的创建入口、保留策略、命名规范与生命周期，是后续快照复制（Snapshot Replication）和 ActiveDR 等高级功能的前提。

一、快照的三种创建入口

FlashArray 提供 GUI、CLI（Purity 命令行）与 REST API 三条等价路径，三者操作的是同一套底层对象，只是适用场景不同：GUI 适合交互式确认与可视化查看，CLI 适合批量与脚本化，API 适合与自动化平台、编排工具集成。

在 GUI 中，进入 Storage → Volumes，选中目标卷后点击 Snapshots 标签页，再点击 Create Snapshot，填写快照名称后缀即可。若要对整个保护组统一打快照，则进入 Protection → Protection Groups，选择组后点击 Snapshot，此时组内所有成员卷会获得同一时间点的一致性快照。

CLI 方式更直接。对单个卷创建快照：

purevol create --snap myvol.20240612_app01 myvol
# 语法：purevol create --snap <快照名> <源卷名>
# 快照名通常为 源卷名.后缀 形式

对保护组创建一致性快照：

purepgroup snap --suffix 20240612_app01 app_pgroup
# 组内所有卷将生成后缀一致的快照

REST API 方式适合自动化。以创建卷快照为例，向 /api/1.19/volume/{volume}/snapshots 发送 POST 请求，请求体中携带 suffix 字段：

POST /api/1.19/volume/myvol/snapshots
{
  "suffix": "20240612_app01"
}

返回结果中会包含快照的完整名称、创建时间、源卷及逻辑大小。无论走哪条路径，最终生成的快照对象都遵循 源卷名.后缀 的命名结构。

二、保留策略：时间与数量两种维度

快照本身不会自动消失，必须显式设置保留策略，否则会持续累积。FlashArray 支持两种保留维度：按时间保留（retain for）和按数量保留（keep at most）。两者可以组合使用，系统取先到期的条件执行销毁。

按时间保留的 CLI 示例：

purevol create --snap myvol.20240612_app01 --retain 7d myvol
# 该快照将在 7 天后自动销毁

按数量保留通常配合保护组使用，例如只保留最近 10 个快照：

purepgroup setattr --keep 10 app_pgroup
# 组内快照超过 10 个时，最旧的自动销毁

在 GUI 中，可以在卷或保护组的 Snapshot Schedule 中设置保留天数与最大数量。需要特别注意的是：保留策略是快照生命周期的唯一自动控制手段，如果既没有设置 retain 也没有设置 keep，快照将永久保留，直到手动销毁。这在生产环境中极易造成快照堆积，虽然快照本身空间开销小，但元数据数量过多会影响管理效率。

三、命名规范：让快照可读、可查、可自动化

FlashArray 的快照名称由 源对象名.后缀 构成，后缀部分由用户自定义。一个良好的命名规范应同时满足三个目标：人能快速读懂、脚本能稳定解析、排序时能反映时间顺序。

推荐采用如下结构：

<源卷名>.<YYYYMMDD>_<HHMM>_<用途标识>
示例：myvol.20240612_1430_app01
      myvol.20240612_1430_before_upgrade

其中日期使用 YYYYMMDD 格式，保证字典序与时间序一致；用途标识用于区分快照来源，例如 app01 表示应用一致性快照，before_upgrade 表示升级前保护点。避免使用空格、中文或特殊字符，以免在 CLI 与 API 调用时产生转义问题。

在保护组场景中，建议所有成员卷使用统一后缀，这样在恢复时可以通过后缀一次性定位整个一致性组，而不是逐个卷查找。

四、生命周期管理：从创建到销毁的完整闭环

快照的生命周期可以概括为四个阶段：创建 → 使用 → 到期 → 销毁。创建阶段确定快照的时间点与命名；使用阶段包括挂载到主机进行数据校验、覆盖恢复源卷、或作为快照复制的源；到期阶段由保留策略触发；销毁阶段释放快照占用的元数据与共享数据块引用。

手动销毁快照的命令如下：

purevol destroy myvol.20240612_app01
# 销毁后进入 destroyed 状态，仍可恢复
purevol eradicate myvol.20240612_app01
# 彻底清除，不可恢复

这里有一个关键区别：destroy 只是将快照标记为已销毁，数据仍保留在系统中，可以通过 purevol recover 恢复；eradicate 才是真正的物理清除。默认情况下，销毁的快照会在 24 小时后自动 eradicate，这个窗口期是误删快照的最后一道防线。

在 GUI 中，可以在 Storage → Volumes → Snapshots 中查看快照状态，已销毁的快照会以灰色显示，并提供 Recover 与 Eradicate 按钮。对于保护组快照，则进入 Protection → Protection Groups → Snapshots 统一管理。

五、实践建议与常见误区

第一，不要依赖手动创建快照。生产环境应通过保护组的 Snapshot Schedule 自动创建，手动快照仅用于升级、变更等临时保护点。第二，保留策略要分层。例如应用一致性快照保留 24 小时，每日快照保留 7 天，每周快照保留 4 周，通过多个保护组或不同后缀实现。第三，命名规范要提前约定，一旦确定就不要随意更改，否则自动化脚本与恢复流程都会失效。第四，定期检查快照数量与空间占用，使用 purevol list --snap 或 GUI 的快照列表，确认没有异常堆积。

快照不是备份。快照与源卷共享底层数据块，如果源卷数据被误删或损坏，快照可以快速恢复；但如果整个阵列发生故障，快照无法提供跨设备保护。跨阵列保护需要依赖快照复制（Snapshot Replication）或 ActiveDR。

掌握本地快照的创建、保留、命名与生命周期管理，就掌握了 FlashArray 数据保护的第一层能力。后续的快照复制、远程保护与灾难恢复，都是在这一层基础上向跨阵列、跨站点延伸。