一旦你备份过了数据,恢复它就简单了:只要在你希望恢复回集群的快照 ID后面加上 _restore
即可:
POST _snapshot/my_backup/snapshot_1/_restore
默认行为是把这个快照里存有的所有索引都恢复。如果 snapshot_1
包括五个索引,这五个都会被恢复到我们集群里。和 snapshot
API 一样,我们也可以选择希望恢复具体哪个索引。
还有附加的选项用来重命名索引。这个选项允许你通过模式匹配索引名称,然后通过恢复进程提供一个新名称。如果你想在不替换现有数据的前提下,恢复老数据来验证内容,或者做其他处理,这个选项很有用。让我们从快照里恢复单个索引并提供一个替换的名称:
POST /_snapshot/my_backup/snapshot_1/_restore
{
"indices": "index_1", (1)
"rename_pattern": "index_(.+)", (2)
"rename_replacement": "restored_index_$1" (3)
}
-
只恢复
index_1
索引,忽略快照中存在的其余索引。 -
查找所提供的模式能匹配上的正在恢复的索引。
-
然后把它们重命名成替代的模式。
这个会恢复 index_1
到你及群里,但是重命名成了 restored_index_1
。
Tip
|
和快照类似, POST _snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true |
从仓库恢复数据借鉴了 Elasticsearch 里已有的现行恢复机制。在内部实现上,从仓库恢复分片和从另一个节点恢复是等价的。
如果你想监控恢复的进度,你可以使用 recovery
API。这是一个通用目的的 API,用来展示你集群中移动着的分片状态。
这个 API 可以为你在恢复的指定索引单独调用:
GET restored_index_3/_recovery
或者查看你集群里所有索引,可能包括跟你的恢复进程无关的其他分片移动:
GET /_recovery/
输出会跟这个类似(注意,根据你集群的活跃度,输出可能会变得非常啰嗦!):
{
"restored_index_3" : {
"shards" : [ {
"id" : 0,
"type" : "snapshot", (1)
"stage" : "index",
"primary" : true,
"start_time" : "2014-02-24T12:15:59.716",
"stop_time" : 0,
"total_time_in_millis" : 175576,
"source" : { (2)
"repository" : "my_backup",
"snapshot" : "snapshot_3",
"index" : "restored_index_3"
},
"target" : {
"id" : "ryqJ5lO5S4-lSFbGntkEkg",
"hostname" : "my.fqdn",
"ip" : "10.0.1.7",
"name" : "my_es_node"
},
"index" : {
"files" : {
"total" : 73,
"reused" : 0,
"recovered" : 69,
"percent" : "94.5%" (3)
},
"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
字段告诉你恢复的本质;这个分片是在从一个快照恢复。 -
source
哈希描述了作为恢复来源的特定快照和仓库。 -
percent
字段让你对恢复的状态有个概念。这个特定分片目前已经恢复了 94% 的文件;它就快完成了。
输出会列出所有目前正在经历恢复的索引,然后列出这些索引里的所有分片。每个分片里会有启动/停止时间、持续时间、恢复百分比、传输字节数等统计值。