【Elasticsearch】安全地删除快照仓库、快照

在上一篇博文《【Elasticsearch】快照与恢复功能详解》中，我们针对 Elasticsearch 的快照和恢复功能进行的讲解。细心的同学可能会对以下的命令产生疑惑，直接删除是安全的吗？本文将会给你答案。

• 删除仓库：DELETE /_snapshot/my_backup_repo
• 删除快照：DELETE /_snapshot/my_backup_repo/my_snapshot_20230720

1.删除仓库

当你执行 DELETE /_snapshot/my_backup_repo 这个命令时，你是在 Elasticsearch 集群中删除 my_backup_repo 这个快照仓库的注册信息或定义。

关键点在于：

• 删除的是“注册信息”，不是物理数据：这个操作 不会 删除存储在实际后端存储系统（比如 AWS S3 桶、Azure Blob 容器、NFS 共享目录等）中的 任何快照文件或数据。
• 后果：
  • Elasticsearch 集群将不再知道存在名为 my_backup_repo 的仓库。
  • 你无法再通过 Elasticsearch API 来 查看、创建、恢复或删除 这个仓库中的任何快照（因为集群不知道它了）。
  • 你 无法再通过 Elasticsearch 管理 存储在该位置的历史快照。
• 物理数据依然存在：你使用这个仓库创建的所有快照文件（my_snapshot_1, my_snapshot_2 等）仍然 安全地躺在 你配置的 S3 桶、Azure 容器、共享文件系统路径等地方。
• 为什么设计成这样？这是一种安全机制。防止管理员在 Elasticsearch 中误操作删除仓库命令时，导致宝贵的备份数据被物理删除。真正的数据删除需要直接操作底层存储系统。
• 如何真正删除快照数据？
  • 如果你想 彻底删除快照数据以释放存储空间，你必须在 删除仓库注册信息之前，使用 Elasticsearch API 先删除仓库内的具体快照：DELETE /_snapshot/my_backup_repo/my_snapshot_20230720。这个命令会通知 Elasticsearch 去清理仓库中该快照专用的、不再被其他快照引用的数据段。
  • 或者，在 删除了仓库注册信息之后，你只能 直接登录到你的存储系统（如 AWS S3 控制台、Azure 门户、NFS 服务器），手动找到对应的目录/路径并删除里面的文件。这需要你非常清楚仓库在存储系统中的具体位置（比如 S3 桶里的 snapshots/prod_cluster 路径）。

简单比喻：

想象你的快照仓库是一个图书馆（物理存储）。DELETE /_snapshot/my_backup_repo 这个操作相当于：

• 把图书馆的 地址登记簿 上关于 my_backup_repo 图书馆的那一页 撕掉了。
• 图书馆管理员（Elasticsearch）忘记了这个图书馆的存在，再也不能帮你从里面借书（管理快照）。
• 但是，图书馆大楼本身和里面所有的书（你的快照数据）都完好无损地还在原地！只是管理员不知道它在哪里，也无法帮你管理里面的书了。

总结：执行 DELETE /_snapshot/my_backup_repo 只会移除 Elasticsearch 集群内部对这个仓库的配置和认知，绝不会触碰存储在外部（如 S3、NAS）的实际快照数据文件。 要清理物理存储空间，必须在删除仓库定义前通过 API 删除快照，或在删除仓库定义后直接操作底层存储系统。

2.删除快照

• DELETE /_snapshot/my_backup_repo/my_snapshot_20230720
• Elasticsearch 会清理 仅被该快照引用 的段文件。被其他快照共享的段文件不会被删除。删除是安全的操作。

上面这段话解释了执行 DELETE /_snapshot/my_backup_repo/my_snapshot_20230720 命令删除 单个快照 时，Elasticsearch 在 底层存储层面 的智能行为和安全机制。核心是理解 “增量快照” 和 “段文件共享” 的原理。

解析：

• DELETE /_snapshot/my_backup_repo/my_snapshot_20230720
  • 这是删除名为 my_backup_repo 的快照仓库中，名为 my_snapshot_20230720 的特定快照的命令。
• Elasticsearch 会清理仅被该快照引用的段文件
  • 段文件（Segment Files）：Elasticsearch（底层是 Lucene）将索引数据存储在不可变的段文件中。写入操作会产生新的段，后台会合并小的段成大的段。
  • 增量快照：快照是增量的。首次快照备份所有相关的段文件。后续快照只备份 自上次快照以来新创建或修改的段文件。旧的、未修改的段文件在仓库中只有一份物理存储，但会被多个快照逻辑引用。
  • 仅被该快照引用：当删除一个快照时，Elasticsearch 会检查仓库中哪些段文件 只有 这个即将被删除的快照在使用（引用）。这些段文件不再被任何其他快照需要，因此是 “孤立” 的，可以安全地从物理存储中删除以释放空间。
  • 清理：指物理删除这些不再被任何快照引用的段文件。
• 被其他快照共享的段文件不会被删除
  • 如果一个段文件存在于多个快照中（例如，它是一个在 my_snapshot_20230720 创建之前就存在且从未修改过的段，被 my_snapshot_20230720 和更早的快照如 my_snapshot_20230713 共同引用），那么删除 my_snapshot_20230720 不会 删除这个共享的段文件。
  • 因为其他快照（如 my_snapshot_20230713）仍然需要它。只有该快照独有的段文件才会被清理。
• 删除是安全的操作
  • 不会误删共享数据：如上所述，被其他快照共享的基础数据会被保留，确保其他快照的完整性和可恢复性。
  • 精准释放空间：只删除真正不再需要的、孤立的段文件，有效释放存储空间。
  • 不影响其他快照：删除一个快照不会破坏或影响仓库中其他快照的完整性。其他快照仍然可以正常恢复。
  • 操作幂等性（通常）：如果尝试删除一个不存在的快照，命令通常会返回一个错误（如 404），不会造成意外后果。重复删除同一个快照（如果第一次成功）通常也会报错（404），不会执行额外操作。

核心概念图示：

想象快照仓库里存储的是乐高积木（段文件）：

• 1️⃣ 首次快照 → Snap1：备份了构建城堡 A 所需的所有积木（Block1、Block2、Block3）。

• 2️⃣ 第二次快照 → Snap2：城堡 A 只在顶部加了一个新塔尖（Block4）。Snap2 只需备份新的 Block4。Snap2 的完整城堡由 [Block1, Block2, Block3 (引用自Snap1), Block4] 组成。

• 3️⃣ 第三次快照 → Snap3：城堡 A 被改造成了飞船，替换了底座（Block5），保留了部分旧墙（Block2）。Snap3 备份新的 Block5 和修改过的 Block2（可能是一个新版本的 Block2）。Snap3 的飞船由 [Block2(新版本), Block3 (引用自Snap1), Block5] 组成。旧的 Block1 和 Block4 不再被引用。

  • 物理存储：所有积木（Block1/2/3/4/5/2’）实际只存储一份
  • 逻辑引用：
    • Snap1 → 引用基础积木 Block1/2/3
    • Snap2 → 引用共享积木 Block1/2/3 + 独有 Block4
    • Snap3 → 引用共享积木 Block3 + 新积木 Block2’/5

• 4️⃣ 删除 Snap2：

  • Snap2 独有的积木是 Block4（因为 Snap1 没有它，Snap3 也不需要它）。
  • Snap2 和其他快照 共享 的积木是 Block1, Block2(旧), Block3 (它们还被 Snap1 或 Snap3 引用)。
  • 结果：执行 DELETE /_snapshot/repo/Snap2 后，检查引用计数：
    • Block4 仅被 Snap2 引用 → 删除（物理删除）
    • Block1 还被 Snap1 引用 → 保留
    • Block2(旧) 还被 Snap1 引用 → 保留
    • Block3 被 Snap1/Snap3 引用 → 保留
  • Snap1 和 Snap3 仍然完整可用。

总结理解的关键点在于：

• 增量性与共享：快照不是独立的完整拷贝，它们共享未修改的底层数据段。
• 引用计数：Elasticsearch 内部维护着仓库中段文件被哪些快照引用的信息。
• 智能清理：删除快照时，只清理 引用计数降为 0（即不再被任何快照引用）的段文件。
• 安全保证：这种基于引用计数的清理机制确保了：
  • 删除一个快照不会破坏其他快照。
  • 空间得到有效释放（删除孤立数据）。
  • 操作不会导致意外数据丢失（只删该删的）。

因此，你可以放心地删除旧的或不必要的快照来管理仓库存储空间，而不用担心会破坏其他快照或丢失仍然需要的基础数据。这就是 “删除是安全的操作” 的含义。