如果有人可以分享他最好的“热备份”策略，那将会很有趣ElasticSearch。
此外，请随时分享与此问题相关的工具和库，并可以提供帮助。
更新： 感谢@javanna 的回复，它非常完整，为进一步的行动提供了良好的方向。
我还进行了一项小型研究，发现了一些文章/讨论，如果有人感兴趣，它们会有所帮助。
更新： Elasticsearch 1.0 有一个“官方”备份解决方案 -快照/恢复 API，这是现在唯一正确的方法。ElasticSearch 将识别主分片并注意一致性。备份将以增量方式完成，因此您将能够非常快速且尽可能频繁地进行备份。
副本是一种备份，elasticsearch 永远不会在原始主分片所在的同一节点上分配副本。但是仍然存在丢失数据的风险，具体取决于集群中有多少分片、副本和节点。
我会看一下网关模块，通过它您可以保存索引和集群元数据。有不同类型的网关。例如，我会查看Shared FS，它允许您将索引和元数据复制到在所有节点之间共享的文件系统。您还可以通过网关快照 API手动启动快照。
此外，通过index.translog.disable_flush 索引设置禁用刷新后，您可以复制数据目录（在每个节点上）。这样，您将确保在复制时不会发出 lucene 提交。制作副本后，您需要再次启用刷新。
更新
除本地网关类型外，所有网关类型均已弃用，并将在未来版本中删除。Elasticsearch 1.0 将发布一个更好的备份解决方案。
因此，这与 ElasticSearch 的工作方式背道而驰，但我会考虑拥有 2 个彼此不了解的独立 ElasticSearch 实例。在您的应用程序代码中，每个命令都会发送到两个实例。如果 1 个实例的命令失败，请在 1 分钟后重试该命令，然后继续重试。现在您可以保留其中 1 个实例作为热备份，或者您甚至可以使用它来通过负载平衡 2 个实例之间的查询来提高性能。
我不喜欢在 ElasticSearch 中设置副本的原因是配置哪个节点获取哪个副本很痛苦，而且如果您将来想要重新安排组织，您基本上必须经历很多麻烦。ElasticSearch 在幕后进行了大量的重新平衡，并尝试为您做所有事情。这可能很好..如果您拥有强大的服务器并且不在乎什么得到什么..但否则可能会很痛苦。