Elasticsearch 快照与恢复
把索引与集群状态快照到共享仓库（文件系统、S3、HDFS 等）：快照按段增量存储，同一索引多次快照只传新增段，因此频繁执行的成本可控。用快照生命周期管理（SLM）策略可以定时执行并自动保留，恢复时按索引选择恢复到当前集群或新集群。
基本信息
| 适用平台 | Elasticsearch（版本间 API 与仓库插件差异较大） |
|---|---|
| 仓库类型 | fs（共享文件系统）、s3、hdfs 等插件 |
| 前置配置 | 各节点 path.repo 白名单内且路径一致 |
| 自动化 | SLM 策略定义仓库、时间表、保留与快照命名 |
典型使用场景
- 日常索引备份：按天快照关键索引，出问题按索引恢复
- 升级前留保护点：跨大版本前先做快照，异常时回退
- 误删索引恢复：只恢复被删的索引，不必动整个集群
- 跨集群迁移：把快照仓库挂到新集群，恢复索引完成搬迁
- 合规留存：按 SLM 保留策略自动管理快照数量
注册仓库与快照
注册仓库与快照
# 1) 定义仓库（fs 类型），并确保所有节点 path.repo 已包含该路径
# repo.json: {"type":"fs","settings":{"location":"/mnt/es-backup"}}
curl -X PUT "localhost:9200/_snapshot/backup_repo" \
-H 'Content-Type: application/json' -d @repo.json
# 2) 创建快照（wait_for_completion 等待完成）
curl -X PUT "localhost:9200/_snapshot/backup_repo/snap-2026.10.12?wait_for_completion=true"
# 3) 只恢复指定索引
curl -X POST "localhost:9200/_snapshot/backup_repo/snap-2026.10.12/_restore?wait_for_completion=true" \
-H 'Content-Type: application/json' \
-d '{"indices":"logs-2026.10.11","include_global_state":false}'
# 4) 查看仓库与快照状态
curl -s "localhost:9200/_snapshot/backup_repo/_all?verbose=false"恢复参数读法
| 参数 | 含义 | 注意 |
|---|---|---|
| indices | 要恢复的索引 | 不填则恢复快照内全部 |
| include_global_state | 是否恢复集群状态 | 恢复到同一集群常设为 false |
| rename_pattern / rename_replacement | 恢复时重命名 | 避免覆盖现有索引，适合并行比对 |
| wait_for_completion | 是否等待完成 | 大批量恢复建议异步并查任务状态 |
仓库位置需在 elasticsearch.yml 的 path.repo 白名单内，各节点路径保持一致，且运行 Elasticsearch 的用户要有读写权限；否则仓库注册直接失败。
跨大版本从快照恢复有限制：升级路径上应先用恢复演练或 reindex 到新集群验证，不要直接假定快照在新版本可用。
快照粒度是索引而不是文档：误删一批文档时，恢复整索引会连同其后的新增数据一起回退，实际做法通常是恢复到别名指向的新索引再做数据合并。SLM 策略要按天命名并设置保留份数，避免快照数量失控。