Elasticsearch 每日备份与恢复操作最佳实践

每日备份可保护您的 Elasticsearch 集群免受副本无法修复的故障：意外删除、错误映射、数据损坏、升级失败以及整个集群丢失。副本有助于提高可用性，但快照才是让您恢复到已知良好副本的关键。

这些 Elasticsearch 每日备份与恢复操作的最佳实践涵盖了仓库设置、快照生命周期管理（SLM）、恢复测试以及索引生命周期管理（ILM）的适用场景。

理解 Elasticsearch 快照机制

Elasticsearch 快照不仅仅是文件复制；它们是增量式的，利用了 Lucene 索引的内部结构。这意味着在初始完整快照之后，后续快照仅存储自上次成功快照以来发生更改的数据段，从而在时间和存储方面实现高效。

快照捕获两个主要组件：

索引数据： 所选索引的实际 Lucene 段。
集群状态： 元数据、持久设置、索引模板、管道和角色。

1. 建立快照仓库

在拍摄任何快照之前，您必须注册一个仓库：存储快照文件的安全位置。仓库的选择对于持久性和恢复速度至关重要。

仓库类型

仓库类型	描述	最适合	要求
`fs`（共享文件系统）	所有主节点和数据节点可访问的本地或网络挂载驱动器。	小型集群，快速本地备份。	必须在 `elasticsearch.yml`（`path.repo`）中注册。
`s3`、`azure`、`gcs`	云存储服务。某些发行版和版本捆绑了这些仓库类型；其他版本需要在每个节点上安装匹配的仓库插件。	生产环境，灾难恢复。	版本适当的仓库支持和正确的 IAM/服务主体凭据。

示例：注册 S3 仓库

对于生产环境，云存储通常是持久性和异地恢复的更好选择。确认您的 Elasticsearch 版本支持仓库，安全配置凭据，然后通过 API 注册仓库。

PUT /_snapshot/my_s3_daily_repo
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup-bucket-name",
    "region": "us-east-1",
    "base_path": "daily_snapshots/production",
    "compress": true
  }
}

提示： 确保配置的存储桶或文件系统路径安全、不可变（如果您的提供商支持），并且专用于备份。

2. 使用 SLM 实现每日自动化

手动快照适用于一次性操作，但例行的每日备份必须使用快照生命周期管理（SLM）进行自动化。SLM 是 Elasticsearch 内部的原生机制，专门用于定义计划、保留策略和管理快照。

定义 SLM 策略

典型的每日策略定义了一个计划、要包含（或排除）的索引以及快照的保留时间。

PUT /_slm/policy/daily_archive_policy
{
  "schedule": "0 30 1 * * ?",
  "name": "<daily-{{now/d}}>",
  "repository": "my_s3_daily_repo",
  "config": {
    "indices": ["logstash-*", "application-metrics-*"],
    "ignore_unavailable": true,
    "include_global_state": false
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 30
  }
}

关键 SLM 配置点：

schedule： 使用 Quartz cron 语法（例如，0 30 1 * * ? 表示每天凌晨 1:30 运行）。安排在低使用率时段。
include_global_state: false： 对于每日数据备份，通常最好排除集群状态，以防止在恢复期间意外回滚状态。
retention： 定义清理计划。上面的示例将快照保留 30 天，确保至少保留 5 个且不超过 30 个。

监控 SLM

定期检查策略的状态，确保它们成功执行。

GET /_slm/status
GET /_slm/policy/daily_archive_policy

3. 与索引生命周期管理（ILM）集成

对于大型时间序列数据（例如日志和指标），索引生命周期管理（ILM）管理从创建到删除的索引。ILM 不会取代每日 SLM 快照，但它可以帮助您协调删除与完成的快照策略。

ILM 和数据分层

在 ILM 删除旧索引之前，您可以让删除阶段等待 SLM 策略运行。这为您的每日或长期快照策略提供了在索引从集群中删除之前捕获数据的机会。

创建一个 SLM 策略，对相关索引模式进行快照。
使用 wait_for_snapshot 从 ILM 删除阶段引用该 SLM 策略。

...
"delete": {
  "min_age": "90d",
  "actions": {
    "wait_for_snapshot": {
      "policy": "daily_archive_policy"
    },
    "delete": {}
  }
}
...

这会在 ILM 删除索引之前等待来自指定 SLM 策略的成功快照。如果您使用数据流，请在暂存环境中测试生命周期流程，以便了解快照策略覆盖了哪些后备索引。

如果您的目标是将较旧的可搜索数据保留在更便宜的存储上而不是删除它，请查看冷阶段或冻结阶段中的可搜索快照操作。这与普通的灾难恢复快照模式不同：

...
"cold": {
  "min_age": "30d",
  "actions": {
    "searchable_snapshot": {
      "snapshot_repository": "my_s3_daily_repo"
    }
  }
}
...

每个目标使用一个生命周期模式：SLM 用于可恢复的备份，wait_for_snapshot 用于删除前，以及可搜索快照用于需要低成本搜索访问时。

4. 恢复测试的最佳实践

没有经过验证的恢复策略，备份例程是不完整的。您必须定期测试恢复过程，以验证数据完整性并满足恢复时间目标（RTO）。

恢复测试环境

不要直接在实时生产集群上测试恢复。 使用专用的暂存或测试环境，该环境运行兼容的 Elasticsearch 版本，并有足够的磁盘空间用于恢复的分片。
频率： 至少每季度测试一次恢复，或在重大升级/配置更改后测试。

执行恢复

恢复可以针对特定索引或整个集群状态。

步骤 1：获取快照详细信息

确定需要恢复的快照名称。

GET /_snapshot/my_s3_daily_repo/_all

步骤 2：执行恢复操作

要恢复特定索引，请使用 indices 参数。在恢复期间通常需要重命名索引，以避免与活动索引冲突（尤其是在测试环境中）。

POST /_snapshot/my_s3_daily_repo/snapshot_20240501/_restore
{
  "indices": ["logstash-2024-05-01"],
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1",
  "include_aliases": false
}

验证恢复成功

恢复后，验证分片健康和文档计数。计数匹配很有用，但也要运行应用程序依赖的示例查询。

GET /_cluster/health/restored-logstash-2024-05-01?wait_for_status=green&timeout=60s
GET /restored-logstash-2024-05-01/_count

5. 安全与性能考虑

安全

仓库访问： 确保 Elasticsearch 用于访问仓库的凭据遵循仓库路径的最小权限原则。实际上，快照管理需要对其拥有的对象具有读取、写入、列出和删除权限，尤其是在保留策略删除旧快照时。
加密： 利用启用了服务器端加密（SSE-S3 或 SSE-KMS）的安全仓库（如 S3）。

性能限制

快照可能对 I/O 密集。如果在快照窗口期间注意到性能下降，请在仓库级别限制快照流量。对于许多仓库类型，相关设置是在注册或更新仓库时的 max_snapshot_bytes_per_sec 和 max_restore_bytes_per_sec。

PUT /_snapshot/my_s3_daily_repo
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup-bucket-name",
    "region": "us-east-1",
    "base_path": "daily_snapshots/production",
    "max_snapshot_bytes_per_sec": "100mb",
    "max_restore_bytes_per_sec": "100mb"
  }
}

indices.recovery.max_bytes_per_sec 控制对等和快照恢复流量，因此只有在了解对分片恢复的影响时才进行调整。尽可能将快照计划安排在峰值索引和搜索窗口之外。

每日备份工作流程

配置持久化仓库： 在生产环境中使用云存储（S3/Azure/GCS）。
定义 SLM 策略： 使用 SLM 安排快照（例如，每天凌晨 1:30），并设置适当的保留规则。
协调 ILM（如果适用）： 在删除前使用 wait_for_snapshot，或使用可搜索快照实现低成本的可搜索历史记录。
监控状态： 通过 _slm/policy 和 _slm/status API 定期验证 SLM 策略执行情况。
测试恢复： 每季度或每半年，在隔离环境中执行完整恢复，以验证 RTO 准备情况。

有用的备份是您可以恢复的备份。保持每日 SLM 策略简单，监控失败，并定期安排恢复演练，以便您的团队在事件发生前了解确切的步骤。