快照备份与恢复是什么
快照是 Elasticsearch 的集群级备份手段：先注册一个仓库（文件系统共享目录或对象存储），再按索引粒度创建快照，需要时从快照恢复，跨集群迁移也常走同一套流程。快照按增量存储，但每个快照在逻辑上是完整独立的。日常做法是定期创建快照，加上周期性的恢复演练——只有演练过的备份才算备份。
基本信息
| 前置条件 | 文件系统仓库需在 elasticsearch.yml 配 path.repo 并保证各节点可见同路径 |
|---|---|
| 仓库类型 | fs、s3、gcs、azure 等 |
| 常用接口 | /_snapshot、/_snapshot/<repo>/<snap>、.../_restore |
| 适用版本 | Elasticsearch 7.x / 8.x |
| 权限要求 | 需要集群管理权限 |
典型使用场景
- 日常备份：按天创建快照并保留最近若干份，应对误删与索引损坏
- 集群迁移：新集群注册同一仓库后恢复指定索引，完成数据搬迁
- 版本升级：升级前做快照，升级异常时快速回退
- 误删恢复：按索引恢复并改名，避免直接覆盖正在使用的索引
- 合规留存：按周期归档快照到对象存储，满足审计要求
注册、快照与恢复
注册、快照与恢复
# 注册文件系统仓库（各节点 elasticsearch.yml 需配 path.repo 指向同路径）
PUT /_snapshot/backup
{ "type": "fs", "settings": { "location": "/mnt/backups" } }
# 创建快照并等待完成
PUT /_snapshot/backup/snap-2026-10-12?wait_for_completion=true
# 恢复指定索引并改名，避免与在用索引冲突
POST /_snapshot/backup/snap-2026-10-12/_restore
{ "indices": "logs-app", "rename_pattern": "logs-app", "rename_replacement": "logs-app-restored" }
GET /_snapshot/_all # 查看仓库与快照状态常见故障与原因
| 现象 | 原因 | 处理方向 |
|---|---|---|
| 仓库不可用 | 节点 path.repo 不一致或权限不足 | 统一路径与属主后重试 |
| 快照部分成功 | 分片不可用或磁盘空间不足 | 先解决分片与空间问题再重建 |
| 恢复失败 | 同名索引已存在且未关闭 | 改用改名恢复或先关闭原索引 |
| 恢复很慢 | 并发恢复分片数受限 | 按需调整并发，避免压垮集群 |
恢复完成后要确认分片是否全部转回正常状态，并核对目标索引的文档数与关键字段，避免「恢复成功但数据不完整」的情况被忽略。