要備份您的阿里雲elasticsearch集群，您可以使用snapshotapi。該api會拿到您的集群當前的狀態和資料，然後儲存到乙個共享倉庫裡。這個備份過程是」智慧型」的。
您的第乙個快照會是乙個資料的完整拷貝，但所有後續的快照保留的是已存快照和新資料之間的差異。隨著您不時的對資料進行快照，備份也在增量的新增和刪除。這意味著後續備份會相當快速，因為它們只傳輸很小的資料量。
如何使用快照方式，完成自建elasticsearch遷移至阿里雲elasticsearch，詳情請參見 oss快照遷移elasticsearch。
本文**中的 <1>、<2>、<3> 這3個標記，用於標識位置，方便對指定位置**描述。實際執行對應**時，需去掉有包含這3個型別的標記。
put _snapshot/my_backup
}
假設我們上傳的資料非常大, 我們可以限制snapshot過程中分塊的大小，超過這個大小，資料將會被分塊上傳到oss中。
post _snapshot/my_backup/<1>
}
get _snapshot
如果需要將快照遷移到另乙個集群，只需要備份到oss。然後再在新的集群上註冊乙個快照倉庫(相同的oss)，設定base_path的位置為備份檔案所在的地方，然後執行恢復備份的命令即可。
乙個倉庫可以包含多個快照，每個快照跟一系列索引相關（比如所有索引，一部分索引，或者單個索引）。當建立快照的時候，指定您感興趣的索引，然後給快照取乙個唯一的名字。
讓我們從最基礎的快照命令開始：
put _snapshot/my_backup/snapshot_1
這個會備份所有開啟的索引到my_backup倉庫下，並命名為snapshot_1的快照裡。這個呼叫會立刻返回，然後快照會在後台執行。
如果您希望在指令碼中一直等待到完成，可通過新增wait_for_completion標記實現：
put _snapshot/my_backup/snapshot_1?wait_for_completion=true
這個會阻塞呼叫直到快照完成（如果是大型快照，會花很長時間才返回）。
預設行為是備份所有開啟的索引。如果您在用 kibana，且考慮到磁碟空間大小因素，不想把所有診斷相關的.kibana索引都備份起來。
您可以在快照您的集群時，只備份您指定的索引：
put _snapshot/my_backup/snapshot_2
這個快照命令，現在只會備份index1和index2。
有時您可能會忘記倉庫裡的快照細節，特別是快照按時間劃分命名的時候（比如backup_2014_10_28）。
直接對倉庫和快照名發起乙個get請求，獲得單個快照資訊：
get _snapshot/my_backup/snapshot_2
}
]
}
可以使用_all佔位符，替換掉具體的快照名稱，獲取乙個倉庫中所有快照的完整列表：
get _snapshot/my_backup/_all
可對倉庫/快照名稱，發乙個delete命令的 http 呼叫，來刪除所有不再有用的舊快照：
delete _snapshot/my_backup/snapshot_2
使用 api 來刪除快照很重要，而不能使用其他機制（比如手動刪除）。因為快照是增量的，有可能很多快照依賴於過去的段。deleteapi 知道哪些資料還在被更多近期快照使用，然後會只刪除不再被使用的段。
如果您做了一次人工檔案刪除，您將會面臨備份嚴重損壞的風險，因為您刪除的可能是還在使用中的資料。
該wait_for_completion標記，提供了基礎監控形式。如果您需要對中等規模的集群做快照恢復時，可能會不夠用。以下2個 api 會給您提供有關快照狀態更詳細的資訊。
您可以給快照 id 執行乙個get，類似上面獲取乙個特定快照的資訊操作：
get _snapshot/my_backup/snapshot_3
如果您呼叫這個命令時，快照還在進行中。您會看到它什麼時候開始，執行了多久等等資訊。
這個 api 用的是快照機制相同的執行緒池，如果您在快照非常大的分片，狀態更新的間隔會很大，因為 api 在競爭相同的執行緒池資源。
更好的方案是拽取_statusapi 資料：
get _snapshot/my_backup/snapshot_3/_status
以下為_statusapi 返回的詳細統計資訊：
,
"stats":,
"indices":,
"stats":,
"shards":
},
...
如果您想取消乙個快照，可以在任務進行中的時候，執行以下刪除快照命令：
delete _snapshot/my_backup/snapshot_3
這個會中斷快照程序。然後刪除倉庫裡進行到一半的快照。
如果您已備份過資料，執行恢復操作相對比較簡單，只要在您希望恢復回集群的快照 id 後面加上_restore即可：
post _snapshot/my_backup/snapshot_1/_restore
預設行為是把這個快照裡存有的所有索引都恢復。如果snapshot_1包括五個索引，這五個都會被恢復到我們集群裡。和snapshotapi 一樣，我們也可以選擇希望恢復具體哪個索引。
還有附加的選項用來重新命名索引。這個選項允許您通過模式匹配索引名稱，然後通過恢復程序提供乙個新名稱。如果您想在不替換現有資料的前提下，恢復老資料來驗證內容，或者做其他處理，這個選項很有用。讓我們從快照裡恢復單個索引並提供乙個替換的名稱：
post /_snapshot/my_backup/snapshot_1/_restore
這個會恢復index_1到您集群裡，但是重新命名成了restored_index_1。
和快照類似，restore命令也會立刻返回，恢復程序會在後台進行。如果您更希望您的 http 呼叫阻塞直到恢復完成，新增wait_for_completion標記：
post _snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true
從倉庫恢復資料借鑑了 elasticsearch 裡已有的現行恢復機制。在內部實現上，從倉庫恢復分片和從另乙個節點恢復是等價的。
如果您想監控恢復的進度，您可以使用recoveryapi。這是乙個通用目的的 api，用來展示您集群中移動著的分片狀態。
這個 api 可以為您在恢復的指定索引單獨呼叫：
get restored_index_3/_recovery
或者檢視您集群裡所有索引，可能包括跟您的恢復程序無關的其他分片移動：
get /_recovery/
輸出會跟這個類似（注意，根據您集群的活躍度，輸出可能會非常多！）：
,
"target":,
"index":,
"bytes":,
"total_time_in_millis":0
},
"translog":,
"start":
}]
}
}
輸出會列出所有目前正在經歷恢復的索引，然後列出這些索引裡的所有分片。每個分片裡會有啟動/停止時間、持續時間、恢復百分比、傳輸位元組數等統計值。
您可以通過刪除正在恢復的索引，取消乙個恢復。因為恢復程序其實就是分片恢復，傳送乙個刪除索引api 修改集群狀態，就可以停止恢復程序。比如：
delete /restored_index_3
如果restored_index_3正在恢復中，這個刪除命令會停止恢復，同時刪除所有已經恢復到集群裡的資料。
elasticsearch快照操作
使用無論哪個儲存資料的軟體，定期備份你的資料都是很重要的。elasticsearch 副本提供了高可靠性 它們讓你可以容忍零星的節點丟失而不會中斷服務。但是，副本並不提供對災難性故障的保護。對這種情況，你需要的是對集群真正的備份 在某些東西確實出問題的時候有乙個完整的拷貝。要備份你的集群，你可以使用...
elasticsearch 使用快照方式遷移資料
註冊快照倉庫 es是通過快照的方式來實現資料備份，並且是以增量的方式，所以一般第一次做的話會花費較長的時間。為了做快照，那麼就需要註冊乙個快照倉庫，告訴es我們的快照應該如何儲存以及將快照儲存到 es的快照倉庫支援如下幾種形式 共享的檔案系統，如nas amazon s3 hdfs hadoop d...
將Elasticsearch的快照備份到HDFS
1 安裝elasticsearch外掛程式repository hdfs 將zip包放在 usr local下 注意外掛程式版本需要和elasticsearch的版本對應。如果版本不匹配，在安裝時會有提示 cd usr local software elasticsearch 6.2.1 bin e...