SLM 是干什么的
SLM（snapshot lifecycle management）是集群内置的快照调度器：按 cron 周期自动创建快照，并按保留规则清理旧快照。它把"什么时候备份、保留多久"从散落的人工脚本变成集群内的策略对象，配合快照仓库使用，是 Elasticsearch 备份的标准做法。
为什么用 cron 加保留策略
schedule 采用 Quartz 风格的 cron 表达式，通常写成 6 段（秒 分 时 日 月 周），可以直接表达"每天凌晨 1 点 30 分"这类固定时点，不依赖脚本进程何时启动。name 支持日期数学语法，让快照名自动带上日期便于检索；retention 同时支持按时间过期与按份数保底，避免历史快照无限增长吃掉磁盘。
基本信息
| 创建或更新 | PUT /_slm/policy/<name> |
|---|---|
| 查看 | GET /_slm/policy、GET /_slm/status |
| 立即执行 | POST /_slm/policy/<name>/_execute |
| 保留规则 | expire_after（过期时间）、min_count（至少保留）、max_count（上限） |
| schedule | Quartz 风格 cron，通常 6 段 |
示例
示例
PUT /_slm/policy/nightly-snapshots
{
"schedule": "0 30 1 * * ?",
"name": "<nightly-snap-{now/d}>",
"repository": "my_backup",
"config": {
"indices": ["*"],
"include_global_state": false
},
"retention": {
"expire_after": "30d",
"min_count": 7,
"max_count": 60
}
}
# 手工跑一次，确认仓库与策略配置可用
POST /_slm/policy/nightly-snapshots/_execute
# 查看执行状态与已有快照
GET /_slm/status
GET /_cat/snapshots/my_backup?v典型使用场景
- 每日全量备份并自动清理，替代自己写的备份脚本与清理任务
- 变更前手工执行一次快照，作为可回滚的时间点
- 多套集群共用同一套备份规范时，用统一策略模板下发
- 审计：查 _slm/status 确认最近一次执行是否成功
- 磁盘水位管理：用 max_count 与 expire_after 控制历史快照总量
策略字段读法
| 字段 | 作用 | 注意 |
|---|---|---|
| schedule | 执行周期 | Quartz 风格 cron，含秒字段 |
| name | 快照命名 | 支持日期数学，重名会让执行失败 |
| config.indices | 备份范围 | 通配符范围要明确是否包含系统索引 |
| include_global_state | 是否包含集群状态 | 只有需要恢复集群级配置时才开启 |
| retention | 保留策略 | 过期时间与份数上限同时生效 |
SLM 依赖快照仓库可用：策略上线前先用 _execute 手工跑一次完整成功的快照，避免等第一次定时执行时才发现仓库不可写。
保留策略到点删除时如果快照正在运行会顺延，历史快照的实际磁盘占用要与容量规划一起核算，不能假设到点立刻腾空。