Elasticsearch snapshot 与 restore（fs / S3 repository、SLM）

为已安装的 Elasticsearch 8.x / 9.x 集群建立 snapshot（备份）机制并说明恢复方法：共享文件系统（NFS + path.repo）或 S3（keystore）repository，通过 rolling restart 生效并验证，手动 snapshot（indices、include_global_state、feature_states），用 SLM 定时 snapshot 并设置保留策略（expire_after/min_count/max_count），以新名称或在已关闭的索引上 restore，feature state restore，监控，以及将同一 repository 以只读方式注册到其他集群进行迁移。最终得到每天自动生成、且已验证可恢复的 snapshot。在 Elasticsearch 中 snapshot 是唯一有效的备份方式；同一集群内修改 mapping/shard 用 reindex，快速找回单个索引请使用运维指南中的场景。

架构: Elasticsearch 8.x / 9.x 集群（1–N 个节点）+ 共享目录（NFS）或 S3 兼容对象存储

开始之前

• 集群健康（green），并且掌握 elastic（或具有 manage + snapshot 权限的用户）的密码。由于 repository 设置需要重启节点，请确认集群能承受一个节点离线（replica 已分配）。
• 每个节点上都有 HTTP CA 文件（…）；API 调用用此 CA 校验。
• … 在所有 master 和 data 节点上挂载自同一个共享（NFS），并已写入 fstab 持久化。elasticsearch 用户的 UID/GID 必须在所有节点上一致，或者共享通过 all_squash,anonuid=…,anongid=… 映射为单一用户；否则节点之间无法读取彼此写入的文件。在多节点集群中使用本地（非共享）目录，repository 验证会失败。
• … bucket 已创建；访问密钥（access key / secret key）在该 bucket 上具有 s3:ListBucket、s3:GetObject、s3:PutObject、s3:DeleteObject、s3:AbortMultipartUpload、s3:ListMultipartUploadParts 和 s3:ListBucketMultipartUploads 权限。节点能通过 HTTPS 访问 …。
• 共享上有足够的可用空间：第一次 snapshot 占用与索引磁盘大小相当的空间，之后只增加变化的 segment（增量）。
• 已清楚版本规则：snapshot 只能 restore 到相同或更新版本的集群，不能 restore 到旧版本。一个索引最多只能 restore 到其创建时主版本的下一个主版本（8.x 中创建的索引可以到 9.x；7.x 中创建的索引不能作为普通索引 restore 到 9.x）。
• 在所有节点上有 root 权限，并有用于 rolling restart 的维护窗口。

指南阶段

• API 访问（所有节点） — API 用的临时凭据文件 · 检查集群和已有 repository
• 准备共享文件系统（所有节点） — 挂载 NFS 共享 · 设置目录权限并测试写入 · 添加 path.repo 设置
• S3 凭据与 client 设置（所有节点） — 将 S3 访问密钥加入 keystore · 添加 S3 client 设置
• 注册并验证 repository — 注册 repository · 验证 repository
• 手动 snapshot — 创建测试索引 · 生成 snapshot · 监控 snapshot 状态
• 用 SLM 自动生成 snapshot — 创建 SLM 策略 · 立即执行策略 · 检查 SLM 状态和统计信息 · 手动执行 retention
• Restore — 以新名称 restore 索引 · 监控 restore 并比较文档数 · 删除恢复出的副本 · 关闭索引并原地 restore · Restore feature state
• 迁移到其他集群 — 准备目标集群 · 以只读方式注册 repository · 在目标集群上 restore 索引 · 删除目标上的凭据文件
• 监控与维护 — 监控 snapshot 健康状况 · 清理 repository · 删除凭据文件 · 定期恢复演练