快照生命周期管理 SLM(实战篇)
本文是一个基于 Elasticsearch 快照生命周期管理(SLM) 的详细实现案例,涵盖从配置到恢复的全流程。我们将以一个电商平台的日志集群为例,演示如何通过 SLM 实现自动化备份与保留策略。
1.案例背景
电商平台每天产生 2TB 日志(索引格式:logs-nginx-2024.07.21
)。
- 业务需求:
- 每天凌晨备份全量索引
- 保留最近 7 天快照(高频恢复点)
- 每月 1 日快照保留 1 年(合规审计)
- 存储成本优化(自动清理旧快照)
- 基础设施:
- Elasticsearch 集群:8 节点(版本 7.10+)
- 快照仓库:AWS S3(桶名:
es-snapshots-prod
) - 定时任务:Kibana 调度
2.实战演练
2.1 SLM 实现全流程
2.1.1 步骤 1:配置 S3 快照仓库
在 Elasticsearch 中注册 S3 仓库(需提前配置 IAM 权限):
PUT _snapshot/es-s3-backup
{
"type": "s3",
"settings": {
"bucket": "es-snapshots-prod",
"region": "us-east-1",
"role_arn": "arn:aws:iam::123456789012:role/es-snapshot-role"
}
}
验证:检查仓库状态
GET _snapshot/es-s3-backup/_status
2.1.2 步骤 2:创建 SLM 策略
定义两个策略:
- 1️⃣ 每日备份(保留 7 天)
- 2️⃣ 月度归档(保留 1 年)
# 策略1:每日备份(保留7天)
PUT _slm/policy/daily_logs_backup
{
"schedule": "0 2 * * *", // 每天凌晨2点执行
"name": "<logs-daily-{now/d}>", // 快照名称格式
"repository": "es-s3-backup",
"config": {
"indices": ["logs-nginx-*"], // 备份所有Nginx日志索引
"include_global_state": false
},
"retention": {
"expire_after": "7d" // 7天后自动删除
}
}
# 策略2:月度归档(保留1年)
PUT _slm/policy/monthly_logs_archive
{
"schedule": "0 3 1 * *", // 每月1日凌晨3点执行
"name": "<logs-monthly-{now/M{yyyy.MM}}>",
"repository": "es-s3-backup",
"config": {
"indices": ["logs-nginx-*"],
"include_global_state": false
},
"retention": {
"expire_after": "365d" // 365天后删除
}
}
2.1.3 步骤 3:手动执行测试
触发一次策略以验证配置:
POST _slm/policy/daily_logs_backup/_execute
检查结果:
GET _snapshot/es-s3-backup/_all?pretty // 查看已生成快照
2.1.4 步骤 4:监控 SLM 运行
通过 Kibana 或 API 监控任务状态:
- Kibana 路径:
Management
→Snapshot and Restore
→Policies
- API 监控:
GET _slm/policy/daily_logs_backup?human // 查看上次执行时间/错误信息
2.1.5 步骤 5:恢复数据测试
模拟从快照恢复数据(恢复前 3 天的日志):
POST _snapshot/es-s3-backup/logs-daily-2024.07.18/_restore
{
"indices": "logs-nginx-2024.07.18", // 指定索引
"rename_pattern": "(.+)", // 重命名恢复的索引(避免冲突)
"rename_replacement": "restored_$1" // 如 restored_logs-nginx-2024.07.18
}
恢复验证:
GET _cat/indices/restored_logs-nginx* // 检查索引是否恢复
2.2 关键运维操作详解
2.2.1 清理失效快照
手动清理因策略变更遗留的快照:
DELETE _snapshot/es-s3-backup/logs-daily-2024.07.01?pretty
2.2.2 修改保留策略
将每日备份保留期从 7 天延长至 14 天:
PUT _slm/policy/daily_logs_backup
{
... // 其他参数不变
"retention": {
"expire_after": "14d" // 更新保留时间
}
}
2.2.3 灾难恢复流程
若生产集群崩溃,从 S3 重建集群:
- 在新集群注册同一 S3 仓库。
- 列出可恢复的快照:
GET _snapshot/es-s3-backup/_all?pretty
- 恢复最新快照:
POST _snapshot/es-s3-backup/logs-daily-2024.07.20/_restore
2.3 SLM 执行逻辑剖析
2.4 最佳实践建议
- 仓库分离:
- 生产快照存于独立 S3 Bucket(与应用程序数据隔离)。
- 启用 S3 版本控制防止误删。
- 加密与权限:
// 创建仓库时启用加密 "settings": { "server_side_encryption": true, "readonly": true // 禁止直接写入仓库 }
- 性能优化:
- 避免备份期间进行
force_merge
(可能阻塞 SLM)。 - 大型集群分批次备份(通过
indices
参数拆分)。
- 避免备份期间进行
- 监控告警:
- 配置 Kibana Alert:当 SLM 连续失败 2 次时触发邮件告警。
- 定期检查 S3 存储量(避免快照占满空间)。
2.5 常见问题排查
问题现象 | 原因分析 | 解决方案 |
---|---|---|
SLM 任务状态为 FAILED | 仓库权限不足 / S3 桶空间不足 | 检查 IAM 角色策略 / 清理 S3 旧数据 |
快照恢复后索引为只读 | 未正确关闭索引 | 执行 POST /restored_index/_open |
保留策略未删除旧快照 | 时间计算错误(时区问题) | 调整策略为 UTC 时间或时区偏移 |
✅ 关键命令总结:
- 创建策略:
PUT _slm/policy/<name>
- 手动执行:
POST _slm/policy/<name>/_execute
- 恢复数据:
POST _snapshot/<仓库>/<快照>/_restore
- 删除快照:
DELETE _snapshot/<仓库>/<快照>
相信聪明的你已经完整掌握 SLM 在真实场景中的落地过程,实现 “备份自动化 + 成本可控 + 一键恢复” 的核心目标。