Snapshot Lifecycle Management (SLM)

前言

這個系列的文章前面主要介紹的都是如何優化 Index 的儲存空間、執行效率…等各種優化，最後這一部份是資料的備份，雖然 Elasticsearch Cluster 可以有許多的 Nodes, 也能設置多份的 Replica 來確保資料的可靠性，但是定期的資料備份還是不能少的，能有效在發生災難時能救回資料，例如：微軟 6.5T 的 Elasticsearch 料被駭客刪了這樣的事件。

進入此章節的先備知識

Elasticsearch Index 的相關基本知識。
若備份在雲端儲存空間的話 (例如 AWS S3)，會要知道這些雲端儲存空間的基本知識。

此章節的重點學習

Snapshot / Restore 的使用方式。
如何在 Kibana 建立 Snapshot Policy，以及使用 AWS S3 Repository。

Snapshot

Snapshot 是 Elasticsearch 用來備份的方式，這邊要注意一件事，如果你打算備份 Elasticsearch 的資料，千萬不要自己從磁碟區去備份 Elasticsearch 的 data 資料夾內的資料，因為有很大的機率當你要復原時，Elasticsearch 在啟動的檢查中會告訴你資料是毀損的，因此在 Elasticsearch 要備份資料，請使用 Snapshot。

Repository

使用 Snapshot 的時候，第一個要先決定你備份的資料要存哪邊，所以要先產生 Repository。

Repository 主要支援的類型有下面幾種：

fs: shared file system，要使用 file system 來建立 Repository 的話，要先在 elasticsearch.yml 設定檔中指定好 path.repo 的路徑。
repository-s3: 以 AWS S3 來當 Repository, 要另外安裝官方的 Plugin。
repository-hdfs: 以 Hadoop HDFS 來當 Repository, 要另外安裝官方的 Plugin。
repository-gcs: 以 Google Cloud Storage 來當 Repository, 要另外安裝官方的 Plugin。
repository-azure: 以 Azure 來當 Repository, 要另外安裝官方的 Plugin。
repository-swift: 這是 OpenStack Swift 的 Repository 擴充套件，是社群開發、非官方的，也是要另外安裝。

在 Elastic Cloud 中增加其他 Azure 和 GCP 的 Repository 支援

若是在 Elastic Cloud 中要使用其他的 Repository 時，要先到 Deployement 中去安裝 Plugins。

在 Elasticsearch plugins, extensions, and settings 的區塊展開後，就可以看到 repository 的 plugins 可以選擇。

建立 Repository

安裝好之後，在 Kibana > Stack Management 裡 Data 區塊的 Snapshot and Restore 就可以 Register a repository。

這就就可以看到 Azure, GCS, AWS S3 的支援了。

這邊以 AWS S3 為例，先在自己的 AWS S3 上建立一個 bucket，然後設定好 IAM 權限：

{
  "Statement": [
    {
      "Action": [
        "s3:*"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::bucket-name",
        "arn:aws:s3:::bucket-name/*"
      ]
    }
  ]
}