官方文档-恢复快照

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

恢复快照

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

• 获取可用快照列表
• 从快照恢复一个索引或者数据流
• 恢复功能状态
• 恢复整个集群
• 监控恢复操作
• 取消正在进行的恢复

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

先决条件

• 想要使用 Kibana的 Snapshot and Restore 功能，你必须具备一下权限：
  • 集群权限：monitor, manage_slm, cluster:admin/snapshot, cluster:admin/repository
  • 索引权限：monitor 索引 all 权限
• 你只能在具有选定主节点的正在运行的集群上恢复快照，且快照仓库必须已在集群注册且为可用的
• 快照和集群版本必须兼容
• 要恢复快照，必须保证集群的全局元数据可写入。确保没有任何cluster blocks配置阻止写操作，index blocks配置不影响快照恢复
• 在恢复数据流之前，确保集群包含数据流所需要的索引模板。可以使用 kibana 的 Index Management 功能或者 get index template API：

  GET _index_template/*?filter_path=index_templates.name,index_templates.index_template.index_patterns,index_templates.index_template.data_stream
  

  如果没有可用的模板，你可以创建一个或者从 cluster state 快照中恢复模板。如果没有匹配的索引模板，数据流就无法 roll over 或创建后备索引。

注意事项

• 如果你恢复数据流，则会同时恢复其后备索引
• 如果从快照中恢复集群存在的索引，则它必须处于closed状态且快照中的索引主分片数需要与其相同
• 你无法恢复现有的open状态的索引，包括数据流的后备索引
• 恢复操作会自动打开恢复的索引，包括后备索引
• 你只能从数据流中恢复特定的后备索引。但是，还原操作不会将还原的后备索引添加到任何现有数据流中

获取可用快照列表

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

GET _snapshot

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

GET _snapshot/my_repository/*?verbose=false

恢复索引或者数据流

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

• 删除后恢复
• 重命名恢复的索引

删除后恢复

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

# Delete an index
DELETE my-index

# Delete a data stream
DELETE _data_stream/logs-my_app-default

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

POST _snapshot/my_repository/my_snapshot_2099.05.06/_restore
{
  "indices": "my-index,logs-my_app-default"
}

重命名恢复的索引

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

POST _snapshot/my_repository/my_snapshot_2099.05.06/_restore
{
  "indices": "my-index,logs-my_app-default",
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1"
}

如果重命名选项产生两个或更多具有相同名称的索引或数据流，则恢复操作将失败。
如果你重命名一个数据流，它的后备索引也会被重命名。例如，如果将 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 来重命名恢复的索引。

# Delete the original index
DELETE my-index

# Reindex the restored index to rename it
POST _reindex
{
  "source": {
    "index": "restored-my-index"
  },
  "dest": {
    "index": "my-index"
  }
}

# Delete the original data stream
DELETE _data_stream/logs-my_app-default

# Reindex the restored data stream to rename it
POST _reindex
{
  "source": {
    "index": "restored-logs-my_app-default"
  },
  "dest": {
    "index": "logs-my_app-default",
    "op_type": "create"
  }
}

恢复功能状态

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

GET _snapshot/my_repository/my_snapshot_2099.05.06

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

POST _snapshot/my_repository/my_snapshot_2099.05.06/_restore
{
  "feature_states": [ "geoip" ]
}

恢复整个集群

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

监控恢复

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

GET _cluster/health

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

GET my-index/_recovery

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

GET _cat/shards?v=true&h=index,shard,prirep,state,node,unassigned.reason&s=state

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

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": false,
  "current_node": "my-node"
}

取消恢复

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

# Delete an index
DELETE my-index

# Delete a data stream
DELETE _data_stream/logs-my_app-default

恢复到其他集群

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

• 添加数据节点或者升级硬件
• 恢复较少的索引和数据流
• 减少恢复索引的副本数量，如下操作：

  POST _snapshot/my_repository/my_snapshot_2099.05.06/_restore
  {
    "indices": "my-index,logs-my_app-default",
    "index_settings": {
      "index.number_of_replicas": 1
    }
  }
  

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

Troubleshoot

• Cannot restore index [] because an open index with same name already exists in the cluster
  删除现有索引或重命名快照内要恢复的索引
• Cannot restore index [] with [x] shards from a snapshot of index [] with [y] shards
  只可以恢复现有索引已关闭且快照中的索引具有相同数量的主分片的索引。此错误表示快照中的索引具有不同数量的主分片。尝试删除现有索引或重命名快照内要恢复的索引。