Elasticsearch集群的数据备份

备份集群
随着存储数据软件的发展，常规性的备份数据越来越重要。Elasticsearch的replicas提供了运行时的高可用性；在服务不中断的情况下，允许不定时的节点宕机。
然而，Repalicas并不提供针对灾难性失败的保护。因此，你需要实时的备份你的集群–一份完整的拷贝，以备不时之需。
备份集群，你需要用到snapshot API.它会将集群当前的状态和数据保存到共享库中。这种备份的过程是“smart”。你的第一个快照将是完整的数据副本，后续的快照将保存现有的快照和新数据之间的增量。随着时间的推移，数据将逐步添加和删除，这意味着后续备份将大大加快，因为它们传输的数据少的多。
要想使用该功能，你首先需要创建一个仓库来保存数据，有以下几种可选择的仓库类型。
 Shared filesystem, such as a NAS
 Amazon S3
 HDFS (Hadoop Distributed File System)
 Azure Cloud

创建仓库
让我们创建一个共享文件系统仓库：
PUT _snapshot/my_backup
{
“type”: “fs”,
“settings”: {
“location”: “/mount/backups/my_backup”
}
}

提供仓库名，在这里我们叫做my_backup具体挂载一种共享文件系统的数据仓库类型最后，我们提供一个目标路径地址注意：共享文件系统路径必须能够被集群中的所有节点访问。

这将会在挂载点中创建仓库和所需元数据。你还可以设置其他选项，取决于节点、网络和仓库位置的性能配置文件。
max_snapshot_bytes_per_sec
该项用于设置快照数据进入仓库的流速，默认是20M每秒。
max_restore_bytes_per_sec
当从仓库恢复数据的时候，该项用于控制恢复的数据流速，为的是让网络不饱和。默认是20M每秒。

假设我们有快速的网络，可以处理额外的流量，我们可以增加一下默认值。

POST _snapshot/my_backup/
{
“type”: “fs”,
“settings”: {
“location”: “/mount/backups/my_backup”,
“max_snapshot_bytes_per_sec” : “50mb”,
“max_restore_bytes_per_sec” : “50mb”
}
}
注意：我们使用POST代替PUT,将会更新存在的设置。
然后增加我们的settings。

快照所有的索引

仓库可能包含多个快照。每个快照可能包含特定数量索引（例如，所有的，几个，或者一个）。当创建仓库时，需要指定快照哪些索引，并给快照一个名称。

最基本的快照命令：
PUT _snapshot/my_backup/snapshot_1

这将会备份所有的索引到my_backup库中，名称叫snapshot_1的快照中。这次请求会很快返回，快照进程会在后台执行。

建议：通常你会想让你的快照进程作为后台进程，但是偶尔你也想在你的脚本中等待完成，你可以增加wait_for_completion 标志。
PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true
这次请求将会阻塞，直到快照完成，因此大数据量的快照可能会等很长时间。

快照特定索引

默认行为是快照着所有开放的索引。但是你可能使用了Marvel，不想快照以.marvel结尾的索引，又或者说你没有足够的空间来备份所有的索引。

这种情况下，当快照你的集群的时候，你可以指定特定的索引名称。
PUT _snapshot/my_backup/snapshot_2
{
“indices”: “index_1,index_2”
}
这次快照将只会快照index_1,index_2两个索引。

查看快照相关的信息
一旦你逐渐积累仓库中的快照，或许你会忘记特定快照的相关信息，尤其是当快照名称命名是基于时间界限的（例如，backup_2014_10_28）。

为了获取单个快照的信息，仅仅通过GET请求并带上具体的仓库名称和快照名称即可。
GET _snapshot/my_backup/snapshot_2
它将会返回与该快照相关的简要信息。
{
“snapshots”: [
{
“snapshot”: “snapshot_1”,
“indices”: [
“.marvel_2014_28_10”,
“index1”,
“index2”
],
“state”: “SUCCESS”,
“start_time”: “2014-09-02T13:01:43.115Z”,
“start_time_in_millis”: 1409662903115,
“end_time”: “2014-09-02T13:01:43.439Z”,
“end_time_in_millis”: 1409662903439,
“duration_in_millis”: 324,
“failures”: [],
“shards”: {
“total”: 10,
“failed”: 0,
“successful”: 10
}
}
]
}
如果你想获取仓库中所有的快照，使用_all来代替快照名称。
GET _snapshot/my_backup/_all

删除快照
最后，我们需要通过命令来删除已经不再使用得旧的快照。通过DELETE 的HTTP请求，来调用对应的仓库/快照名称。
DELETE _snapshot/my_backup/snapshot_2
使用API来删除快照是极其重要的，因为没有其它机制。快照是增量的，可能很多的快照依赖于旧的部分。Delete API能够理解那些数据在最近的快照中使用，并且删除旧的部分。
然而，如果你手动删除文件，会存在中断备份的风险，因为你删除了正在使用的数据。

监控快照过程
Wait_for_completion标志提供了基本的监控信息，但是对于快照或者恢复集群，显然是不够的。

另外两个API将会给出更多的关于快照状态的信息。首先你应当通过GET请求获取快照ID，正如我们之前获取信息所做的一样。
GET _snapshot/my_backup/snapshot_3
如果当你请求的时候，快照进程正在运行，你将会看到快照什么时候开始的、已经运行了多久等信息。注意，这个API和快照使用的是同一个线程池。如果快照大的分片时，更新的时间可能会很长，因为二者会竞争线程池的资源。

一个更好的API选择：
GET _snapshot/my_backup/snapshot_3/_status
_status能够立即返回并给出更多的统计信息：

{
“snapshots”: [
{
“snapshot”: “snapshot_3”,
“repository”: “my_backup”,
“state”: “IN_PROGRESS”,
“shards_stats”: {
“initializing”: 0,
“started”: 1,
“finalizing”: 0,
“done”: 4,
“failed”: 0,
“total”: 5
},
“stats”: {
“number_of_files”: 5,
“processed_files”: 5,
“total_size_in_bytes”: 1792,
“processed_size_in_bytes”: 1792,
“start_time_in_millis”: 1409663054859,
“time_in_millis”: 64
},
“indices”: {
“index_3”: {
“shards_stats”: {
“initializing”: 0,
“started”: 0,
“finalizing”: 0,
“done”: 5,
“failed”: 0,
“total”: 5
},
“stats”: {
“number_of_files”: 5,
“processed_files”: 5,
“total_size_in_bytes”: 1792,
“processed_size_in_bytes”: 1792,
“start_time_in_millis”: 1409663054859,
“time_in_millis”: 64
},
“shards”: {
“0”: {
“stage”: “DONE”,
“stats”: {
“number_of_files”: 1,
“processed_files”: 1,
“total_size_in_bytes”: 514,
“processed_size_in_bytes”: 514,
“start_time_in_millis”: 1409663054862,
“time_in_millis”: 22
}
},
…
一个快照正在缓慢运行，正如它的状态显示的那样 ：IN_PROGRESS
这个快照仍有一个分片在传输数据(其它四个已经完成)。

响应包括快照的整体状态，同时还可以下钻为每个索引和每个分片的统计信息。 这给你一个令人难以置信的详细视图，快照进展如何。 每个分片可以处于不同的完成状态。
INITIALIZING
分片正在检查集群状态看是否可以快照，这通常会很快
STARTED
数据正在传输数据到存储库中
FINALIZING
数据传输已完成，分片正在发送快照元数据
DONE
快照完成
FAILED
快照过程中遇到错误，这个分片/索引/快照没能完成，可以通过检查日志获取更多信息。

取消快照
最后，您可能需要取消快照或还原。因为这是一个长期运行的过程，在执行的过程中，你可能会出现错误，因此可能需要很长的时间来解决问题，而又不想让其占用宝贵的资源。

取消快照，当其执行的过程中，删除快照即可。
DELETE _snapshot/my_backup/snapshot_3
这将会暂停快照的过程，然后从仓库中删除未完成的快照。

原文参考官方文档：https://www.elastic.co/guide/en/elasticsearch/guide/current/backing-up-your-cluster.html