《Elasticsearch 集群》系列，共包含以下文章：
- 1?? 冷熱集群架構
- 2?? 合適的鍋炒合適的菜：性能與成本平衡原理公式解析
- 3?? ILM（Index Lifecycle Management）策略詳解
- 4?? Elasticsearch 跨機房部署
- 5?? 快照與恢復功能詳解
- 6?? Elasticsearch 快照恢復 API 參數詳解
- 7?? 安全地刪除快照倉庫、快照
- 8?? 快照生命周期管理 SLM（理論篇）
- 9?? 快照生命周期管理 SLM（實戰篇）
- 🔟 跨集群檢索（Cross-Cluster Search）
😊 如果您覺得這篇文章有用 ?? 的話，請給博主一個一鍵三連 🚀🚀🚀 吧 （點贊 🧡、關注 💛、收藏 💚）！！！您的支持 💖💖💖 將激勵 🔥 博主輸出更多優質內容！！！
快照與恢復功能詳解
- 1.核心概念
- 2.核心價值與優勢
- 3.關鍵組件詳解
- 3.1 快照倉庫
- 3.2 快照
- 3.3 恢復
- 4.最佳實踐與注意事項
- 5.總結
快照與恢復（Snapshot and Restore）功能是構建健壯、可恢復的 Elasticsearch 集群的 核心基石，用于 災難恢復、數據遷移、版本升級回滾、環境復制 等關鍵場景。
1.核心概念
- 快照：是 Elasticsearch 集群狀態 和 索引數據 在特定時間點的 只讀副本。它不是簡單的文件拷貝，而是利用 Elasticsearch 底層（Lucene）的特性高效捕獲數據。
- 快照倉庫：快照存儲的位置。這是一個 持久化的共享存儲系統，集群所有節點都能訪問。Elasticsearch 不管理存儲的生命周期（如清理舊快照），需在倉庫層面管理。
- 恢復：將存儲在快照倉庫中的一個或多個快照的數據和元數據 還原 到集群中的過程。可以恢復到原集群或新集群。
2.核心價值與優勢
- 災難恢復：應對硬件故障、人為誤刪、軟件缺陷導致的數據損壞或丟失。
- 數據遷移：
- 跨集群遷移（同版本或升級）。
- 跨云遷移或混合云部署。
- 從開發/測試環境遷移到生產環境。
- 版本升級/回滾：在重大升級前創建快照，升級失敗可快速回滾到之前狀態。
- 環境復制：將生產環境的數據快照恢復到測試或預發布環境，進行真實數據測試。
- 長期歸檔：將不再頻繁訪問但仍需保留的數據（符合合規要求）歸檔到成本更低的存儲介質。
- 增量高效：
- 首次快照：是全量備份。
- 后續快照：默認是 增量 的！Elasticsearch 只會備份自上次快照以來 新增或修改的 Lucene 段文件。這極大地節省了存儲空間和備份時間。
- 一致性保證：快照過程保證捕獲的是 一致的時間點視圖，即使索引正在被寫入。這是通過利用 Lucene 的不可變段文件特性實現的。
- 靈活粒度：
- 可以備份 整個集群。
- 可以備份 特定的索引。
- 可以備份 特定的數據流。
- 可以包含 集群狀態（包含索引模板、ILM 策略、Ingest Pipeline、索引別名、持久化任務等元數據）。
- 并行恢復：恢復操作可以在多個節點上并行執行，加快恢復速度。
- 云原生支持：與主流對象存儲（AWS S3、Azure Blob Storage、Google GCS）深度集成，通過倉庫插件實現。
3.關鍵組件詳解
3.1 快照倉庫
- 類型：由插件實現。常見類型：
- 共享文件系統（
fs）：NFS、SAN、NAS。需確保所有節點掛載到同一路徑，并有讀寫權限。 - 對象存儲：
- AWS S3（
s3）：通過repository-s3插件。 - Azure Blob Storage（
azure）：通過repository-azure插件。 - Google Cloud Storage（
gcs）：通過repository-gcs插件。 - 兼容 S3 API 的存儲（如 MinIO、Ceph RGW）：也可使用
s3類型。
- AWS S3（
- HDFS（
hdfs）：通過repository-hdfs插件。
- 共享文件系統（
- 注冊：倉庫必須 先注冊 才能使用。注冊是集群級別的操作。
PUT /_snapshot/my_backup_repo {"type": "s3","settings": {"bucket": "my-elasticsearch-backups","region": "us-west-1","access_key": "YOUR_ACCESS_KEY", // 推薦使用 IAM 角色或 Keystore"secret_key": "YOUR_SECRET_KEY", // 推薦使用 IAM 角色或 Keystore"base_path": "snapshots/prod_cluster" // 可選，倉庫內的路徑} } - 驗證：
- 檢查節點是否能連接倉庫：
GET /_snapshot/my_backup_repo/_verify。
- 檢查節點是否能連接倉庫：
- 管理：
- 查看所有倉庫：
GET /_snapshot。 - 刪除倉庫（不會刪除倉庫內快照數據）：
DELETE /_snapshot/my_backup_repo。
- 查看所有倉庫：
3.2 快照
- 創建：
PUT /_snapshot/my_backup_repo/my_snapshot_20230720?wait_for_completion=true {"indices": "index_1,index_2,data_stream_*", // 可選，默認備份所有 open 的索引和數據流"ignore_unavailable": true, // 忽略不存在的索引"include_global_state": true, // 可選，默認 true，是否包含集群狀態"partial": false // 可選，默認 false。true 允許部分索引備份成功（有未分配分片時）。生產環境慎用！ }wait_for_completion=true會阻塞直到完成。大型集群建議設為false，通過 API 監控進度。
- 增量性：自動識別并僅備份新/改的段文件。倉庫維護一個快照鏈。
- 監控：
- 查看特定快照狀態：
GET /_snapshot/my_backup_repo/my_snapshot_20230720。 - 查看詳細進度和統計信息：
GET /_snapshot/my_backup_repo/my_snapshot_20230720/_status。 - 查看所有正在運行的快照：
GET /_snapshot/_status。
- 查看特定快照狀態：
- 刪除：
DELETE /_snapshot/my_backup_repo/my_snapshot_20230720。- 重要： Elasticsearch 會清理 僅被該快照引用 的段文件。被其他快照共享的段文件不會被刪除。刪除是安全的操作。
3.3 恢復
- 基本恢復：
POST /_snapshot/my_backup_repo/my_snapshot_20230720/_restore?wait_for_completion=false {"indices": "index_1,index_2", // 可選，默認恢復快照中所有索引"ignore_unavailable": true,"include_global_state": false, // 強烈建議設置為 false！除非明確需要恢復集群級設置"include_aliases": false, // 可選，是否恢復索引別名"index_settings": { // 可選，覆蓋恢復索引的設置"index.number_of_replicas": 0 // 例如恢復時先不加副本加快速度},"ignore_index_settings": ["index.refresh_interval"] // 可選，忽略某些設置 } - 重命名索引 / 更改數據流：使用
rename_pattern和rename_replacement參數在恢復時重命名索引或更改數據流名稱。POST /_snapshot/my_backup_repo/my_snapshot_20230720/_restore {"indices": "logs-prod-*","rename_pattern": "logs-prod-(.+)","rename_replacement": "logs-test-$1" // 將 logs-prod- 前綴改為 logs-test- } - 選擇性恢復：可以只恢復特定索引，甚至使用
include_aliases和index_settings精細控制。 - 部分恢復：如果快照創建時允許
partial，即使有分片缺失也能恢復（數據不完整）。 - 監控恢復：
- 恢復 API 返回的
task_id可用于GET /_tasks/{task_id}。 - 索引恢復狀態：
GET /_recovery或GET /index_1/_recovery。 - 集群健康：
GET /_cluster/health關注initializing_shards和relocating_shards。
- 恢復 API 返回的
- 沖突處理：如果要恢復的索引在目標集群中 已存在且打開，恢復操作 默認會失敗。必須先關閉或刪除目標集群中的現有索引。
4.最佳實踐與注意事項
- 倉庫選擇：
- 生產環境：強烈推薦使用云對象存儲（
S3、GCS、Azure Blob）或高度可靠的共享文件系統。 避免使用本地路徑。 - 權限與安全：嚴格配置倉庫訪問權限（IAM 角色、存儲桶策略）。使用 Elasticsearch Keystore 存儲敏感憑證。
- 生命周期管理：在存儲系統層面配置策略，自動歸檔或刪除舊快照（Elasticsearch 本身不自動清理）。
- 生產環境：強烈推薦使用云對象存儲（
- 快照策略：
- 定期快照：使用
Elasticsearch SLM（Snapshot Lifecycle Management） 自動化創建、保留和刪除快照。定義策略（如每小時、每天、每周），保留策略（如保留最后 303030 天快照，每周保留一個快照持續 121212 個月）。 - 命名規范：使用清晰一致的命名（如
daily-20230720）。 - 測試恢復！定期進行恢復演練 是確保備份有效性的唯一方法。恢復到隔離環境驗證。
- 定期快照：使用
- 恢復策略：
include_global_state: false： 恢復生產快照到非生產環境時，幾乎總是將此設置為false！ 避免覆蓋目標集群的模板、ILM 策略等關鍵配置。- 副本設置：恢復時臨時設置
index.number_of_replicas: 0可以顯著加快恢復速度（數據只恢復一份）。恢復完成后，再調整副本數。 - 資源規劃 ：恢復是資源密集型操作（網絡 I/O、磁盤 I/O、CPU）。確保目標集群有足夠資源，避免影響線上業務。考慮在維護窗口進行。
- 版本兼容性：快照具有 向后兼容性：
- 你可以將
N.x的快照恢復到>= N.x的集群（例如7.17快照 →8.10集群）。 - 不能 將
N.x的快照恢復到< N.x的集群（例如8.10快照 →7.17集群）。需要先恢復到同版本或更高版本，再使用 Reindex API 或 Logstash 等工具向下遷移。
- 你可以將
- 監控與告警：
- 監控 SLM 作業執行狀態（成功/失敗）。
- 監控快照創建/恢復的持續時間、速度。
- 監控倉庫存儲空間使用情況。
- 設置告警規則（如快照連續失敗、倉庫空間不足）。
- 性能考量：
- 快照/恢復速度受限于 網絡帶寬（到倉庫）和 存儲 I/O 性能（源/目標集群磁盤、倉庫）。
- 大型集群的快照可能需要數小時。使用
wait_for_completion=false并異步監控。 - 調整
thread_pool（如snapshot、generic）大小需謹慎，評估對集群性能的影響。
5.總結
Elasticsearch 的快照與恢復是一個 強大、靈活且高效 的機制，是任何嚴肅的生產部署不可或缺的一部分。通過理解其增量備份原理、倉庫管理、SLM 自動化以及細致的恢復策略（特別是 include_global_state 的處理），Elasticsearch 工程師能夠構建可靠的數據保護、遷移和災難恢復方案。
🚀 切記：備份的價值只有在成功恢復時才能體現，因此定期的恢復演練至關重要。
并且推送至nexus私有依賴倉庫（筆記）)
)
