Elasticsearch快照和备份

在过去的一年中，我们看到许多公司对Elasticsearch的采用率大幅提升。随着越来越多的公司将Elasticsearch作为其业务不可或缺的一部分，Elasticsearch的高可用性变得越来越重要。借助自动复制和故障转移，Elasticsearch提供稳定，高度可用的搜索和分析平台。但是，虽然复制可以保护群集免受硬件故障的影响，但是当有人意外删除索引时，它无济于事。依赖Elasticsearch集群的任何人都需要执行定期备份。

始终可以备份Elasticsearch集群。但是，在版本1.0之前，备份过程包括关闭索引刷新，识别文件系统上主分片的位置，复制数据，然后记住再次打开刷新。我们认为简单是最好的，而Elasticsearch中的先前备份过程并不完全符合简单的定义。这就是为什么在v1.0中我们引入了一个新的Snapshot＆Restore API，它可以使备份过程变得更加容易。

在v1.0中，备份是一个简单而直接的过程。首先，Elasticsearch需要知道备份数据的位置，这是通过注册备份存储库来完成的：

curl -XPUT 'http://localhost:9200/_snapshot/my_backup' -d '{ "type": "fs", "settings": { "location": "/mount/backups/my_backup", "compress": true } }'

目前，我们支持文件系统和HDFS存储库。对Azure的支持即将推出。一旦Elasticsearch了解了存储库，就可以使用一个命令对整个集群进行备份：

curl -XPUT "localhost:9200/_snapshot/my_backup/snapshot_1?wait_for_completion=true"

可以在继续执行索引和搜索操作的实时群集上创建快照。快照捕获快照进程启动时索引的时间点视图。它使索引的备份映像保持一致。恢复更简单：

curl -XPOST "localhost:9200/_snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true"

也可以在实时集群中恢复索引。但是，必须在恢复之前关闭所有索引。我们计划在将来的版本中恢复开放的只读索引。

备份和还原操作都是增量操作，这意味着只有自上次快照以来更改的文件才会复制到存储库或还原到索引中。增量快照允许根据需要频繁执行快照操作，而不会产生太多磁盘空间开销。用户现在可以在升级之前轻松创建快照或在集群中进行风险更改，并在出现问题时快速回滚到先前的索引状态。快照/恢复机制还可用于在“热”群集和不同地理区域中的远程“冷”备份群集之间同步数据，以实现快速灾难恢复。

我们对这个新功能感到非常兴奋。我们希望将增量备份视为数据的时间机器。我们相信，依赖Elasticsearch作为其系统中的关键组件且无法负担重新索引时间的每个人都会发现新的快照和恢复机制非常有用。