官方文档-快照和恢复

Posted 2023-03-18

参考技术A

对应7.17官方文档路径： Snapshot and restore
官方地址如下：
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/snapshot-restore.html

快照是正在运行的 ES 集群的备份，你可以使用快照做以下事情：

ES 将快照存储在集群存储外的存储空间内，称为快照仓库(snapshot repository)。在你制作或者恢复快照之前，你必须在集群上注册一个快照仓库，ES 支持多种具备云存储属性的存储库，包括：

在注册快照仓库后，你可以使用快照生命周期管理(SLM)自动创建并管理快照，你可以通过恢复快照(restore)恢复或者传输数据。

默认集群快照包含集群状态，全部 data streams，全部 open 状态的索引，包括系统索引。集群状态包含如下内容：

你还可以仅对集群中的特定数据流或索引进行快照。包含数据流或索引的快照会自动包含其别名。还原快照时，你可以选择是否还原这些别名。

快照不包含以下内容：

功能状态包含用来存储配置、历史记录和 ES 的其他功能的索引和数据流，例如 security 和 kibana 相关索引。
功能状态通常包含一个或者多个系统索引或者数据流，还可能包含该功能使用的常规索引和数据流。例如，功能状态可能包含该功能执行历史的常规索引，将此历史记录存储在常规索引中可以让您更轻松地搜索它。

快照会自动删除重复数据来节约存储空间并减少网络传输开销。备份索引时，快照会复制一个索引 segments 的副本并将它们存储在快照仓库。由于段是不可变的，快照只需要复制自存储库的最后一个快照以来新创建的全部段。
每个快照在逻辑上也是独立的。当你删除快照时，ES 只会删除该快照专门使用的段，不会删除仓库中其他快照使用的段。

快照从索引的主分片复制段。当你开始制作一个快照，ES 立刻开始复制任何可用的主分片的段。如果一个分片正在启动或者在重新定位中，ES 将等待这些过程完成后再进行复制。如果一个或多个主分片不可用，快照制作将失败。
一旦快照开始复制分片的段，ES 将不会依据重新平衡和分片分配设置规则移动分片到其他节点，在快照完成复制数据后才会进行分片移动。

快照不代表某一个精确时间点集群的数据状态。每个快照都包含起止时间，快照代表起止时间范围内的某一个时间点每个分片的数据视图。

要将快照恢复到其他集群集群，快照、集群和任何恢复的索引的版本必须兼容。

你无法将快照还原到早期版本的 ES。例如你无法将在 7.6.0 中拍摄的快照恢复到 7.5.0 版本集群。

你从快照恢复的任何索引也必须与当前集群的版本兼容。如果你尝试恢复在不兼容版本集群中创建的索引，则恢复将失败。

制作快照是备份集群唯一可靠且受支持的方式。 你不能通过复制节点的数据目录来备份 ES 集群，官方没有方式支持从文件系统级别的备份恢复数。如果你尝试从此类备份中恢复集群，它可能会因损坏或丢失文件或其他数据不一致而报告失败，或者它可能已经成功地默默地丢失了一些数据。
集群节点的数据目录副本不能用作备份，因为它不是其内容在单个时间点的一致表示。您无法通过在制作副本时关闭节点来解决此问题，也无法通过获取原子文件系统级快照来解决此问题，因为 ES 具有跨越整个集群的一致性要求，您必须使用内置快照功能进行集群备份。

不要修改备份仓库中的任何内容或运行可能会干扰其内容的进程。 如果 ES 以外的东西修改了仓库内容，那么未来制作快照或者恢复操作可能会失败，报告损坏或者其他数据不一致问题，或者默默地丢失了一些数据并报告成功。

但是，你可以安全的从快照仓库的备份中恢复其内容，只要：

官方文档-恢复快照

参考技术A

对应8.0官方文档路径：Snapshot and restore » Restore a snapshot
官方地址如下：
https://www.elastic.co/guide/en/elasticsearch/reference/8.0/snapshots-restore-snapshot.html

本章节主要展示如何恢复一个快照。快照是在集群外部存储数据备份最便捷的方式，你可以在删除或硬件故障后通过快照恢复索引和数据流，你还可以使用快照在集群之间传输数据。
在本章节，你将学会以下内容：

本章节还提供 恢复到其他集群 和 常见错误解决 相关内容。

在 kibana 中可以使用 Stack Management > Snapshot and Restore 功能查看可用快照列表。
你还可以使用 get repository API 和 get snapshot API 来查找可用于恢复的快照。首先，使用 get repository API 获取已注册的快照存储库列表。

然后使用 get snapshot API 来获取特定存储库中的快照列表，这也会返回每个快照的内容。

你可以使用 Kibana 的 快照和恢复 功能或 restore snapshot
API 恢复快照。
默认情况下，恢复请求会尝试恢复快照中的所有常规索引和常规数据流。在大多数情况下，您只需要从快照中恢复特定的索引或数据流。但是，你无法恢复现有的打开索引。
如果你要将数据恢复到预先存在的集群，请使用以下方法之一来避免与现有索引和数据流发生冲突：

最简单的避免恢复冲突的方式就是在恢复索引或数据流前先删除存在的索引，为防止意外重新创建索引或数据流，我们建议暂时停止所有索引数据操作，直到恢复操作完成。

在恢复请求中，可以明确指定要恢复的任何索引和数据流。

如果你想避免删除现有数据，可以重命名你要恢复的索引和数据流。通常使用此方法将现有数据与快照中的历史数据进行比较。例如，可以使用此方法在意外更新或删除后查看文档。
在开始之前，请确保集群有足够的容量容纳现有数据和恢复的数据。
以下 restore snapshot API 请求会将 restored- 添加到任何恢复的索引或数据流的名称之前。

如果重命名选项产生两个或更多具有相同名称的索引或数据流，则恢复操作将失败。
如果你重命名一个数据流，它的后备索引也会被重命名。例如，如果将 logs-my_app-default 数据流重命名为 restored-logs-my_app-default，则后备索引 .ds-logs-my_app-default-2099.03.09-000005 将重命名为 .ds-restored-logs-my_app-default-2099.03.09-000005。
恢复操作完成后，你可以比较原始数据和恢复的数据，如果你不再需要原始索引或者数据流，可以将其删除并使用 reindex API 来重命名恢复的索引。

你可以恢复 feature state 以从快照中恢复功能的系统索引、系统数据流和其他配置数据。
如果你恢复快照的集群状态，默认操作会同时恢复全部的功能状态。如果你不恢复集群状态默认也就不会恢复功能状态。你也可以选择从快照恢复特定的功能状态，而忽视集群状态。
使用 get snapshot API 来查看快照的功能状态：

回复的 feature_states 属性包含快照中的功能列表以及每个功能用到的索引。
要从快照恢复特定功能状态，需要在恢复快照 API 的 feature_states 参数中指定特定的 feature_name 。当你恢复功能状态时，ES 会关闭并覆盖功能的现有索引。

在某些情况下，你需要从快照中恢复整个集群，包括集群状态和所有功能状态。这些情况应该很少见，只会在发生灾难性故障的情况下。
恢复整个集群涉及删除重要的系统索引，包括那些用于身份验证的索引。考虑是否可以改为恢复特定索引或数据流。

恢复操作使用 shard recovery process 从快照恢复索引的主分片。当恢复操作恢复主分片时，集群将处于 yellow 健康状态。
恢复所有主分片后，复制程序会在符合条件的数据节点上创建和分发副本。副本复制完成后，集群运行状况通常会变为 green 。
在 Kibana 中开始恢复后，你将导航到 Restore Status 页面。你可以使用此页面来跟踪快照中每个分片的当前状态。
您还可以使用 ES API 监控快照恢复。
要监控集群健康状态，请使用 cluster health API：

要获取有关正在进行的分片恢复的详细信息，请使用 index recovery API：

要查看任何未分配的分片，请使用 cat shards API：

未分配的分片具有 UNASSIGNED 的 state 状态，p 表示主分片 r 表示副本分片。 unassigned.reason 描述了为什么分片仍未分配。
要更深入地了解未分配分片的分配状态，请使 cluster allocation explanation API：

你可以删除索引或数据流以取消其正在进行的恢复。这也会删除集群中索引或数据流的任何现有数据。删除索引或数据流不会影响快照及其数据。

快照不绑定到特定集群或集群名称。你可以在一个集群中创建快照并在另一个兼容的集群中恢复它。你从快照恢复的任何数据流或索引也必须与当前集群的版本兼容。集群之间的拓扑结构不需要一致。
要恢复快照，其仓库必须已注册并可供新集群使用。如果原始集群仍然具有对仓库的写入权限，请将新集群仓库注册为只读。这可以防止多个集群同时写入快照仓库并破坏仓库的内容。它还可以防止 ES 缓存仓库的内容，这意味着其他集群所做的更改将立即变得可见。
在开始还原操作之前，请确保新集群有足够的容量来存储你要还原的任何数据流或索引。如果新集群的容量较小，你可以：

如果原始集群中的索引通过 shard allocation filtering 分配到了特定节点，则在新集群中将执行相同的规则。如果新集群不包含具有可在其上分配恢复索引的适当属性的节点，则索引将不会成功恢复除非在恢复操作期间对这些索引分配设置进行修改。
恢复操作还会检查恢复的持久设置是否与当前集群兼容，以避免意外恢复不兼容的设置。如果您需要使用含有不兼容的持久设置快照进行恢复操作，请尝试恢复时忽略集群状态。