官方文档-恢复快照

Posted 2023-03-18

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

elasticsearch 快照和恢复

首先，这是官方介绍：

https://www.elastic.co/guide/en/elasticsearch/reference/5.5/modules-snapshots.html#_snapshot

第一步：先创建一个快照仓库，使用API创建

PUT /_snapshot/esbackup
{
  "type":"fs"
  , "settings": {
    "location": "/data/backup"
  }
}

返回结果
{
  "acknowledged": true
}

当然，没那么简单，/data/backup,这个目录不是随便指定得，需要在elasticsearch.yml 配置文件里面指定，不然会报500错误

path.repo: /data/backup

创建成功后我们可以查看一下这个仓库信息

GET _snapshot/esbackup

{
  "esbackup": {
    "type": "fs",
    "settings": {
      "location": "/data/backup"
    }
  }
}

第二步：备份

PUT _snapshot/esbackup/b20170824

b20170824是备份名字

一个仓库可以存储多个备份，比如再备份一个

PUT _snapshot/esbackup/b20170825

查看备份

GET _snapshot/esbackup/b20170824

{
  "snapshots": [
    {
      "snapshot": "b20170824",
      "uuid": "sajgUSp0RHClo7JvSxrMjQ",
      "version_id": 5020299,
      "version": "5.2.2",
      "indices": [
        "logstash-2017.05.08",
        "megacorp",
        "logstash-2017.07.26",
        "test_index",
        ".kibana",
        "logstash-2017.05.04",
        ".monitoring-es-2-2017.08.17",
        ".monitoring-es-2-2017.08.22",
        ".monitoring-data-2",
        "oeeee-2017.04.29",
        "logstash-2017.05.06",
        "my_index",
        "logstash-2017.05.09",
        ".monitoring-es-2-2017.08.19",
        ".monitoring-es-2-2017.08.21",
        "logstash-2017.04.23",
        "kcis_user",
        "logstash-2017.04.21",
        "logstash-2017.05.05",
        ".monitoring-es-2-2017.08.23",
        "logstash-2017.05.14",
        ".monitoring-es-2-2017.08.18",
        "my_index3",
        "logstash-2017.05.13",
        "logstash-2017.05.11",
        "daily-tag-2017.07.11",
        "tag_profile",
        "logstash-2017.05.02",
        ".monitoring-es-2-2017.08.24",
        "logstash-2017.05.03",
        "logstash-2017.05.12",
        "logstash-2017.04.22",
        ".monitoring-es-2-2017.08.20",
        "user_profile_v1",
        "logstash-2017.05.10",
        "logstash-2017.05.07",
        "website",
        "my_index2"
      ],
      "state": "IN_PROGRESS",
      "start_time": "2017-08-24T07:10:45.148Z",
      "start_time_in_millis": 1503558645148,
      "failures": [],
      "shards": {
        "total": 0,
        "failed": 0,
        "successful": 0
      }
    }
  ]
}

第三步：还原

还原指定索引

POST _snapshot/esbackup/b20170825/_restore
{
  "indices":"logstash-2017.05.13"
}

还原所有索引

POST _snapshot/esbackup/b20170825/_restore

本文出自 “飞一般的爱情故事” 博客，请务必保留此出处http://niubdada.blog.51cto.com/3511133/1959065