Elastic Cloud 快照備份與管理: 實作資料高效恢復與 SLM 自動化管理之技術 | 前端三分鐘

文章目錄

1. 什麼是 Elastic Cloud 快照 (Snapshots)？
2. Elastic Cloud Snapshots
1. 2.1. 建立快照與恢復
2. 2.2. SLM (snapshot lifecycle management)
3. FAQ：Elastic Cloud 快照與備份常見問題

什麼是 Elastic Cloud 快照 (Snapshots)？

Elastic Cloud 快照 (Snapshots) 是 Elasticsearch 叢集中資料備份與恢復的核心機制。其核心定義在於擷取叢集在特定時間點的狀態與數據，並將其存儲於外部的 Repositories（如 AWS S3, Google Cloud Storage 或 Azure Blob Storage）中。快照採用增量備份技術，僅存儲自上次快照以來更改的數據，因此具有高效且低成本的優勢。透過 SLM (Snapshot Lifecycle Management)，管理員可以自動化執行備份任務與保留原則，確保在面對資料誤刪、硬體故障或災難復原場景時，能以最快速度完成資料恢復，保障業務連續性。

在雲端時代，資料的安全性與可用性是企業營運的基石。特別是對於儲存大量關鍵數據的 Elasticsearch 叢集而言，高效可靠的資料備份與資料恢復機制至關重要。

Elastic Cloud 快照功能結合強大的 SLM (Snapshot Lifecycle Management) 策略，提供了自動化、細粒度的快照管理能力，不僅有效簡化了資料保護的複雜度，搭配對應的 plugins 將快照資料備份到不同的雲端儲存服務，確保您的資料安全與業務連續性。

Elastic Cloud Snapshots

為什麼備份跟快照很重要? 這是Elastic Cloud 快照的核心功能。

快照可以在不影響系統運行的狀況下做快速且低成本的資料備份
遇到病毒感染或錯誤可以用最快的速度恢復系統運行，通常做快照跟備份的位置會是不同的機台與服務，所以當主要的虛擬機被打掛了，快照跟備份還會活得好好的

Elastic Snapshots 可以做什麼? 為了更清晰地了解 Elastic Cloud 快照的核心功能與其在資料備份和資料恢復中的重要性，請參考以下問答圖解。

在啟用 Elastic Cloud 服務後，會預設幫我們啟動快照的功能，快照預設自動每 30 分鐘做一次且會透過 Repositories 進行存放。

Repositories 可以是本機或是任何遠端有提供支援 plugins 的雲端服務像是 Amazon S3、HDFS、Microsoft Azure、Google Cloud Storage 等等。目前 7.6 版以上就可以透過 kibana 的 GUI 進行快照跟恢復的動作了，可以說是非常方便。

建立快照與恢復

首先第一個步驟就是要註冊 Repository，Stack Management > Data > Snapshot and Restore 點選 Repositories 的 Tab 就可以進行建立，當然也可以透過 API 的方式進行，這個部分可以參考相關文件，目前 Elastic Cloud 試用帳號只支援 AWS S3 跟 GCP，這個帳號目前是建立在 GCP 上。這是Elastic Cloud 快照的實踐。

建立 Repository

Kibana 的介面中

也有提供支援 S3，要使用其他平台應該就要裝額外的 plug-in，這個部分目前沒有去嘗試

Elastic Cloud Enterprise 的介面也是類似

建立快照並設定相關週期，透過 GUI 其實蠻方便的，就是下一步下一步。

建立的過程中可以設定像是要多久快照一次快照保存多久

設定完成後也可以在 Policy 的 Tab 進行管理

Snapshots 可以看到系統自動製作的快照列表

從快照恢復資料，從快照恢復也很方便就是點選然後按恢復就完成，這是資料恢復的關鍵一步，也同樣能透過 API 進行操作。

從 Elastic Cloud 快照恢復資料

SLM (snapshot lifecycle management)

這篇文章示範的 UI 背後其實是一套叫做 SLM (snapshot lifecycle management) 的管理機制，會自動依照設定的 SLM policy 做資料備份跟老舊快照的移除，也提供相關 API 提供管理，更詳細的資訊可以參考SLM 相關文件，底下附上 API 的範例，看完之後建議直接使用 Kibana 的介面，畢竟 Kibana 已經做好 API 的串接。

curl -X PUT "localhost:9200/_slm/policy/nightly-snapshots?pretty" -H 'Content-Type: application/json' -d'
{
  "schedule": "0 30 1 * * ?",
  "name": "<nightly-snap-{now/d}>",
  "repository": "my_repository",
  "config": {
    "indices": ["*"]
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

FAQ：Elastic Cloud 快照與備份常見問題

Q1：快照備份會影響 Elasticsearch 的查詢效能嗎？

A：快照操作對系統效能的影響微乎其微。由於 Elastic Cloud 快照 是在不中斷服務的情況下於背景執行的，且採用增量備份機制，因此不會鎖定索引或顯著增加 CPU 負荷。不過，在執行大規模初次備份時，建議在離峰時間進行，以確保網路頻寬不被佔用。

Q2：快照與傳統的磁碟鏡像備份有什麼不同？

A：快照是「應用程式層級」的備份，它理解 Elasticsearch 的數據分片（Shards）與索引結構。傳統的磁碟鏡像（Disk Image）在恢復時可能因數據不一致而導致叢集無法啟動。Elastic Cloud 快照 則能保證數據的一致性，並支持「細粒度恢復」，允許您只恢復特定的索引而非整個叢集。