type
status
date
slug
summary
tags
category
icon
password

snapshot repository

snapshot repository 是儲存 snapshot 的位置，在 snapshot 之前必須先建立一個 repository。

需知

如果要透過 kibana 操作 snapshot and restore 功能，必須具有以下權限：
  • Cluster privileges：monitor, manage_slm, cluster:admin/snapshot, and cluster:admin/repository
  • index privilege：all on the monitor index
其他事項：
  • 每個 repository 都是獨立的，不同的 repository 不會共享數據。
  • 如果多個 cluster 同時註冊同一個 repository，需要只允許一個 cluster 能夠寫入 repository，其他 cluster 只允許讀取 repository，避免 repository 被不同 cluster 同時寫入導致損壞。
  • 對每個 Elasticsearch 使用對應其主要版本的 repository，避免混合不同版本導致損壞。

設定備份路徑

在 elasticsearch.yml 中設定備份檔路徑並重啟

使用 API 註冊 snapshot repository

  • shared file system repository
      • 💡
      如果在 location 設定相對路徑，則會以設定檔中的第一個 repo 路徑解析。 例如：將 location 設為 my_fs_backup_location，本例中設定檔的第一個 repo 路徑是 /mount/backups，因此會被解析為 /mount/backups/my_fs_backup_location。
      如果將同一個 snapshot repository 註冊到多個 cluster，則只能有一個 cluster 能進行寫入，其餘 cluster 只能進行讀取，要設為 read-only 需要在 settings 中間添加 "readonly": true 屬性。
  • Read-only url repository
      • 如果要設定 cluster 只能讀取 repository，除了在 type:fs 添加 readonly 屬性，還可以使用 Read-only url 的方式，因為 URL repository 總會是唯讀的，因此此方式更安全。
  • source-only repository

使用 Kibana 操作

在 Stack Management > Snapshot and Restore > Repository 中可以操作註冊 repository。
notion image
notion image

驗證 repository

清理 repository

隨著時間推移 repository 可能會累積現有 snapshot 未引用的數據，這是因為 snapshot 期間故障安全考量的結果，這些未引用的數據雖然不會造成安全性問題，但卻會浪費儲存空間，以下 API 可以清理 repository 中未引用的數據。
如果有定期刪除 snapshot 則無需使用此功能。

備份 repository

你可能希望對當前 repository 做一個單獨的備份，以便以後使用當前狀態重新創建 repository。
首先必須先從所有的 cluster 取消註冊該 repository 或者是使用 readonly:true 來註冊，確保備份時沒有內容寫入 repository。

Create a snapshot

需知
如果要透過 kibana 操作 snapshot and restore 功能，必須具有以下權限：
  • Cluster privileges：monitor, manage_slm, cluster:admin/snapshot, and cluster:admin/repository
  • index privilege：all on the monitor index
其他事項
  • cluster 必須已經註冊 snapshot repository
  • 每個 snapshot 在其 repository 中必須具有唯一的名稱。
  • snapshot 會自動去重，因此頻繁的 snapshot 不會對儲存的開銷影響很大。
  • 每個 snapshot 是獨立的，刪除 snapshot 並不影響其他 snapshot。
  • snapshot 過程中可能會暫時停止 shard 分配
  • snapshot 不會阻止 index 或其他請求，但 snapshot 不會包含開始 snapshot 程序後的變更。
  • 可以同時執行多個 snapshot 操作，可以透過 snapshot.max_concurrent_operations 限制最大並發的 snapshot 操作。

使用 SLM 自動執行 snapshot

定期備份 cluster 最簡單的方法就是使用 snapshot lifecycle management (SLM)，SLM 按照制定的計畫自動 snapshot，並且還能自定義刪除 snapshot 的規則。

權限設置

和 SLM 相關的權限如下：
  • manage_slm－允許使用者執行 SLM 操作，例除：創建和更新策略、啟動和停止 SLM。
  • read_slm－允許使用者讀取 SLM 操作，例如：獲取策略、檢查 SLM 狀態。
  • cluster:admin/snapshot/*－允許使用者拍攝或刪除任何 index 的 snapshot。
以下指令建立了一個 slm-admin 的角色，允許管理 slm 策略和執行 snapshot：
以下指令建立了一個 slm-read-only 的角色：
 

創建 SLM 策略

使用 Kibana 操作時，可以到 Stack Management > Snapshot and Restore > Policies 操作。
notion image
或者是也可以透過 SLM API 操作，以下事例為每天 UTC 1:30 進行 snapshot：
  • schedule
  • name
  • repository
  • config
  • retention

手動運行 SLM 策略

可以手動運行 SLM 策略立刻建立 snapshot，手動運行策略並不會影響到正常的排程。
notion image
或是透過以下 API 運行

SLM retention

SLM snapshot retention 和 SLM 拍攝 snapshot 的排程時間並不相同，可以透過以下方式設定 retention 的執行時間或是手動觸發執行
雖然 repository 可以有數千個 snapshot，可是為了管理 snapshot 的 metadata 在 master 節點需要佔用更多的內存，因此需要設定適合的 retention 規則，避免影響 master 節點的穩定性。

檢查 SLM 紀錄

SLM 策略成功運行並不能保證 snapshot 完成，可以透過以下 API 檢查 SLM 策略執行狀況。

手動創建 snapshot

可以透過 Create snapshot API 自行創建 snapshot。

監控 snapshot

刪除 snapshot

刪除 snapshot 並不會刪除其他 snapshot 使用的文件，若要刪除 snapshot 可以在 Kibana 上執行此動作：
notion image
此外也可以透過 Delete snapshot API 刪除：

其他建議

備份 feature states

feature states 指的是儲存在 Elasticsearch 中用於 Elastic 功能的資料，包含了配置和歷史紀錄......等，例如：Elasticsearch 安全性、Kibana設定。可以透過以下 api 確認所有的 feature states：
預設情況下 snapshot 會包括所有的 feature states
例如：以下 SLM 策略在 snapshot 中僅包含 Kibana、Elasticsearch 安全功能設定
不過部分 feature states 包含了敏感資訊，例如 security 就包含了 user 和 password 的資訊，因此建議可以為這些 feature states 額外使用獨立的 repository 和 SML 策略，能夠更嚴謹的控管這些敏感資訊。
例如：以下 SLM 策略只備份了 feature states－
  • include_global_state：true，表示包含所有的 feature states。
  • indices：-*，表示不包括所有的索引和數據流。
例如：以下 SLM 策略備份了 feature states 以外的索引－
  • include_global_state：false，表示排除所有 feature states。
  • indices：其中 * 表示所有索引和數據流，其中 -.* 表示不包括所有 . 開頭的索引。

配置不同時間間隔的 snapshot

如果只配置單個 SLM 策略，可能無法滿足頻繁拍攝 snapshot 和長時間保留的 snapshot 需求。
例如：每 30 分鐘執行 snapshot 且最多保留 100 個 snapshot 的 SLM 策略，雖然可以用於還原近期的資料，但因為最多保存 2 天的 snapshot，因此無法用於還原至上一周的數據。
SLM retention 不會刪除由其他 SLM 規則創建的 snapshot，因此建議配置多個 SLM 策略用來滿足多個用途。

restore

取得可用的 snapshot 清單

從 Kibana 中的 Stack Management > Snapshot and Restore 可以看到可用的 snapshot 清單，或是可以使用以下 API 取得。

還原到其他 Cluster

因為 snapshot 並不綁定 cluster，所以是可以將 snapshot 還原到另一個版本相容的 Cluster 中。
需要將新的 cluster 也註冊欲還原的 repository，如果原始的 cluster 仍然對 repository 有寫入權限，則新的 cluster 需註冊為 read-only，避免多個 cluster 寫入 repository。

還原到現有的 Cluster

如果要將數據還原到已經存在的 cluaster，可能會和現有的 index 產生衝突，可以使用以下方式避免衝突

刪除後還原

這是最簡單避免還原衝突，並且建議暫停活動中的 index，避免意外又重新創建衝突的索引
⚠️
注意：在使用通配符匹配的時候，請不要使用 * 來刪除，因為這將刪除包含系統索引，請使用 *,-.* 避免刪除 . 開頭的系統索引。

還原時重新命名

以下範例的還原 API 會在還原的 index 前方加上 restored-：
如果要將還原後的 index 替換掉原本的 index 可以使用以下方式：

排除系統索引

使用以下方式還原所有 index，除了以 . 為開頭的系統索引不還原

還原 feature status

透過以下方式在 feature_states 中指定要還原的 feature status

原地還原整個 Cluster

  1. 暫時停止索引並關閉以下功能
    1. 如果有啟用權限控管功能，需要先建立一組 superuser 的權限，用於還原完畢前進行操作
      1. 調整 cluster 設定，將 action.destructive_requires_name 調整為 false，以便我們透過通佩符直接刪除 indices 和 data streams
        1. 刪除現有的 data streams 和 indices
          1. 還原整個 snapshot
            1. 還原完畢後就可以繼續索引並開啟被關閉的功能

              監控還原

              當還原操作恢復 primary shard 後，cluster 的健康度會是 yellow。直到將 replica shard 都恢復完成後才會是 green。
              當透過 Kibana 開始還原後，可以到 Restore Status 頁面追蹤還原進度，此外也可以透過以下 API

              取消還原

              透過刪除 index 或 data stream 可以取消正在還原的數據

              參考

              Snapshot and restore | Elasticsearch Guide [7.16] | Elastic
              Elasticsearch 快照仓库的内部结构 - Mincong Huang