【Elasticsearch】快照生命周期管理 SLM（理论篇）

1.快照生命周期管理（SLM）

SLM（Snapshot Lifecycle Management）是 Elasticsearch 中 自动化管理索引快照的策略，用于定期创建集群快照、定义保留策略，确保灾难恢复能力。

核心功能：

• 定时创建快照（如每天凌晨2点）
• 自动清理旧快照（保留最近30天，删除更早版本）
• 跨仓库管理（支持本地/云存储如 AWS S3、Azure Blob）

提出背景：

• 手动备份低效：大规模集群需备份数百个索引，人工操作易遗漏。
• 存储成本失控：历史快照堆积占用大量云存储空间。
• RTO / RPO 需求：业务要求明确恢复时间点（如最多丢失 1 小时数据）。

解决的问题：

• ✅ 自动化备份 → 减少人工干预
• ✅ 精确保留策略 → 降低存储成本
• ✅ 保障可恢复性 → 满足 SLA 要求

2.索引生命周期管理（ILM）

ILM（Index Lifecycle Management）是 Elasticsearch 中 自动化管理索引生命周期的策略，根据年龄、大小等条件将索引动态迁移到不同性能/成本的存储层。

生命周期阶段：

阶段	操作	典型配置
Hot	高频读写（SSD存储）	rollover（达 50GB 切新索引）
Warm	低频查询（HDD存储）	shrink（减少分片数）
Cold	极少访问（低成本存储）	freeze（冻结索引）
Delete	删除过期数据	delete（保留 30 天后删除）

提出背景：

• 性能与成本矛盾：新索引需高性能（SSD），旧索引可存于廉价存储。
• 手动轮转低效：人工迁移索引易出错，尤其日志类应用（如 Filebeat 日增数百索引）。
• 存储优化需求：冷数据无需占用高价存储资源。

解决的问题：

• ✅ 存储分层优化 → 降低硬件成本
• ✅ 自动索引轮转 → 提升集群稳定性
• ✅ 资源按需分配 → 平衡性能与成本

3.SLM 与 ILM 的核心区别

3.1 管理目标不同

维度	SLM	ILM
焦点	数据备份与恢复（快照副本）	索引存储优化（原始数据分层）
本质	灾备机制	资源调度机制

3.2 操作对象不同

类型	SLM	ILM
操作目标	集群快照（.snapshot 文件）	原始索引（如 logs-2023-10-01-000001）
存储位置	外部仓库（S3 / HDFS / NFS）	集群内部节点（Hot / Warm / Cold 数据节点）

3.3 策略驱动因素不同

策略类型	SLM	ILM
触发条件	时间计划（Cron 表达式）	索引年龄 / 大小 / 文档数
关键动作	create_snapshot，delete_snapshot	rollover，shrink，freeze，delete

3.4 典型使用场景

场景	SLM 示例	ILM 示例
日志管理	每日备份所有索引到 S3	7 天内日志存 Hot 节点（SSD），30 天后删除
安全合规	保留审计日志快照 5 年	合规数据在 Cold 阶段保留 1 年后删除

4.协同工作场景

两者通常配合使用以实现完整数据治理：

• ILM 管理在线数据
• SLM 管理离线备份

协同价值：

• ILM 删除原始索引后，SLM 仍保留其快照（满足长期归档需求）。
• 恢复时：先从 SLM 快照还原，再由 ILM 自动分配到合适存储层。

5.总结对比表

特性	SLM	ILM
英文全称	Snapshot Lifecycle Management	Index Lifecycle Management
核心目标	数据备份与恢复	索引存储分层与优化
操作对象	集群快照（副本）	原始索引（数据本身）
关键操作	创建 / 删除快照	Rollover / Shrink / Freeze / Delete
存储位置	外部仓库（如 S3）	集群内部节点（Hot / Warm / Cold）
Elasticsearch API	PUT _slm/policy/daily_backups	PUT _ilm/policy/logs_policy

✅ 一句话区分：

• ILM 管理 “活数据”（在线索引如何存储和迁移），SLM 管理 “数据备份”（如何保存和恢复快照）。
• 协同关系：ILM 负责数据的 “生老病死”，SLM 负责 “拍遗照留念” 以备恢复。

两者共同构成 Elasticsearch 数据治理的核心框架，建议在大型生产环境中配合使用。