如果有人能分享他对ElasticSearch的最佳"热备份"策略，那将是一件有趣的事情。
此外，请随时分享与此问题相关的工具和库，并提供帮助。
更新：感谢@javanna的回复，它非常完整，为进一步的行动提供了良好的指导。
我还做了一项小型研究，发现了一些文章/讨论，如果有人感兴趣，这些文章/讨论会有所帮助。
- Elasticsearch备份策略
- github:gist上的备份/恢复Elasticsearch索引和相关片段
- 弹性搜索备份和恢复讨论(查看Paul Smith的评论，他还分享了一个有用的链接，指向他的验证索引的工具)
更新：Elasticsearch 1.0有一个"官方"备份解决方案-快照/恢复API，这是目前唯一正确的方法。ElasticSearch将识别主碎片并注意一致性。备份将以增量方式进行，因此您将能够以非常快的速度随时进行备份。
副本是一种备份，弹性搜索从不在原始主碎片所在的同一节点上分配一个副本。但是，根据集群中有多少碎片、副本和节点，仍然存在丢失数据的风险。
我将查看网关模块，通过它可以保存索引和集群元数据。有不同类型的网关。以SharedFS为例，它允许您将索引和元数据复制到所有节点之间共享的文件系统中。您还可以通过网关快照API手动启动快照。
此外，一旦通过index.translog.disable_flush索引设置禁用了flush，就可以复制数据目录(在每个节点上)。这样，您就可以确保在复制时不会发出lucene提交。复制后，您需要再次启用flush。
更新
除本地网关类型外，所有网关类型都已弃用，并将在将来的版本中删除。Elasticsearch 1.0将发布一个更好的备份解决方案。
所以这与ElasticSearch的工作方式相反，但我会考虑使用两个彼此不知道的独立ElasticSearch实例。在应用程序代码中，每个命令都会发送到这两个实例。如果一个命令有一个实例失败，请在1分钟后重试该命令，然后继续重试。现在，您可以保留其中一个实例作为热备份，甚至可以使用它通过在两个实例之间负载平衡查询来提高性能。
我不喜欢在ElasticSearch中设置副本的原因是，配置哪个节点获得哪个副本是一件很痛苦的事情，如果你想在未来重新安排组织，你基本上必须经历很多困难。ElasticSearch在幕后进行了大量的再平衡，并试图为您做一切。这可能很好。。如果你有强大的服务器，而不在乎什么得到什么。。但在其他方面可能是一种痛苦。