elasticsearch 备份 与 恢复

最近 同事不小心把 数据给删除了，没办法就想到怎么恢复 数据 ，后来百度 ，查看前辈的资料，自己整理一下，希望以后有用

下面具体  细节：

es 快照 和 恢复

1 查看所有 快照 

在任何快照或者恢复操作之前，需要先完成一个快照存储介质的注册。
查看所有的存储介质：
curl localhost:9200/_snapshot/_all
curl localhost:9200/_snapshot  // 单独指定


共享文件存储介质
共享文件存储介质类型是fs，使用共享文件系统来存储快照。
假如共享文件存储介质挂载在/mount/back目录下，需要在elasticsearch.yml添加如下配置：


(注意 这一步是关键 否则 报错)
path.repo: ["/mount/back"]  // 存储 地址 windows 下面 可以指定 D:/ziliao/elasticsearch-2.3.3/data/back(我自己的存储路径)


第一步 创建 仓库


Elasticsearch的一大特点就是使用简单，api也比较强大，备份也不例外。简单来说，备份分两步：1、创建一个仓库。2、备份指定索引。下面一步一步来：


备份数据之前，要创建一个仓库来保存数据，仓库的类型支持Shared filesystem, Amazon S3, HDFS和Azure Cloud。下面以文件系统为例：


PUT http://127.0.0.1:9200/_snapshot/back 
{
    "type": "fs", 
    "settings": {
        "location": "D:/ziliao/elasticsearch-2.3.3/data/back/my_backup" 
    }
}


上面的代码，我们创建了一个名叫my_backup 的备份，存放在本地的D:/ziliao/elasticsearch-2.3.3/data/back/my_backup 目录下。除了location 参数外，还可以通过max_snapshot_bytes_per_sec 和max_restore_bytes_per_sec 来限制备份和恢复时的速度，如下：


更新 代码


POST http://127.0.0.1:9200/_snapshot/back/ 
{
    "type": "fs",
    "settings": {
        "location": "D:/ziliao/elasticsearch-2.3.3/data/back/my_backup",
        "max_snapshot_bytes_per_sec" : "50mb", 
        "max_restore_bytes_per_sec" : "50mb"
    }
}


注意：第一段代码用的是PUT 请求，用来创建repository，第二段代码用的是POST 请求，来修改已经存在的repository


第二步 备份索引


仓库创建好之后就可以开始备份了。一个仓库可以包含多个快照（snapshots），快照可以存所有的索引，部分索引或者一个单独的索引。可以给索引指定一个唯一的名字：
PUT http://127.0.0.1:9200/_snapshot/back/my_backup/snapshot_1


上面的代码会将所有正在运行的索引，备份到my_backup仓库下一个叫snapshot_1的快照中。上面的api会立刻返回，然后备份工作在后台运行。如果你想api同步执行，可以加wait_for_completion 标志：


PUT http://127.0.0.1:9200/_snapshot/back/my_backup/snapshot_1?wait_for_completion=true




如果只想备份部分索引的话，可以加上indices 参数：


PUT http://127.0.0.1:9200/_snapshot/back/my_backup/snapshot_2
{
    "indices": "index_1,index_2"
}


删除备份


不要手动删除文件（Elasticsearch一贯主张使用api操作，尤其是大集群中），删除snapshot_2：


DELETE http://127.0.0.1:9200/_snapshot/back/my_backup/snapshot_2


如果备份正在后台进行，也可以直接删除来取消此次备份。


查看备份信息


GET http://127.0.0.1:9200/_snapshot/back/my_backup/snapshot_2
返回信息
{
"snapshots": [
{
"snapshot": "my_backup",
"version_id": 2030399,
"version": "2.3.3",
"indices": [
"domain_v12"
],
"state": "SUCCESS",
"start_time": "2017-04-14T02:38:17.401Z",
"start_time_in_millis": 1492137497401,
"end_time": "2017-04-14T02:38:22.324Z",
"end_time_in_millis": 1492137502324,
"duration_in_millis": 4923,
"failures": [ ],
"shards": {
"total": 1,
"failed": 0,
"successful": 1
}
}
]
}


如果要查看所有索引的信息，使用如下api：GET http://127.0.0.1:9200/_snapshot/back/my_backup/_all


另外还有个一api可以看到更加详细的信息：GET http://127.0.0.1:9200/_snapshot/back/my_backup/snapshot_3/_status




恢复


备份好后，恢复就更容易了，恢复snapshot_1里的全部索引：POST http://127.0.0.1:9200/_snapshot/back/my_backup/snapshot_1/_restore


这个api还有额外的参数：


POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore
{
    "indices": "index_1", 
    "rename_pattern": "index_(.+)", 
    "rename_replacement": "restored_index_$1" 
}
参数indices 设置只恢复index_1索引，参数rename_pattern 和rename_replacement 用来正则匹配要恢复的索引，并且重命名。和备份一样，api会立刻返回值，然后在后台执行恢复，使用wait_for_completion 标记强制同步执行。






在恢复过程中更改索引设置：
在恢复过程中，大部分索引设置可以被覆盖。如下面的例子恢复index_1索引，不创建任何副本，且刷新间隔设置为默认。
POST /_snapshot/backup/snapshot_1/_restore
{
"indices": "index_1",
"index_settings": {
     "index.number_of_replicas": 0
},
"ignore_index_settings": [
     "index.refresh_interval"
     ]
}
注意：一些设置如index.number_of_shards在恢复过程中是不能被改变的。




另外可以使用下面两个api查看状态：


GET http://127.0.0.1:9200/_recovery/restored_index_3
GET http://127.0.0.1:9200/_recovery/


如果要取消恢复过程（不管是已经恢复完，还是正在恢复），直接删除索引即可：


DELETE http://127.0.0.1:9200/restored_index_3


恢复到另一个集群

快照存储的信息不依赖于特定的集群或集群名称。因此，可以恢复到另一个集群。这需要在新的集群上注册快照包含的存储介质，并启动恢复过程。新集群不必具有相同的大小或者拓扑，但是，新集群的版本要与所创建的快照的版本一样或者更高。
可以减少索引副本以恢复成更小的集群。
如果原始集群的索引使用分片分配过滤被分配到特定节点，同样的规则将在新集群中强制执行。因此，如果新的集群不包含与该索引恢复的分配属性的适当节点，该索引将不会恢复成功的，除非这些索引在恢复操作过程中分配设置被更改。
恢复操作也支持wait_for_completion参数，会阻止客户端一直到操作完成。这是获知关于操作完成的最简单方法。
同一时刻，只允许执行一个快照或者一个恢复操作。
恢复操作使用标准的分片恢复机制。因此，当前运行的任何恢复操作可通过删除正在恢复的索引来中止。该操作的结果将会把删除索引的数据从集群中清除。