注冊前要注意配置文件加上
path.repo: ["/data/es_backup"]
然后重啟es
不然會報錯doesn't match any of the locations specified by path.repo because this setting is empty"
注冊一個倉庫，存放快照，記住，這里不是生成快照，只是注冊一個倉庫
curl -XPUT 'http://*.*.*.*:9200/_snapshot/my_backup' -H 'Content-Type: application/json' -d '{
"type": "fs",
"settings": {
"location": "/data/es_backup",
"compress": true
}
}'
查看倉庫信息：
curl -XGET 'http://*.*.*.*:9200/_snapshot/my_backup?pretty'
恢復快照：
創建全部快照,也可以根據索引創建快照
curl -XPUT '*.*.*.*:9200/_snapshot/my_backup/snapshot_20171020?wait_for_completion=true&pretty'
刪除快照
使用無論哪個存儲數據的軟件，定期備份你的數據都是很重要的。 Elasticsearch 副本提供了高可靠性；它們讓你可以容忍零星的節點丟失而不會中斷服務。
但是，副本並不提供對災難性故障的保護。對這種情況，你需要的是對集群真正的備份——在某些東西確實出問題的時候有一個完整的拷貝。
要備份你的集群，你可以使用 snapshot API。這個會拿到你集群里當前的狀態和數據然后保存到一個共享倉庫里。這個備份過程是"智能"的。你的第一個快照會是一個數據的完整拷貝，但是所有后續的快照會保留的是已存快照和新數據之間的差異。隨着你不時的對數據進行快照，備份也在增量的添加和刪除。這意味着后續備份會相當快速，因為它們只傳輸很小的數據量。
要使用這個功能，你必須首先創建一個保存數據的倉庫。有多個倉庫類型可以供你選擇：
- 共享文件系統，比如 NAS
- Amazon S3
- HDFS (Hadoop 分布式文件系統)
- Azure Cloud
創建倉庫編輯
|
|
給我們的倉庫取一個名字，在本例它叫 |
|
|
我們指定倉庫的類型應該是一個共享文件系統。 |
|
|
最后，我們提供一個已掛載的設備作為目的地址。 |
注意：共享文件系統路徑必須確保集群所有節點都可以訪問到。
這步會在掛載點創建倉庫和所需的元數據。還有一些其他的配置你可能想要配置的，這些取決於你的節點、網絡的性能狀況和倉庫位置：
-
max_snapshot_bytes_per_sec -
當快照數據進入倉庫時，這個參數控制這個過程的限流情況。默認是每秒
20mb。 -
max_restore_bytes_per_sec - 當從倉庫恢復數據時，這個參數控制什么時候恢復過程會被限流以保障你的網絡不會被占滿。默認是每秒 `20mb`。
假設我們有一個非常快的網絡，而且對額外的流量也很 OK，那我們可以增加這些默認值：
POST _snapshot/my_backup/
{
"type": "fs",
"settings": {
"location": "/mount/backups/my_backup",
"max_snapshot_bytes_per_sec" : "50mb",
"max_restore_bytes_per_sec" : "50mb"
}
}
|
|
注意我們用的是 |
|
|
然后添加我們的新設置。 |
快照所有打開的索引編輯
一個倉庫可以包含多個快照。 每個快照跟一系列索引相關（比如所有索引，一部分索引，或者單個索引）。當創建快照的時候，你指定你感興趣的索引然后給快照取一個唯一的名字。
讓我們從最基礎的快照命令開始：
PUT _snapshot/my_backup/snapshot_1
這個會備份所有打開的索引到 my_backup 倉庫下一個命名為 snapshot_1 的快照里。這個調用會立刻返回，然后快照會在后台運行。
通常你會希望你的快照作為后台進程運行，不過有時候你會希望在你的腳本中一直等待到完成。這可以通過添加一個 wait_for_completion 標記實現：
PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true
這個會阻塞調用直到快照完成。注意大型快照會花很長時間才返回。
快照指定索引編輯
默認行為是備份所有打開的索引。 不過如果你在用 Marvel，你不是真的想要把所有診斷相關的 .marvel索引也備份起來。可能你就壓根沒那么大空間備份所有數據。
這種情況下，你可以在快照你的集群的時候指定備份哪些索引：
PUT _snapshot/my_backup/snapshot_2
{
"indices": "index_1,index_2"
}
這個快照命令現在只會備份 index1 和 index2 了。
列出快照相關的信息編輯
一旦你開始在你的倉庫里積攢起快照了，你可能就慢慢忘記里面各自的細節了 ——特別是快照按照時間划分命名的時候（比如， backup_2014_10_28 ）。
要獲得單個快照的信息，直接對倉庫和快照名發起一個 GET 請求：
GET _snapshot/my_backup/snapshot_2
這個會返回一個小響應，包括快照相關的各種信息：
{
"snapshots": [
{
"snapshot": "snapshot_1",
"indices": [
".marvel_2014_28_10",
"index1",
"index2"
],
"state": "SUCCESS",
"start_time": "2014-09-02T13:01:43.115Z",
"start_time_in_millis": 1409662903115,
"end_time": "2014-09-02T13:01:43.439Z",
"end_time_in_millis": 1409662903439,
"duration_in_millis": 324,
"failures": [],
"shards": {
"total": 10,
"failed": 0,
"successful": 10
}
}
]
}
要獲取一個倉庫中所有快照的完整列表，使用 _all 占位符替換掉具體的快照名稱：
GET _snapshot/my_backup/_all
刪除快照編輯
最后，我們需要一個命令來刪除所有不再有用的舊快照 。這只要對倉庫/快照名稱發一個簡單的 DELETEHTTP 調用：
DELETE _snapshot/my_backup/snapshot_2
用 API 刪除快照很重要，而不能用其他機制（比如手動刪除，或者用 S3 上的自動清除工具）。因為快照是增量的，有可能很多快照依賴於過去的段。delete API 知道哪些數據還在被更多近期快照使用，然后會只刪除不再被使用的段。
但是，如果你做了一次人工文件刪除，你將會面臨備份嚴重損壞的風險，因為你在刪除的是可能還在使用中的數據。
監控快照進度編輯
wait_for_completion 標記提供了一個監控的基礎形式，但哪怕只是對一個中等規模的集群做快照恢復的時候，它都真的不夠用。
另外兩個 API 會給你有關快照狀態更詳細的信息。首先你可以給快照 ID 執行一個 `GET`，就像我們之前獲取一個特定快照的信息時做的那樣：
GET _snapshot/my_backup/snapshot_3
如果你調用這個命令的時候快照還在進行中，你會看到它什么時候開始，運行了多久等等信息。不過要注意，這個 API 用的是快照機制相同的線程池。如果你在快照非常大的分片，狀態更新的間隔會很大，因為 API 在競爭相同的線程池資源。
更好的方案是拽取 _status API 數據：
GET _snapshot/my_backup/snapshot_3/_status
_status API 立刻返回，然后給出詳細的多的統計值輸出：
{
"snapshots": [
{
"snapshot": "snapshot_3",
"repository": "my_backup",
"state": "IN_PROGRESS",
"shards_stats": {
"initializing": 0,
"started": 1,
"finalizing": 0,
"done": 4,
"failed": 0,
"total": 5
},
"stats": {
"number_of_files": 5,
"processed_files": 5,
"total_size_in_bytes": 1792,
"processed_size_in_bytes": 1792,
"start_time_in_millis": 1409663054859,
"time_in_millis": 64
},
"indices": {
"index_3": {
"shards_stats": {
"initializing": 0,
"started": 0,
"finalizing": 0,
"done": 5,
"failed": 0,
"total": 5
},
"stats": {
"number_of_files": 5,
"processed_files": 5,
"total_size_in_bytes": 1792,
"processed_size_in_bytes": 1792,
"start_time_in_millis": 1409663054859,
"time_in_millis": 64
},
"shards": {
"0": {
"stage": "DONE",
"stats": {
"number_of_files": 1,
"processed_files": 1,
"total_size_in_bytes": 514,
"processed_size_in_bytes": 514,
"start_time_in_millis": 1409663054862,
"time_in_millis": 22
}
},
...
|
|
一個正在運行的快照會顯示 |
|
|
這個特定快照有一個分片還在傳輸（另外四個已經完成）。 |
響應包括快照的總體狀況，但也包括下鑽到每個索引和每個分片的統計值。這個給你展示了有關快照進展的非常詳細的視圖。分片可以在不同的完成狀態：
-
INITIALIZING - 分片在檢查集群狀態看看自己是否可以被快照。這個一般是非常快的。
-
STARTED - 數據正在被傳輸到倉庫。
-
FINALIZING - 數據傳輸完成；分片現在在發送快照元數據。
-
DONE - 快照完成！
-
FAILED - 快照處理的時候碰到了錯誤，這個分片/索引/快照不可能完成了。檢查你的日志獲取更多信息。
取消一個快照編輯
最后，你可能想取消一個快照或恢復。 因為它們是長期運行的進程，執行操作的時候一個筆誤或者過錯就會花很長時間來解決——而且同時還會耗盡有價值的資源。
要取消一個快照，在他進行中的時候簡單的刪除快照就可以：
DELETE _snapshot/my_backup/snapshot_3
這個會中斷快照進程。然后刪除倉庫里進行到一半的快照。
參考鏈接：https://www.elastic.co/guide/en/elasticsearch/reference/5.5/modules-snapshots.html
https://www.elastic.co/guide/cn/elasticsearch/guide/current/backing-up-your-cluster.html