我正计划使用ElasticSearch S3云插件来创buildES群集的快照。 这一切看起来相当直接，但我想知道它是否可能将其整合到我们现有的备份策略中。
通过我们的其他数据存储，我们每小时都会全面备份。 我们保持最新的24小时，过去7天每天1次，过去4周每天1次，最近2个月每次1次。
是否有可能以这种方式创build快照，或者我最好使用FS快照库，然后将内容压缩并挂接到相同的上传过程中？
我唯一担心的是，听起来像快照function本质上创build增量备份，这将意味着这将无法正常工作。 知道其他人如何备份他们的ES群是很好的。
非常感谢
引用文档 ：
索引快照过程是增量式的。 在创build索引快照的过程中，Elasticsearch将分析已存储在存储库中的索引文件的列表，并仅复制自上次快照以来创build或更改的文件。 这允许多个快照以紧凑的forms保存在存储库中。
在备份和灾难恢复计划中度过了职业生涯，我理解您的担忧。 像所有的备份一样，处理这个策略需要一些分析。 有些事情要考虑：
快照程序是一个持续增量的策略。 对于一个累加表（没有营业额），充足一点就足够了，永远保持增量。 除…
在快照初始化期间，有关所有先前快照的信息将被加载到内存中，这意味着在大型存储库中，即使
wait_for_completion参数设置为false，该命令也可能需要几秒（甚至几分钟）的时间才能返回。
这是你不鼓励所有事情的动机。 每两年一次的快照历史logging将占用很多堆。 令人高兴的是，他们确实拥有DELETEfunction来修剪这段历史。
如果你的stream失率很高，那么肯定会计划在一段时间之后发布DELETE到较旧的快照。 根据文档，ES快照过程非常聪明，可以正确处理数据清除过程。 即使采用“连续增量式”备份系统，您的GFS快照策略也可以完成。 把它看作是一个重复数据删除的备份到磁盘系统; 您不会每2个月清除一次重复数据删除群集，您可以让备份系统重新获取不再需要的数据块/文件。
如果你需要离开这个东西，你可以复制快照回购本身，并做它通常的媒体旋转。 快照的es-repo用于热备份/恢复。 如果由于某种原因需要加载较旧的版本，则应该能够通过热副本恢复脱机副本，并从ES API调用恢复，并且将从您放入快照恢复库的数据加载。