背景

雖然 Elasticsearch 有良好的容災性，但是在以下情況還是需要備份機制：

• 資料災備：在叢集出錯時，可以及時從備份中恢復資料。
• 歸檔資料：有些不斷增加的資料暫時不用，但是以備後期檢視而不想刪除，則可以將這些資料進行備份歸檔。
• 遷移資料：將資料從一個叢集遷移到另一個叢集時，也可以用備份的方式來實現。Elasticsearch 做備份有兩種方式，一是將資料匯出成文字檔案，比如通過 elasticdump 、 esm 等工具將儲存在 Elasticsearch 中的資料匯出到檔案中。二是以備份 Elasticsearch data 目錄中檔案的形式來做快照，也就是 Elasticsearch 中 snapshot 介面實現的功能。第一種方式相對簡單，在資料量小的時候比較實用，當應對大資料量場景效率就大打折扣。接下來講到的就是 snapshot api 的使用。

備份到哪裡

在 Elasticsearch 中通過 repository 定義備份儲存型別和位置，儲存型別有共享檔案系統、AWS 的 S3儲存、HDFS 的儲存等。

不管是哪種，你都要在 elasticsearch.yml 的配置檔案中註明可以用作備份路徑 path.repo：

path.repo: /usr/local/elasticsearch-7.3.0/data/backup
複製程式碼

配置好後，就可以使用 snapshot api 來建立一個 repository 了，如下我們建立一個名為 es_backup 的 repository。

PUT /_snapshot/es_backup
{
  "type": "fs","settings": {
    "location": "/usr/local/elasticsearch-7.3.0/data/backup"
  }
}
複製程式碼
 

建立成功之後就可以在這個 repository 中備份資料了。

如何備份

備份也叫快照，也就是記錄當下索引資料的狀態，如下建立一個名叫 snapshot_0910 的快照：

PUT /_snapshot/es_backup/snapshot_0910
複製程式碼

wait_for_completion 為 true 是指該 api 在備份執行完畢後再返回結果，否則預設是非同步執行的，我們這裡為了立刻看到效果，所以設定了該引數，線上執行時不用設定該引數，讓其在後臺非同步執行即可。

通過以下命令檢視快照執行狀態：

GET _snapshot/es_backup/snapshot_0910
複製程式碼

結果如下：

{
  "snapshots" : [
    {
      "snapshot" : "snapshot_0910","uuid" : "1rkfrgJsQMSWmVT0WePQ-Q","version_id" : 7030099,"version" : "7.3.0","indices" : [
        "blogs","address_xc","pattern","student","student2","kibana_sample_data_flights",".kibana_task_manager","p_sc",".kibana_1","my_index"
      ],"include_global_state" : true,"state" : "SUCCESS","start_time" : "2019-09-10T09:14:11.455Z","start_time_in_millis" : 1568106851455,"end_time" : "2019-09-10T09:15:17.168Z","end_time_in_millis" : 1568106917168,"duration_in_millis" : 65713,"failures" : [ ],"shards" : {
        "total" : 10,"failed" : 0,"successful" : 10
      }
    }
  ]
}
複製程式碼
 

何時備份

通過上面的步驟我們成功建立了一個備份，但隨著資料的新增，我們需要對新增的資料也做備份，那麼我們如何做呢？方法很簡單，只要再建立一個快照 snapshot_new 就可以了。

PUT /_snapshot/es_backup/snapshot_new?wait_for_completion=true
複製程式碼

當執行完畢後，es_backup 目錄體積變大了，這說明新資料備份進來了。如果在同一個 repository 中做多次 snapshot 時，Elasticsearch 會檢查要備份的資料 segment 檔案是否有變化，如果沒有變化則不處理，否則只會把發生變化的 segment file 備份下來。這其實就實現了增量備份。

Elasticsearch 的資深使用者應該瞭解 force merge 功能，即可以強行將一個索引的 segment file 合併成指定數目，這裡要注意的是如果你主動呼叫 force merge api，那麼 snapshot 功能的增量備份功能就失效了，因為 api 呼叫完畢後，資料目錄中的所有 segment file 都發生變化了。

另一個就是備份時機的問題，雖然 snapshot 不會佔用太多的 cpu、磁碟和網路資源，但還是建議大家儘量在閒時做備份。

如何恢復

通過下面的 api，我們可以將 index_1 索引恢復到 restored_index_1 中。這個恢復過程完全是基於檔案的，因此效率會比較高。

POST /_snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true
{
  "indices": "index_1","rename_replacement": "restored_index_1"
}
複製程式碼

其他

由於 Elasticsearch 版本更新比較快，因此大家在做備份與恢復的時候，要注意版本問題，同一個大版本之間的備份與恢復是沒有問題的，比如都是 5.1 和 5.6 之間可以互相備份恢復。但你不能把一個高版本的備份在低版本恢復，比如將 6.x 的備份在 5.x 中恢復。而低版本備份在高版本恢復有一定要求：

• 5.x 可以在 6.x 恢復

• 2.x 可以在 5.x 恢復

• 1.x 可以在 2.x 恢復

參考

如果需要詳細瞭解，可以去官網：www.elastic.co/guide/en/el…