Elasticsearch 集群如何配置快照仓库实现数据定期备份

Elasticsearch 集群备份不能直接拷贝数据文件，必须通过快照 API 配合共享存储或对象存储来实现。生产环境建议优先选用 S3 兼容存储并配合快照生命周期管理（SLM）实现定期自动化备份。

先说结论：原生快照机制是唯一官方支持的备份方式，直接拷贝 data 目录会导致数据损坏。

适合：需要定期保留索引状态、支持跨集群恢复或灾难重建的场景。
先准备：确保所有节点能访问统一的共享存储（如 NFS、S3）并配置好权限。
验收：手动执行一次快照并尝试恢复到测试集群，确认数据完整性。

核心配置准备

在使用文件系统快照前，必须在所有节点的 elasticsearch.yml 中明确允许备份路径。

path.repo: ["/mnt/backups/es"]

修改后需重启节点生效。若使用 S3 存储，无需配置 path.repo，但需安装 repository-s3 插件。

注册快照仓库

1. 文件系统类型（FS）

PUT /_snapshot/my_backup
{
  "type": "fs",
  "settings": {
    "location": "/mnt/backups/es",
    "compress": true
  }
}

2. S3 对象存储类型

建议通过 Keystore 管理密钥，避免明文泄露。

bin/elasticsearch-keystore add s3.access_key
bin/elasticsearch-keystore add s3.secret_key

注册仓库命令：

PUT /_snapshot/my_s3_backup
{
  "type": "s3",
  "settings": {
    "bucket": "my-es-backup-bucket",
    "region": "cn-north-1",
    "base_path": "elasticsearch"
  }
}

配置自动化策略 (SLM)

为实现标题所述的“定期备份”，需配置 Snapshot Lifecycle Management 策略。

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

上述策略表示每天凌晨 1:30 执行，保留最近 30 天或至少 5 个快照。

验证与监控

使用以下命令查看仓库状态及快照执行情况：

GET /_snapshot/_all
GET /_snapshot/my_backup/_all
GET _slm/policy/daily_snapshots/_status

重点关注 state 字段是否为 SUCCESS，以及 next_execution_millis 是否符合预期。

常见风险与排查

1. 权限问题：ES 进程用户必须对备份目录有读写权限，否则注册会报 filesystem exception。

2. 密钥安全：切勿将 S3 密钥明文写在 HTTP 请求体中，生产环境务必使用 Keystore 存储。

3. 版本兼容：高版本 ES 创建的快照通常不能直接恢复到低版本集群，升级前务必备份。

4. 只读仓库：如果误将仓库配置为只读，将无法创建新快照，只能用于恢复。