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

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

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

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

快照与恢复（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 工程师能够构建可靠的数据保护、迁移和灾难恢复方案。

🚀 切记：备份的价值只有在成功恢复时才能体现，因此定期的恢复演练至关重要。