《Elasticsearch 集群》系列，共包含以下文章：
- 1?? 冷熱集群架構
- 2?? 合適的鍋炒合適的菜：性能與成本平衡原理公式解析
- 3?? ILM（Index Lifecycle Management）策略詳解
- 4?? Elasticsearch 跨機房部署
- 5?? 快照與恢復功能詳解
- 6?? Elasticsearch 快照恢復 API 參數詳解
- 7?? 安全地刪除快照倉庫、快照
- 8?? 快照生命周期管理 SLM（理論篇）
- 9?? 快照生命周期管理 SLM（實戰篇）
- 🔟 跨集群檢索（Cross-Cluster Search）
😊 如果您覺得這篇文章有用 ?? 的話，請給博主一個一鍵三連 🚀🚀🚀 吧 （點贊 🧡、關注 💛、收藏 💚）！！！您的支持 💖💖💖 將激勵 🔥 博主輸出更多優質內容！！！
快照生命周期管理 SLM（理論篇）
- 1.快照生命周期管理（SLM）
- 2.索引生命周期管理（ILM）
- 3.SLM 與 ILM 的核心區別
- 3.1 管理目標不同
- 3.2 操作對象不同
- 3.3 策略驅動因素不同
- 3.4 典型使用場景
- 4.協同工作場景
- 5.總結對比表
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 數據治理的核心框架，建議在大型生產環境中配合使用。
)
