Elasticsearch 数据备份与恢复需通过 Snapshot 与 Restore 机制实现：先注册快照仓库，再执行增量备份，接着查看快照列表，然后按需恢复索引（支持重命名与过滤），最后清理无用快照。
如果您需要在 Elasticsearch 中保障数据安全并实现可追溯的恢复能力，则必须依赖其内置的 Snapshot 与 Restore 机制。以下是执行数据备份与从快照恢复的完整操作流程：
一、创建快照仓库（Repository）
快照仓库是存放所有快照文件的逻辑容器，必须先注册才能执行备份操作。仓库类型决定存储位置，如本地文件系统（fs）、阿里云 OSS、AWS S3 等。所有节点必须能访问该路径或服务，且需提前配置权限与网络连通性。
1、确认 Elasticsearch 配置文件 elasticsearch.yml 中已声明 path.repo 路径（仅 fs 类型必需）：
path.repo: ["/mnt/es_backup"]
2、重启 Elasticsearch 服务使配置生效。
3、在 Kibana Dev Tools 中执行以下命令注册名为 my_fs_backup 的本地文件系统仓库：
PUT /_snapshot/my_fs_backup
{"type": "fs", "settings": {"location": "/mnt/es_backup", "compress": true}}
4、验证仓库是否注册成功：
GET /_snapshot/my_fs_backup
5、若使用阿里云 OSS，需确保 RAM 用户具备 AliyunOSSFullAccess 权限，并使用包含 endpoint、access_key_id、secret_access_key、bucket 的完整 PUT 请求注册 oss 类型仓库。
二、执行 Snapshot 备份
快照默认为增量备份，首次为全量，后续仅保存自上次快照以来变更的数据块，大幅节省存储与时间开销。备份过程不阻塞集群读写，但会占用 I/O 和网络资源。
1、执行全量快照（备份全部索引）：
PUT /_snapshot/my_fs_backup/snapshot_20260512
{"wait_for_completion": true}
2、执行指定索引快照（例如仅备份 blog-test 和 my_index）：
PUT /_snapshot/my_fs_backup/snapshot_blog_only
{"indices": "blog-test,my_index", "ignore_unavailable": true, "include_global_state": false}
3、检查快照状态：
GET /_snapshot/my_fs_backup/snapshot_20260512
4、确认返回中 status 字段为 SUCCESS，且 indices 字段列出全部已备份索引及其分片数。
三、查看已有快照列表
在执行恢复前，需准确识别目标快照名称、时间戳及所含索引范围。快照元数据不包含监控索引（如 .monitoring.*）、Translog 或集群配置，仅保留用户索引数据。
1、列出指定仓库下全部快照：
GET /_snapshot/my_fs_backup/_all
2、按时间倒序筛选最近三个快照：
GET /_snapshot/my_fs_backup/_all?sort=duration&order=desc&size=3
3、获取快照详细统计信息（含各索引分片恢复进度）：
GET /_snapshot/my_fs_backup/snapshot_20260512/_status
4、注意：快照名称不可重复，若同名快照已存在，新请求将覆盖原快照元数据，但不会删除底层数据文件。
四、从快照恢复数据
恢复操作将快照中的索引重建至当前集群，支持全量恢复、部分索引恢复及索引重命名，适用于误删回滚、环境重建等场景。恢复期间目标索引不可写入，且需确保磁盘空间充足。
1、恢复全部索引（覆盖同名索引）：
POST /_snapshot/my_fs_backup/snapshot_20260512/_restore
{"wait_for_completion": true}
2、仅恢复特定索引并重命名以避免冲突：
POST /_snapshot/my_fs_backup/snapshot_20260512/_restore
{"indices": "blog-test", "rename_pattern": "blog-(.+)", "rename_replacement": "restored_blog_$1"}
3、跳过部分索引（如排除已损坏的索引）：
POST /_snapshot/my_fs_backup/snapshot_20260512/_restore
{"indices": "index_a,index_b", "ignore_unavailable": true}
4、验证恢复结果：
GET /restored_blog_test/_count
5、监控恢复进度：
GET /_recovery/restored_blog_test
五、删除不再需要的快照
快照本身不自动清理，长期积累将占用大量存储空间。删除快照仅移除元数据及对应数据块引用，实际文件将在下一次仓库清理时释放（fs 类型）或由 OSS 生命周期策略处理。
1、删除单个快照：
DELETE /_snapshot/my_fs_backup/snapshot_20260512
2、批量删除多个快照（用逗号分隔）：
DELETE /_snapshot/my_fs_backup/snapshot_20260510,snapshot_20260511
3、确认删除成功：
GET /_snapshot/my_fs_backup/_all | jq '.snapshots | length'
4、注意：删除操作不可逆，执行前请确保目标快照未被其他恢复任务引用，且已通过 GET /_snapshot/.../_status 确认其状态为 SUCCESS。
