翻译自官网， 水平有限，用于自查。转载请注明网址: http://www.jianshu.com/p/f53ce0db0da7

仓库

在任何快照或还原操作能够进行之前，应该注册一个快照仓库到Elasticsearch。
仓库设置是特殊的仓库类型(repository-type)，如下：

PUT /_snapshot/my_backup
{
  "type": "fs",
  "settings": {
        ... repository specific settings ...
  }
}

一旦一个仓库被注册，它的信息(information)可以使用如下命令获取：

GET /_snapshot/my_backup

命令返回：

{
  "my_backup": {
    "type": "fs",
    "settings": {
      "compress": true,
      "location": "/mount/backups/my_backup"
    }
  }
}

多个仓库的信息可以使用一个逗号隔开的列表一次获取。可以使用星号通配符(*)，
例如，由repo开始或包含backup的仓库信息可以使用如下命令获取：

GET /_snapshot/repo*,*backup*

若非指定仓库名称，或者使用_all，Elasticsearch会返回集群中所有当前已注册的仓库信息：

GET /_snapshot

或者：

GET /_snapshot/_all

共享文件系统仓库

共享文件系统仓库("type":"fs")使用共享文件系统存储快照。
为了注册共享文件系统仓库，有必要在每一台主节点和数据节点上，将相同的共享文件系统挂载到相同location。
这个location(或者一个它的父文件夹)必须在每一台主节点和数据节点的配置中，注册在path.repo设置里。

假设这个共享文件系统仓库挂载在/mount/backups/my_backup， 如下设置需要加到elasticsearch.yml文件里：

path.repo: ["/mount/backups", "/mount/longterm_backups"]

path.repo设置支持Microsoft Windows UNC路径，只要至少服务器名称和共享被指定为前缀，并正确地转义回斜杠

path.repo: ["\\\\MY_SERVER\\Snapshots"]

所有节点重启后，如下命令可以用于注册名为my_backup的共享文件系统仓库：

PUT /_snapshot/my_backup 
{
    "type": "fs",
    "settings": {
        "location": "/mount/backups/my_backup",
        "compress": true
    }
}

如果这个仓库location使用了相对路径，则会使用path.repo中的一级路径：

PUT /_snapshot/my_backup
{
    "type": "fs",
    "settings": {
        "location": "my_backup",
        "compress": true
    }
}

支持如下设置：

只读URL仓库

URL仓库("type":"url") 可以用作以只读方式从共享文件系统仓库中获取数据的一种方案。
url参数需要指定共享文件系统仓库的根路径。
支持如下设置：

URL仓库支持如下协议： "http", "https", "ftp", "file" 和 "jar"
使用"http:", "https:" 和 "ftp:" 必须要在repositories.url.allowed_urls设置白名单，主机名，路径，查询和片段支持使用通配符，例如：

repositories.url.allowed_urls: ["http://www.example.org/root/*", "https://*.mydomain.com/*?*#*"]

使用"file:"类似于使用共享文件系统仓库，URL指定到注册在path.repo中的位置。

仓库插件

通过如下官方插件，可以使用其他后端仓库：

• repository-s3
• repository-hdfs
• repository-azure
• repository-gcs

仓库认证

当一个仓库被注册，它立即在所有主节点和数据节点上进行验证，以确保它在集群中的所有节点上都具有功能性。
当注册或升级仓库时， verify参数可以用于明确地禁用仓库验证：

PUT /_snapshot/s3_repository?verify=false
{
  "type": "s3",
  "settings": {
    "bucket": "my_s3_bucket",
    "region": "eu-west-1"
  }
}

验证进程也可以使用如下命令手动执行：

POST /_snapshot/s3_repository/_verify

如果验证成功，命令返回一个节点列表。否则返回错误信息。

快照

一个仓库可以包含同一个集群的多个快照， 快照在集群中由唯一的命名标识。
一个命名为snapshot_1的快照可以执行如下命令创建到my_backup仓库中：

PUT /_snapshot/my_backup/snapshot_1?wait_for_completion=true

wait_for_completion 参数指定了请求在快照初始化结束后立即返回还是等待创建结束。
在快照初始化期间，之前所有快照的信息读入内存，
这意味着即使设置wait_for_completion为false，在巨型仓库中会花费数秒(甚至几分钟)

默认情况下会创建一个所有打开且启动着的索引的快照
这种行为可以通过快照请求体中的一个特殊的索引列表来改变

PUT /_snapshot/my_backup/snapshot_1
{
  "indices": "index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": false
}

应该包含在快照中的索引列表可以用indices参数指定且支持multi index syntax .
快照请求同样支持ignore_unavailable选项.
如果设置为true, 在快照创建时会忽略不存在的索引，
而默认情况下，不设定ignore_unavailable选项时， 一个索引丢失会导致快照请求失败。

设定include_global_state为false可以防止集群全局状态被存储为快照的一部分。

默认情况下，如果一个或个多快照中的索引并非全部主分片可用，整个快照请求会失败。
这种行为可以通过设置partial为true来避免。

索引快照进程是增量的。在制作索引快照进程中，Elasticsearch分析早已存储在仓库中的索引文件列表并仅仅拷贝自上一次快照以来被创建或改变的文件。多个快照可以以紧凑格式存储在仓库中。快照进程以非阻塞方式执行，所有索引和搜索操作可以继续在正在进行快照的索引上执行。然而，一个快照意味着索引在快照创建的时间点的情况，所以那些在快照进程启动后增加索引的记录不会加入到快照中。
对于已经启动并且此时不在重分配(relocating)的主分片，快照进程立即启动。1.2.0版本以前，如果任何加入到快照中的索引的主分片正在重分或者初始化，快照操作都会失败。自1.2.0版本以后，Elasticsearch等待分片重分或初始化完成。

除了创建每个索引的副本，快照进程也能存储那些全局的、包含了持久化的集群设置和模板的元数据。临时的设置和注册的快照仓库不会存储为快照的一部分。

任一时间集群中只有一个快照进程可以被执行。当一个会干涉再平衡(rebalancing)进程和分配过滤的特定分片的快照正在被创建时，这个分片无法被移动到另一个节点。
Elasticsearch只允许移动一个分片到另一个节点。(根据当前的分配过滤设置和再平衡算法)

一旦一个快照被创建，关于这个快照的信息可以用如下命令获得：

GET /_snapshot/my_backup/snapshot_1

类似于仓库，关于多个快照的信息可以一次查询，支持通配符如下：

GET /_snapshot/my_backup/snapshot_*,some_other_snapshot

所有当前存储在仓库的快照可以用如下命令列出：

GET /_snapshot/my_backup/_all

如果一些快照不可用，命令将失败，ignore_unavailable可以用于返回所有当前可用的快照

一个当前运行的快照可以用如下命令获取：

GET /_snapshot/my_backup/_current"

可以用如下命令从仓库中删除一个快照:

DELETE /_snapshot/my_backup/snapshot_1

当一个快照被从仓库中删除，Elasticsearch删除所有与被删除快照相关联，并且没有被其他快照使用的文件。
如果在快照正在创建时执行删除快照操作，快照进程会失败，所有快照进程创建的文件将会被清理。因此，删除快照操作可以用于撤销错误启动的长时间运行的快照操作。

可以使用如下操作删除一个仓库：

DELETE /_snapshot/my_backup

还原

一个快照可使用如下命令恢复：

POST /_snapshot/my_backup/snapshot_1/_restore

默认情况下，快照中的所有索引还原了，且集群状态没有还原。可以选择应该还原的索引，并可以在还原请求体中使用index和include_global_state选项来还原全局集群状态。索引列表支持multi index syntax

rename_pattern和rename_replacement选项还可以使用正则表达式来重命名还原的索引。该表达式支持引用原始文本。将include_aliases设置为false，防止别名与关联索引一起被还原。

POST /_snapshot/my_backup/snapshot_1/_restore
{
  "indices": "index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": true,
  "rename_pattern": "index_(.+)",
  "rename_replacement": "restored_index_$1"
}

还原操作可以在一个正常运作的集群上执行。然而，一个现有的索引只有在关闭时才能还原，并且分片数与快照中的索引相同。如果索引是关闭的，还原操作会自动打开它， 如果索引不存在，会自动创建。如果集群状态因include_global_state而还原（默认false），当前集群中不存在的模板会被添加，重名的模板会被替换。还原的持久化设置会被添加到现有的持久化设置中。

局部还原

默认情况下，如果一个或多个操作中的索引没有全部可用分片的快照，整个还原操作都会失败。例如，若某些分片未能获得快照，就会发生这样的情况。通过设置partial为true，仍有可能还原这样的索引。请注意，这样的情况下，只有成功的快照会被还原， 所有丢失的分片会被重新创建为空。

在还原过程中更改索引设置

大多数的索引设置可以在还原过程覆盖。例如如下命令将在不创建任何副本的情况下还原index_1索引，同时切换回默认的刷新间隔：

POST /_snapshot/my_backup/snapshot_1/_restore
{
  "indices": "index_1",
  "index_settings": {
    "index.number_of_replicas": 0
  },
  "ignore_index_settings": [
    "index.refresh_interval"
  ]
}

请注意，一些设置像index.number_of_shards无法在还原操作期间被改变。

还原到不同的集群

暂时用不上, 戳这儿看原版

快照状态

可以使用下面的命令获取当前运行的快照列表，这些快照具有详细的状态信息：

GET /_snapshot/_status

在这种格式中，命令会返回所有当前运行快照的信息。通过指定仓库名称，可以将结果指定到特定的仓库。

GET /_snapshot/my_backup/_status

如果同时指定仓库名称和快照，这个命令会对给定的快照返回详细的状态信息即使它并非当前运行：

GET /_snapshot/my_backup/snapshot_1/_status

同样支持多id：

GET /_snapshot/my_backup/snapshot_1,snapshot_2/_status

监控快照/还原进程

有几种办法可以监控快照和还原进程在其运行的过程中。
两种操作都支持wait_for_completion参数， 阻塞客户端直到操作结束。
这是一个可以用来获取操作结束通知的简单方式。

快照操作也可以通过周期性调用快照信息来监控：

GET /_snapshot/my_backup/snapshot_1

请注意，快照信息操作和快照操作使用相同的资源和线程池。
因此，在大型分片正在快照时执行快照信息操作，可能会导致快照信息操作在返回结果之前等待可用的资源。
在非常大的分片上，这个等待时间是值得关注的。

为了获取关于快照更直接更完整的信息，可以使用快照状态命令：

GET /_snapshot/my_backup/snapshot_1/_status

快照信息方法仅仅返回关于正在进行的快照的基本信息，快照状态将返回加入到快照中的每个分片的当前信息的完整分解。

还原过程基于Elasticsearch的标准还原机制。因此，可以使用标准的还原监视服务来监控还原状态。当还原操作执行时，集群通常会进入red状态，这是因为还原操作从还原索引的主分片开始。在这个操作过程中，主分片不可用，表现为集群状态为red。一旦主分片还原完成，Elasticsearch将切换到标准复制过程创建所需数量的副本，此时集群状态为yellow。一旦所有所需副本创建完成，集群切换回green状态。

集群健康操作仅提供还原过程的高级别状态。可以通过indices recovery和cat recovery API来更加详细地了解还原的过程。

停止当前运行的快照和还原操作

快照和还原框架在同一时间只允许一个快照或还原操作运行。如果当前运行的快照错误的被执行，或者时间非常长，可以使用快照删除操作来终止它。快照删除操作检查要删除的快照是否正在运行，如果是，快照删除操作会先停止快照进程，再从仓库中将它删除。

DELETE /_snapshot/my_backup/snapshot_1

还原操作使用标准分片还原机制，任何正在运行的还原操作都可以通过删除正在还原的索引来取消。
请注意，由于此操作，所有此索引的数据会全部从集群中被删除。

集群阻塞对快照和还原操作的影响

许多快照和还原操作受到集群和索引阻塞的影响。例如注册和注销仓库需要编写全局元数据访问。快照操作要求所有索引和全局元数据都是可读的，还原操作要求全局元数据是可写的。但是在还原期间，索引级别的阻塞会被忽略，因为索引基本上是在还原期间创建的。请注意，仓库内容不是集群的一部分，所以集群阻塞不会影响到仓库内部操作如从已注册的仓库中列出或者删除快照。