在上一篇博文《【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 管理 存储在该位置的历史快照。
- 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
路径)。
- 如果你想 彻底删除快照数据以释放存储空间,你必须在 删除仓库注册信息之前,使用 Elasticsearch API 先删除仓库内的具体快照:
简单比喻:
想象你的快照仓库是一个图书馆(物理存储)。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(即不再被任何快照引用)的段文件。
- 安全保证:这种基于引用计数的清理机制确保了:
- 删除一个快照不会破坏其他快照。
- 空间得到有效释放(删除孤立数据)。
- 操作不会导致意外数据丢失(只删该删的)。
因此,你可以放心地删除旧的或不必要的快照来管理仓库存储空间,而不用担心会破坏其他快照或丢失仍然需要的基础数据。这就是 “删除是安全的操作” 的含义。