首先创建好hdfs 集群，再修改一下 hdfs-site.xml ，添加
<property>
<name>dfs.permissions</name>
<value>false</value>
</property>
因为我的hdfs是用root用户操作的，elasticsearch 是用 es 用户操作的，先禁止dfs的权限检查
之后重启hdfs集群
开始给es添加hdfs插件，
在es的 bin 目录下，执行 ./elasticsearch-plugin install repository-hdfs 等待安装完成，有些慢
安装之后需要你输入yes，来获取对应操作es的权限
那个里面有对应的权限，
之后修改es 的jvm配置
添加： -Djava.security.policy=file:////home/es/elasticsearch/plugins/repository-hdfs/plugin-security.policy
来设置安全策略，之后重启es
开始进行备份。
curl -XPUT '192.168.93.129:9200/my_index/my_type/1' -d '{"id": 1,"name": "aa"}'
curl -XPUT '192.168.93.129:9200/my_index/my_type/2' -d '{"id": 2,"name": "bb"}'
添加了两条数据
curl -XGET 'http://192.168.93.129:9200/_count?pretty' -d '
{
"query": {
"match_all": {}
}
}'
创建索引仓库：
curl -XPUT 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository' -d '
{
"type": "hdfs",
"settings": {
"uri": "hdfs://192.168.93.129:9000/",
"path": "elasticsearch/respositories/my_hdfs_repository",
"conf.dfs.client.read.shortcircuit": "false",
"max_snapshot_bytes_per_sec" : "50mb",
"max_restore_bytes_per_sec" : "50mb"
}
}'
my_hdfs_repository 是仓库的名字
对索引进行snapshotting备份
（1）对所有open的索引进行snapshotting备份
一个仓库可以包含多分snapshot，每个snapshot是一部分索引的备份数据，创建一份snapshot备份时，我们要指定要备份的索引。比如下面这行命令：PUT _snapshot/my_hdfs_repository/snapshot_1，这行命令就会将所有open的索引都放入一个叫做snapshot_1的备份，并且放入my_hdfs_repository仓库中。这个命令会立即返回，然后备份操作会被后台继续进行。如果我们不希望备份操作以后台方式运行，而是希望在前台发送请求时等待备份操作执行完成，那么可以加一个参数即可，比如下面这样：PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true。
curl -XPUT 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository/snapshot_2'
（2）对指定的索引进行snapshotting备份
默认的备份是会备份所有的索引，但是有的时候，可能我们不希望备份所有的索引，有些可能是不重要的数据，而且量很大，没有必要占用我们的hdfs磁盘资源，那么可以指定备份少数重要的数据即可。此时可以使用下面的命令去备份指定的索引：
PUT _snapshot/my_backup/snapshot_2
{
"indices": "index_1,index_2",
"ignore_unavailable": true,
"include_global_state": false,
"partial": true
}
ignore_unavailable如果设置为true的话，那么那些不存在的index就会被忽略掉，不会进行备份过程中。默认情况下，这个参数是不设置的，那么此时如果某个index丢失了，会导致备份过程失败。设置include_global_state为false，可以阻止cluster的全局state也作为snapshot的一部分被备份。默认情况下，如果某个索引的部分primary shard不可用，那么会导致备份过程失败，那么此时可以将partial设置为true。
而且snapshotting的过程是增量进行的，每次执行snapshotting的时候，es会分析已经存在于仓库中的snapshot对应的index file，然后仅仅备份那些自从上次snapshot之后新创建的或者有过修改的index files。这就允许多个snapshot在仓库中可以用一种紧凑的模式来存储。而且snapshotting过程是不会阻塞所有的es读写操作的，然而，在snapshotting开始之后，写入index中的数据，是不会反应到这次snapshot中的。每次snapshot除了创建一份index的副本之外，还可以保存全局的cluster元数据，里面包含了全局的cluster设置和template。
每次只能执行一次snapshot操作，如果某个shard正在被snapshot备份，那么这个shard此时就不能被移动到其他node上去，这会影响shard rebalance的操作。只有在snapshot结束之后，这个shard才能够被移动到其他的node上去。
查看snapshot备份列表
一旦我们在仓库中备份了一些snapshot之后，就可以查看这些snapshot相关的详细信息了，使用这行命令就可以查看指定的snapshot的详细信息：GET _snapshot/my_hdfs_repository/snapshot_1，结果大致如下所示。当然也可以查看所有的snapshot列表，GET _snapshot/my_hdfs_repository/_all。
curl -XGET 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository/snapshot_2?pretty'
5、删除snapshot备份
如果要删除过于陈旧的snapshot备份快照，那么使用下面这行命令即可：DELETE _snapshot/my_backup/snapshot_2。记住，一定要用api去删除snapshot，不要自己手动跑到hdfs里删除这个数据。因为snapshot是增量的，有可能很多snapshot依赖于底层的某一个公共的旧的snapshot segment。但是delete api是理解数据如何增量存储和互相依赖的，所以可以正确的删除那些不用的数据。如果我们自己手工进行hdfs文件删除，可能导致我们的backup数据破损掉，就无法使用了。
curl -XDELETE 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository/snapshot_1'
6、监控snapshotting的进度
使用wait_for_completion可以在前台等待备份完成，但是实际上也没什么必要，因为可能要备份的数据量特别大，难道还等待1个小时？？看着是不太现实的，所以一般还是在后台运行备份过程，然后使用另外一个监控api来查看备份的进度，首先可以获取一个snapshot ID：GET _snapshot/my_backup/snapshot_3。如果这个snapshot还在备份过程中，此时我们就可以看到一些信息，比如什么时候开始备份的，已经运行了多长时间，等等。然而，这个api用了跟snapshot一样的线程池去执行，如果我们在备份非常大的shard，进度的更新可能会非常之慢。一个更好的选择是用_status API，GET _snapshot/my_backup/snapshot_3/_status，这个api立即返回最详细的数据。这里我们可以看到总共有几个shard在备份，已经完成了几个，还剩下几个，包括每个索引的shard的备份进度：
curl -XGET 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository/snapshot_1'
7、取消snapshotting备份过程
如果我们想要取消一个正在执行的snapshotting备份过程，比如我们发现备份时间过于长，希望先取消然后在晚上再运行，或者是因为不小心误操作发起了一次备份操作，这个时候就可以运行下面这条命令：DELETE _snapshot/my_backup/snapshot_3。也就是立即删除这个snapshot，这个命令会去取消snapshot的过程，同时将备份了一半的仓库中的数据给删除掉。
curl -XDELETE 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository/snapshot_1'
hdfs仓库。