我计划使用 ElasticSearch S3 云插件来创建我们的 ES 集群的快照。这一切看起来相当简单，但我想知道是否有可能将其集成到我们现有的备份策略中。
对于其他数据存储，我们每小时都会进行一次完整备份。我们保留最近 24 小时的数据、过去 7 天每天 1 次、过去 4 周每天 1 次以及过去 2 个月每天 1 次...
是否可以通过这种方式创建快照，或者我最好使用 FS 快照存储库，然后压缩内容并挂入相同的上传过程？
我唯一担心的是，快照功能实际上会创建增量备份，这意味着它不起作用。如果知道其他人如何备份他们的 ES 集群就好了。
非常感谢
答案1
去引用文档：
索引快照过程是增量的。在制作索引快照的过程中，Elasticsearch 会分析已存储在存储库中的索引文件列表，并仅复制自上次快照以来创建或更改的文件。这样就可以以紧凑的形式在存储库中保存多个快照。
作为一名从事备份和灾难恢复规划的专业人士，我理解您的担忧。与所有备份一样，处理此策略需要进行一些分析。需要考虑以下几点：
- 数据周转率。如果您只在索引中保留（n）周的数据，则可以容忍一些备份策略。如果索引是一个累加器表，其中没有任何东西被删除并且随着时间的推移它会变得越来越大，那么不同的样式是值得的。
- 增长率. 比如营业额，随着时间的推移它会变得有多大。
- 备份存储限制。很明显。如果它是持续增加的，并且您的周转率很高，那么您的备份存储库将包含很多不需要的东西。
- 备份 I/O 限制。虽然操作是非阻塞的，但它不是零资源。增量比全量更快，但可能出于其他原因需要全量。
快照过程是一种持续增量策略。对于累加器表（无周转），只需执行一次完整操作并永久保留增量即可。除了...
wait_for_completion在快照初始化期间，所有先前快照的信息都会加载到内存中，这意味着在大型存储库中，即使该参数设置为 ，此命令也可能需要几秒钟（甚至几分钟）才能返回false。
这就是您不保留所有内容的动机。两年前的每小时快照历史记录将占用大量内存。幸运的是，他们确实有DELETE功能可以修剪此历史记录。
如果您的周转率确实很高，那么一定要计划DELETE随着时间的推移发布旧快照。根据文档，ES 快照过程足够智能，可以正确处理数据清除过程。即使使用“持续增量”备份系统，您的 GFS 快照策略也绝对可以实现。可以将其想象成一个重复数据删除备份到磁盘系统；您不会每 2 个月清除一次重复数据删除集群，而是让备份系统收获不再需要的块/文件。
如果您需要将这些内容移至异地，则可以复制快照存储库本身并在其上进行常规媒体轮换。快照的 es-repo 用于热备份/恢复。如果出于某种原因您需要加载较旧的快照，您应该能够通过热副本恢复离线副本并从 ES API 调用恢复，它将从您放入快照存储库的数据中加载。