本文中含有需要您注意的重要提示信息，忽略該信息可能對您的業務造成影響，請務必仔細閱讀。
通過快照備份與恢復命令，您可以實現手動備份與恢復阿里云Elasticsearch實例的索引數據，并將備份的數據保存到一個共享倉庫里。本文介紹如何手動備份與恢復數據。
背景信息
ES數據備份與恢復依賴于elasticsearch-repository-oss插件，阿里云ES實例默認已安裝該插件且不可卸載。關于該插件的詳細信息，請參見elasticsearch-repository-oss。
前提條件
已開通對象存儲服務OSS（Object Storage Service），并新建一個標準存儲類型的Bucket（不支持歸檔存儲類型），開通Bucket公共讀權限，且Bucket的地域需要與Elasticsearch實例的地域保持一致。 具體操作，請參見開通OSS服務和創建存儲空間。
RAM用戶需要具備
AliyunOSSFullAccess權限策略。具體操作，請參見為RAM用戶授權。
注意事項
快照僅保存索引數據，不保存Elasticsearch實例自身的監控數據（例如以
.monitoring和.security_audit為前綴的索引）、元數據、Translog、實例配置數據、Elasticsearch軟件包、自帶和自定義的插件、Elasticsearch日志等。本文中的代碼均可以在阿里云Elasticsearch實例的Kibana控制臺上執行。詳細信息，請參見登錄Kibana控制臺。
創建倉庫
創建一個名稱為my_backup的倉庫。
云上集群創建倉庫。
PUT _snapshot/my_backup/ { "type": "oss", "settings": { "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com", "access_key_id": "xxxx", "secret_access_key": "xxxxxx", "bucket": "xxxxxx", "compress": true, "chunk_size": "500mb", "base_path": "snapshot/" } }8.x版本自建集群創建倉庫，需要安裝elasticsearch-repository-oss插件。具體操作，請參見安裝elasticsearch-repository-oss插件。
說明關于該插件的詳細信息，請參見elasticsearch-repository-oss。
PUT /_snapshot/my_backup { "type": "oss", "settings": { "oss.client.endpoint": "oss-cn-shanghai.aliyuncs.com", "oss.client.access_key_id": "xxx", "oss.client.secret_access_key": "xxx", "oss.client.bucket": "xxxxxx", "oss.client.base_path":"snapshot/", "oss.client.compress": true } }
參數 | 說明 |
endpoint | OSS Bucket的內網訪問域名。獲取方式，請參見訪問域名和數據中心。 |
access_key_id | 用于標識用戶。獲取方式，請參見獲取AccessKey。 |
secret_access_key | 用于驗證用戶的密鑰。獲取方式，請參見獲取AccessKey。 |
bucket | OSS Bucket的名稱，需要一個已經存在的Bucket。獲取方式，請參見控制臺創建存儲空間。 |
compress | 打開快照文件的壓縮功能：
|
chunk_size | 當您上傳的數據非常大時，配置此參數可以限制快照過程中分塊的大小。超過這個大小，數據將會被分塊上傳到OSS中。 |
base_path | 倉庫的起始位置，默認為根目錄?？梢灾付ň唧w快照的存放目錄，例如snapshot/myindex/。 |
獲取倉庫信息
獲取所有倉庫的信息
GET _snapshot獲取指定倉庫的信息
GET _snapshot/my_backup創建快照
為全部索引創建快照
PUT _snapshot/my_backup/snapshot_1以上命令會為所有打開的索引創建名稱為snapshot_1的快照，并保存到my_backup倉庫中。該命令會立刻返回，并在后臺執行備份任務。如果您希望任務執行完成后再返回，可通過添加wait_for_completion實現。該參數會阻塞調用直到備份完成，如果是大型快照，需要很長時間才能返回。
PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true一個倉庫可以包含多個快照，每個快照中可以包含所有、部分或單個索引的備份數據。
第一次創建快照時，系統會備份所有的數據，后續所有的快照僅備份已存快照和新快照之間的增量數據。隨著快照的不斷進行，備份也在增量的添加和刪除。這意味著后續備份會相當快速，因為它們只傳輸很小的數據量。
為指定索引創建快照
系統默認會備份所有打開的索引。如果您在使用Kibana，并且考慮到磁盤空間大小因素，不需要把所有診斷相關的.kibana索引都備份起來，那么可以在創建快照時，指定需要備份的索引。
PUT _snapshot/my_backup/snapshot_2
{
"indices": "index_1,index_2"
}以上命令只會備份名稱為index_1和index_2的索引。
查看快照信息
查看所有快照信息
GET _snapshot/my_backup/_all預期結果如下：
{
"snapshots": [
{
"snapshot": "snapshot_1",
"uuid": "vIdSCkthTeGa0nSj4D****",
"version_id": 5050399,
"version": "5.5.3",
"indices": [
".kibana"
],
"state": "SUCCESS",
"start_time": "2018-06-28T01:22:39.609Z",
"start_time_in_millis": 1530148959609,
"end_time": "2018-06-28T01:22:39.923Z",
"end_time_in_millis": 1530148959923,
"duration_in_millis": 314,
"failures": [],
"shards": {
"total": 1,
"failed": 0,
"successful": 1
}
},
{
"snapshot": "snapshot_3",
"uuid": "XKO_Uwz_Qu6mZrU3Am****",
"version_id": 5050399,
"version": "5.5.3",
"indices": [
".kibana"
],
"state": "SUCCESS",
"start_time": "2018-06-28T01:25:00.764Z",
"start_time_in_millis": 1530149100764,
"end_time": "2018-06-28T01:25:01.482Z",
"end_time_in_millis": 1530149101482,
"duration_in_millis": 718,
"failures": [],
"shards": {
"total": 1,
"failed": 0,
"successful": 1
}
}
]
}根據快照名查看指定快照的信息
GET _snapshot/my_backup/snapshot_3預期結果如下：
{
"snapshots": [
{
"snapshot": "snapshot_3",
"uuid": "vIdSCkthTeGa0nSj4D****",
"version_id": 5050399,
"version": "5.5.3",
"indices": [
".kibana"
],
"state": "SUCCESS",
"start_time": "2018-06-28T01:22:39.609Z",
"start_time_in_millis": 1530148959609,
"end_time": "2018-06-28T01:22:39.923Z",
"end_time_in_millis": 1530148959923,
"duration_in_millis": 314,
"failures": [],
"shards": {
"total": 1,
"failed": 0,
"successful": 1
}
}
]
}使用_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
}
}
}
}
}
}
]
}刪除快照
刪除指定的快照。如果該快照正在進行，執行以下命令，系統會中斷快照進程并刪除倉庫中創建到一半的快照。
DELETE _snapshot/my_backup/snapshot_3刪除快照請使用DELETE API，而不能使用其他機制刪除（例如手動刪除可能會造成備份嚴重損壞）。因為快照是增量的，很多快照可能依賴于之前的備份數據。DELETE API能夠過濾出還在被其他快照使用的數據，只刪除不再被使用的備份數據。
從快照恢復
建議不要恢復
.開頭的系統索引，此操作可能會導致Kibana訪問失敗。如果集群中存在與待恢復索引同名的索引，需要提前刪除或者關閉該同名索引后再恢復，否則恢復失敗。
如果需要跨地域恢復集群快照，需要先將原地域OSS中的快照數據遷移到目標地域的OSS中，再恢復到目標地域的Elasticsearch集群中。OSS間遷移的具體操作，請參見遷移實施。
在目標集群中創建OSS倉庫
在將快照恢復到目標集群前，需要在目標集群中創建倉庫，并映射到與快照備份相同的OSS地址中，詳細信息請參見創建倉庫。
PUT _snapshot/my_backup_restore/
{
"type": "oss",
"settings": {
"endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
"access_key_id": "xxxx",
"secret_access_key": "xxxxxx",
"bucket": "xxxxxx",
"compress": true,
"chunk_size": "500mb",
"base_path": "snapshot/"
}
}恢復指定索引
如果您需要在不替換現有數據的前提下，恢復舊版本的數據來驗證內容，或者進行其他處理，可恢復指定的索引，并重命名該索引。
POST /_snapshot/my_backup_restore/snapshot_1/_restore
{
"indices": "index_1",
"rename_pattern": "index_(.+)",
"rename_replacement": "restored_index_$1"
}參數 | 說明 |
indices | 只恢復index_1索引，忽略快照中的其他索引。 |
rename_pattern | 查找正在恢復的索引，該索引名稱需要與提供的模板匹配。 |
rename_replacement | 重命名查找到的索引。 |
恢復所有索引（除.開頭的系統索引）
POST _snapshot/my_backup_restore/snapshot_1/_restore
{"indices":"*,-.monitoring*,-.security*,-.kibana*","ignore_unavailable":"true"}恢復所有索引（包含.開頭的系統索引）
POST _snapshot/my_backup_restore/snapshot_1/_restore假設snapshot_1中包含5個索引，那么這5個索引都會被恢復到集群中。
_restore API會立刻返回，恢復進程會在后臺進行。如果您希望調用阻塞直到恢復完成，可以添加wait_for_completion參數。
POST _snapshot/my_backup_restore/snapshot_1/_restore?wait_for_completion=true
將快照恢復到Indexing Service實例中。
將index_1索引數據恢復到Indexing Service實例中，并且放到my_backup_restore倉庫下，示例如下。
實際使用時，您需要將對應信息替換為您實際的信息。
POST /_snapshot/my_backup_restore/snapshot_1/_restore
{
"indices": "index_1",
"ignore_index_settings": [
"index.apack.cube.following_index"
]
}查看快照恢復信息
您可以通過_recovery API來監控快照恢復的狀態、進度等信息。
查看快照中指定索引的恢復狀態
GET restored_index_3/_recovery查看集群中的所有索引的恢復信息
獲取的恢復信息可能包含跟您的恢復進程無關的其他分片的恢復信息。
GET /_recovery/預期結果如下：
{
"restored_index_3" : {
"shards" : [ {
"id" : 0,
"type" : "snapshot",
"stage" : "index",
"primary" : true,
"start_time" : "2014-02-24T12:15:59.716",
"stop_time" : 0,
"total_time_in_millis" : 175576,
"source" : {
"repository" : "my_backup",
"snapshot" : "snapshot_3",
"index" : "restored_index_3"
},
"target" : {
"id" : "ryqJ5lO5S4-lSFbGnt****",
"hostname" : "my.fqdn",
"ip" : "10.0.**.**",
"name" : "my_es_node"
},
"index" : {
"files" : {
"total" : 73,
"reused" : 0,
"recovered" : 69,
"percent" : "94.5%"
},
"bytes" : {
"total" : 79063092,
"reused" : 0,
"recovered" : 68891939,
"percent" : "87.1%"
},
"total_time_in_millis" : 0
},
"translog" : {
"recovered" : 0,
"total_time_in_millis" : 0
},
"start" : {
"check_index_time" : 0,
"total_time_in_millis" : 0
}
} ]
}
}輸出結果會展示所有恢復中的索引，并列出這些索引中的所有分片。同時每個分片中會展示啟動和停止時間、持續時間、恢復百分比、傳輸字節數等統計值。部分參數說明如下。
參數 | 說明 |
type | 恢復的類型。snapshot表示這個分片是在從一個快照恢復。 |
source | 待恢復的快照和倉庫。 |
percent | 恢復的進度。94.5%表示對應分片已經恢復了94.5%的數據。 |
刪除正在進行快照恢復的索引
通過DELETE命令刪除正在恢復的索引，取消恢復操作。
DELETE /restored_index_3如果restored_index_3正在恢復中，以上刪除命令會停止恢復，同時刪除所有已經恢復到集群中的數據。