Elasticsearch 通常用作日志和其他类型数据的数据存储。因此，如果您存储有价值的数据，那么您还需要工具来备份和恢复这些数据以支持灾难恢复。
在早期版本的 Elasticsearch 中，唯一可行的解决方案是通过完整扫描转储数据，然后重新编制索引。随着 Elasticsearch 成熟为一个完整的产品，它支持原生功能来备份和恢复数据。
在本章中，我们将探讨如何使用 网络文件系统 (NFS) 配置共享存储。 用于存储备份，以及如何执行和恢复备份。
在本章的最后一个秘籍中，我们将演示如何使用重新索引功能在不同的 Elasticsearch 集群之间克隆数据。如果由于从旧 Elasticsearch 版本迁移到新版本而无法使用标准备份或恢复功能，这种方法非常有用。
在本章中，我们将介绍以下食谱：
Elasticsearch 提供了一个内置系统来快速备份和恢复您的数据。在处理实时数据时，由于存在大量并发问题，因此保持备份很复杂。
Elasticsearch 快照允许您在远程存储库中创建单个索引（或别名）或整个集群的快照。
在开始执行快照之前，必须创建一个存储库——这是您的备份或快照将被存储的地方。
您将需要一个正常运行的 Elasticsearch 安装 - 类似于我们在 the 下载和安装 Elasticsearch 配方在 第 1 章， < em>开始。
为了执行命令，可以使用任何 HTTP 客户端，例如 Curl (https://curl.haxx.se/)或邮递员 (https://www.getpostman.com/)。您可以使用 Kibana 控制台，因为它为 Elasticsearch 提供了代码完成和更好的字符转义。
我们需要编辑 config/elasticsearch.yml 并添加备份存储库的目录 - path.repo: /backup/。
通常，在生产集群中， /backup 目录应该是共享存储库。
要管理存储库，我们将执行以下步骤：
结果如下：
如果您检查您的文件系统，/backup/my_repository 目录将按如下方式创建：
结果如下：
结果如下：
在对我们的数据进行快照之前，我们必须创建一个存储库——即我们可以存储备份数据的地方。可用于创建存储库的参数如下：
在 fs类型使用的情况下，设置如下：
存储库后端最常见的类型是 filesystem，但也有其他官方存储库后端，例如：
创建存储库后，会立即在所有数据节点上对其进行验证，以确保其正常运行。
Elasticsearch 还提供了一种手动方式来验证节点状态存储库，这对于检查云存储库存储的状态非常有用。手动验证存储库的命令如下：
在前面的秘籍中，我们定义了一个存储库——也就是我们将存储备份的地方。现在我们可以在命令被调用的那一刻创建索引的快照（使用索引的完整备份）。
对于每个存储库，都可以定义多个快照。
您将需要一个正常运行的 Elasticsearch 安装 - 类似于我们在 下载和安装 Elasticsearch 中描述的安装配方在 第 1 章,< /span> 开始。
要执行这些命令，可以使用任何 HTTP 客户端，例如 Curl (https://curl.haxx.se/) 或 Postman （https://www.getpostman.com/）。您可以使用 Kibana 控制台，因为它为 Elasticsearch 提供了代码完成和更好的字符转义。
要正确执行以下命令，需要在上一个秘籍中创建的存储库。
要管理快照，我们将执行以下步骤：
结果如下：
结果将与上一步相同。
结果如下：
创建快照所需的最低配置是存储库的名称和快照的名称（即 snap_1）。
如果没有设置其他参数，则快照命令将转储所有集群数据。要控制快照过程，可以使用以下参数：
wait_for_completion 查询参数 允许您在返回调用之前等待快照结束。如果您想自动化您的快照脚本以顺序备份索引，这将非常有用。
如果未设置 wait_for_completion 参数，则为了检查快照状态，用户必须使用快照 GET 调用对其进行监控。
快照是增量的；这意味着仅在同一索引的两个快照之间复制更改的文件。这种方法减少了快照期间的时间和磁盘使用量。
快照过程被设计为尽可能快，因此它实现了存储库中 Lucene 索引段的直接副本。为了防止在复制过程中可能发生的更改和索引损坏，所有需要复制的段都被阻止更改，直到快照结束。
Elasticsearch 会处理快照期间的所有事情，包括防止将数据写入快照过程中的文件，以及管理集群事件（例如分片重定位、故障等）。
要检索存储库的所有可用快照，命令如下：
可以使用 _status 端点监控快照过程，该端点提供快照状态的完整概览。
对于当前示例，快照 _status API 调用如下：
结果很长，由以下部分组成：
状态响应非常丰富，也可以用来估计快照的性能和增量备份及时需要的大小。
一旦您拥有数据的快照，就可以将其还原。恢复过程非常快——索引分片数据只需复制到节点上并激活。
您将需要一个正常运行的 Elasticsearch 安装——类似于我们在 下载和安装 Elasticsearch 中描述的安装第 1 章中的配方， 开始。
要执行这些命令，可以使用任何 HTTP 客户端，例如 Curl (https://curl.haxx.se/) 或 Postman （https://www.getpostman.com/）。您可以使用 Kibana 控制台，因为它为 Elasticsearch 提供了代码完成和更好的字符转义。
为了正确执行以下命令，需要在上一个秘籍中创建的备份。
要恢复快照，我们将执行以下步骤：
结果如下：
在此示例中， "mybooks-*" 索引模式 匹配 mybooks-join。 rename_pattern 参数捕获 "join"，新索引会通过rename_placement "copy -join".
恢复过程非常快；该过程包括以下步骤：
可以使用一些参数来控制恢复过程，如下所示：
管理存储库（存储数据的地方）是 Elasticsearch 备份管理中最关键的部分。由于其原生分布式架构，快照和还原设计为集群样式。
在快照期间，分片被复制到定义的存储库。如果此存储库是节点本地的，则备份数据分布在所有节点上。出于这个原因，如果您有一个多节点集群，则必须拥有共享存储库存储。
一种常见的方法是使用 NFS，因为它很容易设置并且是一种非常快速的解决方案（此外，可以使用标准的 Windows Samba 共享。）
我们有一个包含以下节点的网络：
您将需要一个正常运行的 Elasticsearch 安装 - 类似于我们在 下载和安装 Elasticsearch 中描述的安装第 1 章中的配方， 开始。
为了执行命令，可以使用任何 HTTP 客户端，例如 curl (https://curl.haxx.se/)或邮递员 (https://www.getpostman.com/)。您可以使用 Kibana 控制台，因为它为 Elasticsearch 提供了代码完成和更好的字符转义。
以下说明适用于标准 Debian 或 Ubuntu 发行版；它们可以很容易地针对另一个 Linux 发行版进行更改。
要创建 NFS 共享存储库，我们需要在 NFS 服务器上执行以下步骤：
NFS 服务器启动并运行后，我们需要配置客户端。我们将在每个 Elasticsearch 节点上重复以下步骤：
NFS 是一种分布式文件系统协议，在 Unix 世界中非常常见——它允许您在服务器上挂载远程目录。挂载的目录看起来像服务器的本地目录，因此，通过使用 NFS，多个服务器可以写入同一个目录。
如果您需要进行共享备份，这非常方便；这是因为所有节点都将从同一个共享目录写入/读取。
快照和恢复 API 非常快，是备份数据的首选方式，但它们也有一些限制：
为了能够在这种情况下复制数据，解决方案是使用远程服务器使用重新索引 API。
您将需要一个正常运行的 Elasticsearch 安装 - 类似于我们在 下载和安装 Elasticsearch 中描述的安装第 1 章中的配方， 开始。
为了执行命令，可以使用任何 HTTP 客户端，例如 curl (https://curl.haxx.se/)或邮递员 (https://www.getpostman.com/)。您可以使用 Kibana 控制台，因为它为 Elasticsearch 提供了代码完成和更好的字符转义。
要从远程服务器复制索引，我们需要执行以下步骤：
结果将类似于我们已经在 重新索引索引 配方中看到的本地重新索引>第 3 章，基本操作。
重新索引 API 允许您调用远程集群。支持 Elasticsearch 服务器的每个版本（主要是 1.x 或更高版本）。
reindex API 对远程索引集群执行扫描查询，并将数据放入当前集群。此过程可能需要很长时间，具体取决于需要复制的数据量以及索引数据所需的时间。
源部分包含控制获取数据的重要参数，例如：
配置的 remote 部分由以下参数组成：
在标准快照和还原上使用这种方法有很多优点，包括：