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