基本概念
使用 Elasticsearch Snapshot 時需要有一些基本概念澄清，他不是拿指定的 Indices 文件做個壓縮包丟在 S3 完事，他是有控制的。
snapshot 結構
Elasticsearch 的 snapshot 是由其自身控制的，整個系統保持了一個如下的從下到上的控制結構，他們具備包含關係：
snapshot --> repository --> single snapshot --> indices
snapshot
這裏將 snapshot 單獨列出，是因爲在 Elasticsearch 中 snapshot 獨佔性工作的，他更像是一個管道，任何一個 repository 在工作的時候是排他的，雖然他並不阻止 indices 的寫入。
repository
這個倉庫應該是一組 snapshot 備份的集合，也可以認爲是一個目標的選擇。在一個 Elasticsearch 系統中你可以根據自己的意願設定不同的 Repository。
Single snapshot
這個指的是在 Repository 中我們進行的每個備份內容，他更像一個集合，包含了這次 snapshot 中所有的 Indices。
Indices
在一個 snapshot 當中，可以包含多個 Indices 文件內容。他可以在執行 snapshot 的時候用 pattern 識別，也可以一個一個的指定。
S3 插件
如果要想讓 Elasticsearch 備份到 S3 當中需要單獨安裝一個插件 S3 Repository Plugin。
Repository
在正常執行 _snapshot 以前，需要先建立好自己的 Repository。具體操作可以參考 S3 Repository Plugin 完成 S3 的配置操作。
其中 AWS 的賬戶口令控制不必非要寫在系統的 YAML 配置文件中，直接在創建 Repository 的設定用起來會更加靈活。獲取 Repository 的時候，系統會自動屏蔽賬戶信息部分。
AWS IAM
這個稍微複雜一點，也可能是我們對 AWS IAM 並不熟悉。按照 Elastic 官方給出的 Recommanded S3 Permissions 直接配置即可。
Recommanded S3 Permissions:
https://www.elastic.co/guide/en/elasticsearch/plugins/current/repository-s3-repository.html#repository-s3-permissions
這裏他需要獲取到 AWS S3 Bucket 的列表權限，因爲他會放置自己的一些控制文件進入，並且還需要進行比對操作。
如果你需要備份不同的 ES 系統到一個 AWS S3 Bucket 一定要分配到不同的目錄當中，因爲 Elasticsearch 的那些控制文件會導致他們之間衝突。這裏可以參考這個 S3 Permissions 的說明中後面一個 IAM 配置說明即可。
snapshot 操作
當 Repository 做好後，就可以直接執行 _snapshot 操作了。具體的操作方法可以參考 Snapshot and Restore 部分的說明了。指令比 _search 不知道簡單多少倍.
如果你執行的時候，其他的 snapshot 正在執行，你會得到一個 503: Service Unavailable 的錯誤信息。這就是上面說的 snapshot 執行的獨佔性，哪怕不同的 repository 之間也不能並行。
S3 中文件的作用
Elasticsearch 在 S3 中創建 snapshot 的時候，會形成一些輔助文件，幫他管理 snapshot 內容。
最坑爹是 Elasticsearch 並不在自己的 Indices 當中創建備份信息，而是將所有這些信息都放在了 S3 當中。當然熟悉後也明白，這麼做的好處是，可以讓另一個 ES 系統通過同樣的 Repository 配置讀取這些 S3 中的內容。
備份配置步驟
需要安裝的插件 （推薦每臺es節點都安裝，並重啓服務）
/opt/elasticsearch/bin/elasticsearch-plugin install repository-s3
配置訪問S3賬號與密碼
#ACCESS-KEY
/opt/elasticsearch/bin/elasticsearch-keystore add s3.client.default.access_key
AKIAJLFDDDDDDDDDDDDD
#SECRET-KEY
/opt/elasticsearch/bin/elasticsearch-keystore add s3.client.default.secret_key
nHr5vFTxCBI6CbRgNGDAAAAAAAAAA
刪除key 信息：
/opt/elasticsearch/bin/elasticsearch-keystore remove s3.client.default.access_key
/opt/elasticsearch/bin/elasticsearch-keystore remove s3.client.default.secret_key
Amazon S3存儲庫實例如下：
curl -XPUT 'http://localhost:9200/_snapshot/backup' -H 'Content-Type: application/json' -d '{ "type": "s3", "settings": { "bucket": "pte-es-backup", } }'
參數名詞解釋：
Type: 倉庫類型
Setting: 倉庫的額外信息
Bucket: 存儲桶名稱
不同的ES版本支持的region參考：
Region: AWS Region
Access_key: 訪問祕鑰
Secret_key: 私有訪問祕鑰
使用上面的命令，創建一個倉庫（s3-backup），並且還創建了存儲桶（esbackup）,返回{"acknowledged":true} 信息證明創建成功。
確認備份倉庫是否創建成功：
curl -XPOST http://localhost:9200/_snapshot/backup/_verify?pretty
{
"nodes" : {
"Uz61yrDjRXy-otyYiwLXtA" : {
"name" : "172.17.5.152"
},
"JgrZMa9CTRuoV1cezEeXuQ" : {
"name" : "172.17.5.153"
},
"z_BLa4u1SZWt5gA4oZRpOA" : {
"name" : "172.17.5.196"
}
}
}
查看剛創建的存儲倉庫：
curl -XGET localhost:9200/_snapshot/backup?pretty
查看所有的存儲桶：
curl -XGET localhost:9200/_snapshot/_all?pretty
備份索引
創建好存儲倉庫之後就可以開始備份了。一個倉庫可以包含多個快照（snapshots），快照可以存所有的索引或者部分索引，當然也可以存儲一個單獨的索引。(要注意的一點就是快照只會備份open狀態的索引，close狀態的不會備份)
備份所有索引
curl -XPUT http://127.0.0.1:9200/_snapshot/backup/snapshot_all
上面的代碼會將所有正在運行的open狀態的索引，備份到backup倉庫下一個叫snapshot_all的快照中。上面的api會立刻返回{"accepted":true}，然後備份工作在後臺運行。
如果你想api同步執行，可以加wait_for_completion 標誌：
curl -XPUT http://127.0.0.1:9200/_snapshot/backup/snapshot_all?wait_for_completion=true
上面的方法會在備份完全完成後才返回，如果快照數據量大的話，會花很長時間。
備份部分索引
默認是備份所有open狀態的索引，如果你想只備份某些或者某個索引，可以指定indices參數來完成
curl -XPUT 'http://localhost:9200/_snapshot/backup/index-kjh-201712' -H 'Content-Type: application/json' -d '{ "indices": "index-kjh-2017.12" }'
備份多索引方法：
{
"indices": "products,index_1,index_2",
"ignore_unavailable": true,
"include_global_state": false
}
indices: 需要備份的索引
ignore_unavailable: 如果索引不存在，則略過。
include_global_state: 爲了讓同一個snapshot可以恢復到多個不同的cluster，這裏設置成false。之所以是false，是因爲我們不想把global cluster state備份進snapshot
查看快照信息
curl -XGET 'http://localhost:9200/_snapshot/backup/_all'?pretty
curl -XGET 'http://localhost:9200/_snapshot/backup/index-kjh-201712?'pretty
查看快照信息，只需要發起GET請求就好：
詳細信息：
{
"snapshot" : "index-kjh-201712",
"uuid" : "mQPVTiYlR_Wc2ftR7OIrZw",
"version_id" : 6010099,
"version" : "6.1.0",
"indices" : [
"index-kjh-2017.12"
],
"state" : "SUCCESS", <============總體狀況
"start_time" : "2018-01-04T11:15:04.974Z",
"start_time_in_millis" : 1515064504974,
"end_time" : "2018-01-04T11:15:07.658Z",
"end_time_in_millis" : 1515064507658,
"duration_in_millis" : 2684,
"failures" : [ ],
"shards" : {
"total" : 5,
"failed" : 0,
"successful" : 5
}
}
]
}
快照總體狀況：
上面信息深入每和每個實例統計數據。這給你一個令人難以置信的詳細視圖快照是如何進展的。碎片可以以不同的方式完成:
INITIALIZING： 集羣的碎片是檢查狀態是否可以快照。這通常是非常快。
STARTED：數據被轉移到存儲庫。
FINALIZING：數據傳輸完成;碎片現在發送快照的元數據。
DONE：快照完成。
FAILED：在快照過程中錯誤的出處,這碎片/索引/快照無法完成。檢查你的日誌以獲取更多信息。
恢復索引數據：
curl -XPOST 'http://localhost:9200/_snapshot/backup/index-kjh-201712/_restore
查看恢復狀態：
GET http://127.0.0.1:9200/_recovery/index-kjh-201712
GET http://127.0.0.1:9200/_recovery/
刪除一個快照存儲桶：
curl -XDELETE localhost:9200/_snapshot/backup/index-kjh-201712?pretty
{
"acknowledged" : true
}
部分恢復：
默認情況下，如果一個或多個索引在快照中沒有可用的分片，整個恢復操作將失敗。可以通過設置部分恢復爲true，以恢復這些索引。注意：在這種情況下，只有成功的分片快照被恢復，丟失的分片將被重建爲空的。
恢復到另一個集羣
快照存儲的信息不依賴於特定的集羣或集羣名稱。因此，可以恢復到另一個集羣。這需要在新的集羣上註冊快照包含的存儲介質，並啓動恢復過程。新集羣不必具有相同的大小或者拓撲，但是，新集羣的版本要與所創建的快照的版本一樣或者更高。
可以減少索引副本以恢復成更小的集羣。
如果原始集羣的索引使用分片分配過濾被分配到特定節點，同樣的規則將在新集羣中強制執行。因此，如果新的集羣不包含與該索引恢復的分配屬性的適當節點，該索引將不會恢復成功的，除非這些索引在恢復操作過程中分配設置被更改。
恢復操作也支持wait_for_completion參數，會阻止客戶端一直到操作完成。這是獲知關於操作完成的最簡單方法。
同一時刻，只允許執行一個快照或者一個恢復操作。
恢復操作使用標準的分片恢復機制。因此，當前運行的任何恢復操作可通過刪除正在恢復的索引來中止。該操作的結果將會把刪除索引的數據從集羣中清除。
跨集羣恢復步驟如下：
clusterA —— 配置s3備份環境----clusterA執行備份到S3存儲桶
clusterB —— 配置s3備份環境(指向clusterA備份存儲桶)----clusterB執行恢復操作