【Elasticsearch】快照与恢复功能详解

《Elasticsearch 集群》系列，共包含以下文章：

1️⃣ 冷热集群架构
2️⃣ 合适的锅炒合适的菜：性能与成本平衡原理公式解析
3️⃣ ILM（Index Lifecycle Management）策略详解
4️⃣ Elasticsearch 跨机房部署
5️⃣ 快照与恢复功能详解
6️⃣ Elasticsearch 快照恢复 API 参数详解
7️⃣ 安全地删除快照仓库、快照
8️⃣ 快照生命周期管理 SLM（理论篇）
9️⃣ 快照生命周期管理 SLM（实战篇）
🔟 跨集群检索（Cross-Cluster Search）

😊 如果您觉得这篇文章有用 ✔️ 的话，请给博主一个一键三连 🚀🚀🚀 吧（点赞 🧡、关注 💛、收藏 💚）！！！您的支持 💖💖💖 将激励 🔥 博主输出更多优质内容！！！

快照与恢复功能详解

1.核心概念
2.核心价值与优势
3.关键组件详解
- 3.1 快照仓库
- 3.2 快照
- 3.3 恢复
4.最佳实践与注意事项
5.总结

快照与恢复（Snapshot and Restore）功能是构建健壮、可恢复的 Elasticsearch 集群的 核心基石，用于 灾难恢复、数据迁移、版本升级回滚、环境复制 等关键场景。

1.核心概念

快照：是 Elasticsearch 集群状态 和 索引数据 在特定时间点的 只读副本。它不是简单的文件拷贝，而是利用 Elasticsearch 底层（Lucene）的特性高效捕获数据。
快照仓库：快照存储的位置。这是一个 持久化的共享存储系统，集群所有节点都能访问。Elasticsearch 不管理存储的生命周期（如清理旧快照），需在仓库层面管理。
恢复：将存储在快照仓库中的一个或多个快照的数据和元数据还原到集群中的过程。可以恢复到原集群或新集群。

2.核心价值与优势

灾难恢复：应对硬件故障、人为误删、软件缺陷导致的数据损坏或丢失。
数据迁移：
- 跨集群迁移（同版本或升级）。
- 跨云迁移或混合云部署。
- 从开发/测试环境迁移到生产环境。
版本升级/回滚：在重大升级前创建快照，升级失败可快速回滚到之前状态。
环境复制：将生产环境的数据快照恢复到测试或预发布环境，进行真实数据测试。
长期归档：将不再频繁访问但仍需保留的数据（符合合规要求）归档到成本更低的存储介质。
增量高效：
- 首次快照：是全量备份。
- 后续快照：默认是增量的！Elasticsearch 只会备份自上次快照以来 新增或修改的 Lucene 段文件。这极大地节省了存储空间和备份时间。
一致性保证：快照过程保证捕获的是 一致的时间点视图，即使索引正在被写入。这是通过利用 Lucene 的不可变段文件特性实现的。
灵活粒度：
- 可以备份 整个集群。
- 可以备份 特定的索引。
- 可以备份 特定的数据流。
- 可以包含 集群状态（包含索引模板、ILM 策略、Ingest Pipeline、索引别名、持久化任务等元数据）。
并行恢复：恢复操作可以在多个节点上并行执行，加快恢复速度。
云原生支持：与主流对象存储（AWS S3、Azure Blob Storage、Google GCS）深度集成，通过仓库插件实现。

3.关键组件详解

3.1 快照仓库

类型：由插件实现。常见类型：
- 共享文件系统（fs）：NFS、SAN、NAS。需确保所有节点挂载到同一路径，并有读写权限。
- 对象存储：
  - AWS S3（s3）：通过 repository-s3 插件。
  - Azure Blob Storage（azure）：通过 repository-azure 插件。
  - Google Cloud Storage（gcs）：通过 repository-gcs 插件。
  - 兼容 S3 API 的存储（如 MinIO、Ceph RGW）：也可使用 s3 类型。
- HDFS（hdfs）：通过 repository-hdfs 插件。

PUT /_snapshot/my_backup_repo
{"type": "s3","settings": {"bucket": "my-elasticsearch-backups","region": "us-west-1","access_key": "YOUR_ACCESS_KEY", // 推荐使用 IAM 角色或 Keystore"secret_key": "YOUR_SECRET_KEY", // 推荐使用 IAM 角色或 Keystore"base_path": "snapshots/prod_cluster" // 可选，仓库内的路径}
}

验证：
- 检查节点是否能连接仓库：GET /_snapshot/my_backup_repo/_verify。
管理：
- 查看所有仓库：GET /_snapshot 。
- 删除仓库（不会删除仓库内快照数据）：DELETE /_snapshot/my_backup_repo 。

3.2 快照

创建：

PUT /_snapshot/my_backup_repo/my_snapshot_20230720?wait_for_completion=true
{"indices": "index_1,index_2,data_stream_*", // 可选，默认备份所有 open 的索引和数据流"ignore_unavailable": true, // 忽略不存在的索引"include_global_state": true, // 可选，默认 true，是否包含集群状态"partial": false // 可选，默认 false。true 允许部分索引备份成功（有未分配分片时）。生产环境慎用！
}

wait_for_completion=true 会阻塞直到完成。大型集群建议设为 false，通过 API 监控进度。

增量性：自动识别并仅备份新/改的段文件。仓库维护一个快照链。
监控：
- 查看特定快照状态：GET /_snapshot/my_backup_repo/my_snapshot_20230720。
- 查看详细进度和统计信息：GET /_snapshot/my_backup_repo/my_snapshot_20230720/_status。
- 查看所有正在运行的快照：GET /_snapshot/_status。
删除：
- DELETE /_snapshot/my_backup_repo/my_snapshot_20230720。
- 重要： Elasticsearch 会清理 仅被该快照引用 的段文件。被其他快照共享的段文件不会被删除。删除是安全的操作。

3.3 恢复

基本恢复：

POST /_snapshot/my_backup_repo/my_snapshot_20230720/_restore?wait_for_completion=false
{"indices": "index_1,index_2", // 可选，默认恢复快照中所有索引"ignore_unavailable": true,"include_global_state": false, // 强烈建议设置为 false！除非明确需要恢复集群级设置"include_aliases": false, // 可选，是否恢复索引别名"index_settings": { // 可选，覆盖恢复索引的设置"index.number_of_replicas": 0 // 例如恢复时先不加副本加快速度},"ignore_index_settings": ["index.refresh_interval"] // 可选，忽略某些设置
}

重命名索引 / 更改数据流：使用 rename_pattern 和 rename_replacement 参数在恢复时重命名索引或更改数据流名称。

POST /_snapshot/my_backup_repo/my_snapshot_20230720/_restore
{"indices": "logs-prod-*","rename_pattern": "logs-prod-(.+)","rename_replacement": "logs-test-$1" // 将 logs-prod- 前缀改为 logs-test-
}

选择性恢复：可以只恢复特定索引，甚至使用 include_aliases 和 index_settings 精细控制。
部分恢复：如果快照创建时允许 partial，即使有分片缺失也能恢复（数据不完整）。
监控恢复：
- 恢复 API 返回的 task_id 可用于 GET /_tasks/{task_id}。
- 索引恢复状态：GET /_recovery 或 GET /index_1/_recovery。
- 集群健康：GET /_cluster/health 关注 initializing_shards 和 relocating_shards。
冲突处理：如果要恢复的索引在目标集群中 已存在且打开，恢复操作 默认会失败。必须先关闭或删除目标集群中的现有索引。

4.最佳实践与注意事项

仓库选择：
- 生产环境：强烈推荐使用云对象存储（S3、GCS、Azure Blob）或高度可靠的共享文件系统。 避免使用本地路径。
- 权限与安全：严格配置仓库访问权限（IAM 角色、存储桶策略）。使用 Elasticsearch Keystore 存储敏感凭证。
- 生命周期管理：在存储系统层面配置策略，自动归档或删除旧快照（Elasticsearch 本身不自动清理）。
快照策略：
- 定期快照：使用 Elasticsearch SLM（Snapshot Lifecycle Management） 自动化创建、保留和删除快照。定义策略（如每小时、每天、每周），保留策略（如保留最后 $30$ 天快照，每周保留一个快照持续 $12$ 个月）。
- 命名规范：使用清晰一致的命名（如 daily-20230720）。
- 测试恢复！定期进行恢复演练 是确保备份有效性的唯一方法。恢复到隔离环境验证。
恢复策略：
- include_global_state: false： 恢复生产快照到非生产环境时，几乎总是将此设置为 false！ 避免覆盖目标集群的模板、ILM 策略等关键配置。
- 副本设置：恢复时临时设置 index.number_of_replicas: 0 可以显著加快恢复速度（数据只恢复一份）。恢复完成后，再调整副本数。
- 资源规划 ：恢复是资源密集型操作（网络 I/O、磁盘 I/O、CPU）。确保目标集群有足够资源，避免影响线上业务。考虑在维护窗口进行。
- 版本兼容性：快照具有 向后兼容性：
  - 你可以将 N.x 的快照恢复到 >= N.x 的集群（例如 7.17 快照 → 8.10 集群）。
  - 不能将 N.x 的快照恢复到 < N.x 的集群（例如 8.10 快照 → 7.17 集群）。需要先恢复到同版本或更高版本，再使用 Reindex API 或 Logstash 等工具向下迁移。
监控与告警：
- 监控 SLM 作业执行状态（成功/失败）。
- 监控快照创建/恢复的持续时间、速度。
- 监控仓库存储空间使用情况。
- 设置告警规则（如快照连续失败、仓库空间不足）。
性能考量：
- 快照/恢复速度受限于 网络带宽（到仓库）和 存储 I/O 性能（源/目标集群磁盘、仓库）。
- 大型集群的快照可能需要数小时。使用 wait_for_completion=false 并异步监控。
- 调整 thread_pool（如 snapshot、generic）大小需谨慎，评估对集群性能的影响。

5.总结

Elasticsearch 的快照与恢复是一个 强大、灵活且高效 的机制，是任何严肃的生产部署不可或缺的一部分。通过理解其增量备份原理、仓库管理、SLM 自动化以及细致的恢复策略（特别是 include_global_state 的处理），Elasticsearch 工程师能够构建可靠的数据保护、迁移和灾难恢复方案。