适用版本： 6.8-7.5
1. 错误异常的基本描述 #
cannot delete snapshot during a restore 表示当前集群仍有 restore 任务正在使用这个快照或正在执行任意 restore 流程，Elasticsearch 为避免恢复过程依赖的文件被提前删除，直接抛出 ConcurrentSnapshotExecutionException 阻止删除。
这是一条明确的数据一致性保护规则，不是仓库权限问题，也不是快照不存在。
常见现象 #
- 发起快照删除时立即返回并发执行异常。
- 同一时间窗口内存在
/_restore请求、挂载 searchable snapshot 或索引恢复任务。 - 运维侧以为 restore 已经开始就可以删源快照，但删除被立即拒绝。
- 日志中会看到
restoreInProgress非空的保护逻辑被触发。
典型报错与异常栈 #
ConcurrentSnapshotExecutionException: [repo:snap-20260331] cannot delete snapshot during a restore
2. 为什么会发生这个错误 #
restore 依赖快照仓库中的分片文件和元数据。只要 restore 仍在进行中，删除快照就可能把恢复所需文件一起删掉，因此 Elasticsearch 在入口阶段直接禁止这类操作。
常见原因通常包括：
- 正在执行快照恢复，而运维脚本同时做旧快照清理。
- searchable snapshots 挂载或恢复任务尚未结束。
- 自动化调度没有区分“备份/恢复窗口”和“清理窗口”。
- restore 过程很慢，调用方误以为它已经结束。
3. 如何排查和解决这个异常和解决这个异常 #
建议按“先确认 restore 是否仍在进行，再判断是否需要等待或调整任务编排”的顺序处理：
- 查看当前是否存在 restore in progress 条目。
- 确认删除目标快照是否正被 restore 使用。
- 如果 restore 只是耗时较长，等待结束后再删除。
- 如果频繁重现，检查自动化是否把 restore 与 cleanup 安排在同一窗口。
相关 Elasticsearch API #
GET /_cluster/state：查看RestoreInProgress相关状态。GET /_recovery：确认相关索引是否仍在恢复中。GET /_snapshot/{repository}/_current：确认是否还伴随其他快照活动。
排查时需要注意的问题 #
- 这类异常发生得很早，说明删除主体动作根本还没开始。
- 不要在 restore 尚未完成时尝试绕过保护做手工仓库删除，这会直接破坏恢复链路。
- 如果恢复长期不结束，先处理 restore 本身的问题，而不是继续重试删除。
4. 如何解决这个错误 #
常用修复思路 #
- 等待 restore 完成后再删除快照。
- 把 restore 与快照清理编排到不同时间窗口。
- 对自动化脚本增加 restore 状态检查，只有无活跃 restore 时才允许删除。
- 如果 restore 异常卡住，先定位恢复失败的分片、仓库或节点问题。
借助 INFINI 产品提升排障效率 #
- INFINI Console 适合同时查看恢复任务状态、索引恢复进度和快照删除请求时间线。
- INFINI Gateway 可帮助识别哪些自动化请求在 restore 窗口内触发了删除动作。
5. 小结 #
cannot delete snapshot during a restore 的重点很直接：删除请求被 restore 保护规则拦下了。要解决它，先结束或稳定 restore，再回到快照删除流程，而不是把问题误判成仓库层故障。
相关错误 #
附：日志上下文 #
if (restoreInProgress != null) {
if (restoreInProgress.isEmpty() == false) {
throw new ConcurrentSnapshotExecutionException(snapshot, "cannot delete snapshot during a restore");
}
}
