ES备份恢复

@[toc]

  Elasticsearch 副本提供了高可靠性；可以容忍部分的节点丢失而不会中断服务。但是副本并不提供对灾难性故障的保护。对这种情况，则是需要备份来进行处理。  备份Elasticsearch集群可以使用 snapshot API。该API会拿到集群里当前的状态和数据然后保存到一个共享仓库里。这个备份过程是"智能"的。第一个快照会是一个数据的完整拷贝，但是所有后续的快照会保留的是已存快照和新数据之间的差异。随着不时的对数据进行快照，备份也在增量的添加和删除。这意味着后续备份会相当快速，因为它们只传输很小的数据量。

  每个快照可以包含在各种版本的Elasticsearch中创建的索引，并且在还原快照时，必须有可能将所有索引还原到目标集群中。如果快照中的任何索引是在不兼容的版本中创建的，则将无法还原快照。

  要使用这个功能，必须先创建一个保存数据的仓库。有多个仓库类型可以选择：

在升级之前备份数据时，如果快照包含在与升级版本不兼容的版本中创建的索引，则升级后将无法还原快照。如果最终遇到需要还原与当前运行的集群版本不兼容的索引快照的情况，则可以将其还原到最新的兼容版本上，然后使用 reindex-from-remote重建索引。

部署一个共享文件系统仓库：

注意：共享文件系统路径必须确保集群所有节点都可以访问到  这步会在挂载点创建仓库和所需的元数据。还有一些其他的配置可能想要配置的，这些取决于节点、网络的性能状况和仓库位置.

  一个仓库可以包含多个快照。每个快照跟一系列索引相关（比如所有索引，一部分索引，或者单个索引），快照要有一个唯一的名字。

  通常快照作为后台进程运行，不过有时候要等快照创建完成之后再返回，可以通过添加一个 wait_for_completion 标记实现，但是要注意kibana的超时限制。参数 wait_for_completion 决定请求是在快照初始化后立即返回（默认），还是等快照创建完成之后再返回。快照初始化时，所有之前的快照信息会被加载到内存，所以在一个大的仓库中改请求需要若干秒（甚至分钟）才能返回，即使参数 wait_for_completion 的值设置为 false。

  默认行为是备份所有打开的索引。但是如果需要备份部分索引，可以在快照集群的时候指定备份哪些索引：

  要获得单个快照的信息，直接对仓库和快照名发起一个 GET 请求：

  要获取一个仓库中所有快照的完整列表，使用 _all 占位符替换掉具体的快照名称：

  wait_for_completion 标记提供了一个监控的基础形式，但哪怕只是对一个中等规模的集群做快照恢复的时候，它都真的不够用。  另外两个 API 会给有关快照状态更详细的信息。首先可以给快照 ID 执行一个 GET：

  如果调用这个命令的时候快照还在进行中，会看到它什么时候开始，运行了多久等等信息。不过要注意，这个 API 用的是快照机制相同的线程池。如果在快照非常大的分片，状态更新的间隔会很大，因为 API 在竞争相同的线程池资源。

更好的方案是拉取 _status API 数据：

  响应包括快照的总体状况，但也包括下钻到每个索引和每个分片的统计值。这个给展示了有关快照进展的非常详细的视图。分片可以在不同的完成状态：

  最后，我们需要一个命令来删除所有不再有用的旧快照。这只要对仓库/快照名称发一个简单的 DELETE HTTP 调用：

  用 API 删除快照很重要，而不能用其他机制（比如手动删除，或者用AWS S3上的自动清除工具）。因为快照是增量的，有可能很多快照依赖于过去的段。delete API 知道哪些数据还在被更多近期快照使用，然后会只删除不再被使用的段。

  但是，如果做了一次人工文件删除，将会面临备份严重损坏的风险，因为在删除的是可能还在使用中的数据。

  要取消一个快照，在他进行中的时候删除快照即可

  从仓库删除任何快照时，将自动执行此端点执行的大多数清理操作。如果定期删除快照，则在大多数情况下，使用此功能将无法节省任何空间或仅节省很少的空间，因此应相应地降低其调用频率。

  删除仓库后，Elasticsearch仅删除对该仓库存储快照的位置的引用。快照本身保持不变。

  ES恢复很简单，只要在恢复回集群的快照 ID后面加上 _restore 即可：

  默认行为是把这个快照里存有的所有索引都恢复。如果 snapshot_1 包括五个索引，这五个都会被恢复到我们集群里。和 snapshot API 一样，我们也可以选择希望恢复具体哪个索引。  还有附加的选项用来重命名索引。这个选项允许通过模式匹配索引名称，然后通过恢复进程提供一个新名称。如果想在不替换现有数据的前提下，恢复老数据来验证内容，或者做其他处理，这个选项很有用。让我们从快照里恢复单个索引并提供一个替换的名称：

  这个会恢复 index_1 到集群里，但是重命名成了 restored_index_1 。

  和快照类似， restore 命令也会立刻返回，恢复进程会在后台进行。如果更希望 HTTP 调用阻塞直到恢复完成，添加 wait_for_completion 标记：

  从仓库恢复数据借鉴了 Elasticsearch 里已有的现行恢复机制。在内部实现上，从仓库恢复分片和从另一个节点恢复是等价的。  如果想监控恢复的进度，可以使用 recovery API。这是一个通用目的的 API，用来展示集群中移动着的分片状态。  这个 API 可以为在恢复的指定索引单独调用

  或者查看集群里所有索引，可能包括跟恢复进程无关的其他分片移动：

输出会跟这个类似（注意，根据集群的活跃度，输出可能会非常多）：

  要取消一个恢复，需要删除正在恢复的索引。因为恢复进程其实就是分片恢复，发送一个 删除索引 API 修改集群状态，就可以停止恢复进程。比如：

  如果 restored_name 正在恢复中，这个删除命令会停止恢复，同时删除所有已经恢复到集群里的数据。

  许多备份和恢复操作受集群和索引块的影响。例如，创建和删除仓库需要写入全局元数据访问。备份操作要求所有索引及其元数据以及全局元数据均可读。恢复操作要求全局元数据可写，但是在恢复过程中会忽略索引级别块，因为索引实际上是在还原过程中重新创建的。仓库内容不是集群的一部分，因此集群块不会影响内部仓库操作。