官方文档-创建快照

对应7.17官方文档路径：Snapshot and restore » Create a snapshot
官方地址如下：
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/snapshots-take-snapshot.html

创建快照

本章节主要展示如何制作正在运行的集群的快照，之后便可以通过恢复快照 API 恢复或者传输数据。
在本章节，你将学会一下内容：

• 使用快照生命周期管理(SLM)自动创建和保留快照
• 手动拍摄快照
• 监控快照进度
• 删除或取消快照
• 备份集群配置文件

本章节还提供了创建集群状态专用快照和在不同时间间隔制作快照的技巧。

先决条件

• 想要使用 Kibana的 Snapshot and Restore 功能，你必须具备一下权限：
  • 集群权限：monitor, manage_slm, cluster:admin/snapshot, cluster:admin/repository
  • 索引权限：monitor 索引 all 权限
• 你只能在具有选定主节点的正在运行的集群上制作快照
• 快照仓库必须已经在集群上注册并可用
• 集群的全局元数据必须可读，将进行快照的索引及其原数据也必须可读，确保没有任何阻止读取集群和索引的配置。

注意事项

• 每个快照在其仓库必须具备唯一的名字，尝试创建同名快照将失败
• 快照会自动删除重复数据，你可以频繁创建快照，对存储空间影响不大
• 每个快照逻辑独立，删除一个快照对其他快照无影响
• 制作快照会暂停分片的分配移动
• 制作快照不会阻止索引和其他请求，但快照不包含在其开始后的更改内容
• 你可以同时拍摄多个快照，集群配置参数snapshot.max_concurrent_operations限制了快照操作并发数
• 如果你的快照包含数据流，则它还将包含数据流的支持索引和元数据。你还可以在快照中仅包含特定的支持索引。但是，快照将不会包含数据流的元数据或其他支持索引。
• 快照可以包括数据流，但不包括特定的支持索引。当你恢复此类数据流时，它将仅包含快照中的支持索引。如果流的原始写入索引不在快照中，则快照中最近的支持索引将成为流的写入索引。

使用 SLM 自动制作快照

SLM 是定期备份集群最简单的方法，SLM 策略会按照预设计划自动拍摄快照，该策略还可以根据你定义的保留规则删除快照。

SLM 安全

当 ES 安全功能开启时，以下集群权限控制对 SLM 功能的访问：

• manage_slm
  允许用户执行全部 SLM 操作，包括创建更新策略以及开始和结束策略
• read_slm
  允许用户执行全部 SLM 只读操作，例如获取策略信息以及检查 SLM 状态
• cluster:admin/snapshot/*
  允许用户制作或删除任何索引的快照，无论他们是否有索引访问权限

你可以通过 Kibana 来创建管理具备这些权限的角色。
授权一个用户用以创建和管理 SLM 策略和快照，你可以创建一个角色具备manage_slm和cluster:admin/snapshot/*集群权限以及 SLM 历史索引的全部权限，如下所示：

POST _security/role/slm-admin
{
  "cluster": [ "manage_slm", "cluster:admin/snapshot/*" ],
  "indices": [
    {
      "names": [ ".slm-history-*" ],
      "privileges": [ "all" ]
    }
  ]
}

授权一个用户用以 SLM 策略和历史快照的只读操作，你可以创建一个角色具备read_slm集群权限以及 SLM 历史索引的read权限，如下所示：

POST _security/role/slm-read-only
{
  "cluster": [ "read_slm" ],
  "indices": [
    {
      "names": [ ".slm-history-*" ],
      "privileges": [ "read" ]
    }
  ]
}

创建一个 SLM 策略

在 kibana 上管理 SLM，路径为 Stack Management > Snapshot and Restore > Policies，创建策略可以点击 Create policy。
你也可以使用 SLM API 管理 SLM。
以下请求创建一个策略在每天 UTC 时间 1:30 备份集群状态，全部数据流和全部 open 状态的索引：

PUT _slm/policy/nightly-snapshots
{
  "schedule": "0 30 1 * * ?",        ①
  "name": "<nightly-snap-{now/d}>",  ②
  "repository": "my_repository",     ③
  "config": {
    "indices": "*",                  ④
    "include_global_state": true     ⑤
  },
  "retention": {                     ⑥
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

① 制作快照定时任务采用 Cron 语法
② 快照名称支持 date math 语法，为避免命名冲突，策略会在每个快照后面追加 UUID
③ 配置集群内已注册的快照仓库
④ 配置快照需要备份的数据流和索引，通配符表示快照将包括所有数据流和所有 open 的索引，包括系统索引
⑤ 设置为 true，快照将包含集群状态和 feature states
⑥ 快照保留规则。保留30天，且忽略年龄保留至少5个快照至多50个快照

手动运行 SLM 策略

你可以手动运行 SLM 策略立刻制作一个快照，可以用于测试一个新的策略或者在更新升级前制作一个快照。手动运行策略不影响快照的定时任务。
Kibana 界面可以在 Policies 界面点击 Run Now 按钮执行，或者可以使用 execute SLM policy API 执行：

POST _slm/policy/nightly-snapshots/_execute

快照进程在后台运行，监控其运行状态使用 Monitor a snapshot API。

SLM 保留计划

SLM 快照保留计划是集群级别的任务，与策略的快照保留计划是相互独立的。用来控制 SLM 保留任务的运行周期和时间，通过集群设置slm.retention_schedule来配置

PUT _cluster/settings
{
  "persistent" : {
    "slm.retention_schedule" : "0 30 1 * * ?"
  }
}

要立刻运行集群保留计划，使用 execute SLM retention policy API：

POST _slm/_execute_retention

SLM 策略的保留计划仅适用于使用 SLM 创建的快照。其他方式创建的快照不计入策略的保留限制。

快照保留限制

我们建议你在 SLM 策略中配置保留策略retention，用来删除不再需要的快照。
快照仓库可以安全的扩展到数千个快照，但是为了管理其元数据，大型快照仓库会占用主节点更多内存。快照保留规则确保仓库的元数据不会增长到可能破坏主节点稳定性的大小。

手动创建快照

不使用 SLM 策略创建快照，使用 create snapshot API 进行单独创建，快照命名支持 date math。

# PUT _snapshot/my_repository/<my_snapshot_{now/d}>
PUT _snapshot/my_repository/%3Cmy_snapshot_%7Bnow%2Fd%7D%3E

根据备份数据大小，快照可能需要一段时间才能完成。默认情况下，创建快照 API 仅启动快照进程，该进程在后台运行。要在快照完成之前阻塞客户端，请将wait_for_completion参数设置为true。

PUT _snapshot/my_repository/my_snapshot?wait_for_completion=true

你还可以使用 clone snapshot API 克隆现存的快照。

监控快照

要监控任何当前正在运行的快照，使用 get snapshot API 带上 _current 参数：

GET _snapshot/my_repository/_current

要获取参与任何当前正在运行的快照的每个分片的完整细节，使用 get snapshot status API：

GET _snapshot/_status

查看 SLM 历史记录

要获取集群 SLM 执行历史记录的更多信息，包括每个 SLM 策略的状态，使用 get SLM stats API。该 API 还会返回有关集群的快照保留任务历史记录的信息。

GET _slm/stats

要获取某一个特定 SLM 策略的执行记录，使用 get SLM policy API，请求回复包括以下内容：

• 策略计划执行的下一次任务
• 策略上次成功启动快照过程的时间，成功启动并不能保证快照已完成
• 上次策略执行失败的时间以及相关的错误

GET _slm/policy/nightly-snapshots

删除或取消快照

在 Kibana 的 Snapshots 界面点击删除按钮或者使用 delete snapshot API 进行删除：

DELETE _snapshot/my_repository/my_snapshot_2099.05.06

如果你删除正在制作中的快照，ES 会取消制作它。制作快照进程停止并删除为快照创建的所有文件。删除快照不会删除其他快照使用的文件。

备份配置文件

如果你在自己的硬件上运行 ES，我们建议你除了备份快照之外，还需要对每个节点$ES_PATH_CONF目录中的文件进行定期备份。快照不会备份这些文件。
根据你的设置，其中一些配置文件可能包含敏感数据，例如密码或密钥。如果是这样，请考虑加密您的文件备份。

备份特殊功能状态

默认包含集群状态的快照会包含全部功能状态，不包含集群状态的快照也不包含功能状态。
你也可以配置快照进包含特定功能状态，而忽视集群状态。
要获取可用功能的列表，使用 get features API (7.12版本以后功能)：

GET _features

API 返回：

{
  "features": [
    {
      "name": "tasks",
      "description": "Manages task results"
    },
    {
      "name": "kibana",
      "description": "Manages Kibana configuration and reports"
    },
    {
      "name": "security",
      "description": "Manages configuration for Security features, such as users and roles"
    },
    ...
  ]
}

要在快照中包含特定的功能状态，请在 feature_states 数组中指定该功能名称。
例如，以下 SLM 策略仅在其快照中包含 Kibana 和 ES 安全功能的功能状态：

PUT _slm/policy/nightly-snapshots
{
  "schedule": "0 30 2 * * ?",
  "name": "<nightly-snap-{now/d}>",
  "repository": "my_repository",
  "config": {
    "indices": "*",
    "include_global_state": true,
    "feature_states": [
      "kibana",
      "security"
    ]
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

作为功能状态一部分的任何索引或数据流都将显示在快照中。例如，如果你备份 security 功能状态，security-* 系统索引会显示在 get snapshot API 的回复中，位于 indices 和 feature_states 内。

专用集群状态快照

一些功能状态包含敏感数据，例如 security 功能状态包含的系统索引存储了用户名和哈希加密的密码。
为了更好地保护这些数据，请考虑为集群状态的快照创建专用仓库和 SLM 策略。这使您可以严格限制和审核对仓库的访问。
例如，下面的 SLM 策略只备份集群状态，并且策略存储快照到特定的仓库。

PUT _slm/policy/nightly-cluster-state-snapshots
{
  "schedule": "0 30 2 * * ?",
  "name": "<nightly-cluster-state-snap-{now/d}>",
  "repository": "my_secure_repository",
  "config": {
    "include_global_state": true,         ①        
    "indices": "-*"                       ②
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

① 包含集群状态，默认包含全部功能状态
② 排除常规数据流和索引
如果你为集群状态制作专用快照，则需要从其他快照中排除集群状态和系统索引。例如：

PUT _slm/policy/nightly-snapshots
{
  "schedule": "0 30 2 * * ?",
  "name": "<nightly-snap-{now/d}>",
  "repository": "my_repository",
  "config": {
    "include_global_state": false,      ①
    "indices": "*,-.*"                  ②  
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

① 排除集群状态，默认排除全部功能状态
② 包含全部数据流和全部 open 的索引，但是排除系统索引和其他以.开头的索引

在不同时间间隔创建快照

如果你仅使用单个 SLM 策略，可能较难频繁制作快照并以较长时间间隔保留快照。
例如， 每30分钟制作一次快照且最多保留100个快照的 SLM 策略只会保留大约两天的快照。虽然此设置很适合备份最近的修改，但它不能让你恢复前一周或前一个月的数据。
要解决此问题，你可以在一个快照仓库创建多个不同制作计划的 SLM 策略。由于策略保留计划仅针对自身生成的快照，所以它不会删除其他策略创建的快照。
例如，以下策略每小时制作一次快照并且最多保留24个快照，快照最多保留一天：

PUT _slm/policy/hourly-snapshots
{
  "name": "<hourly-snapshot-{now/d}>",
  "schedule": "0 0 * * * ?",
  "repository": "my_repository",
  "config": {
    "indices": "*",
    "include_global_state": true
  },
  "retention": {
    "expire_after": "1d",
    "min_count": 1,
    "max_count": 24
  }
}

以下策略在同一仓库内每年夜间制作快照，该策略将其制作的快照保留一个月：

PUT _slm/policy/daily-snapshots
{
  "name": "<daily-snapshot-{now/d}>",
  "schedule": "0 45 23 * * ?",          ①
  "repository": "my_repository",
  "config": {
    "indices": "*",
    "include_global_state": true
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 1,
    "max_count": 31
  }
}

① UTC 时间每天 23:45 制作快照
以下策略在同一快照仓库中创建每月快照，该策略将其制作的快照保留一年：

PUT _slm/policy/monthly-snapshots
{
  "name": "<monthly-snapshot-{now/d}>",
  "schedule": "0 56 23 1 * ?",          ①
  "repository": "my_repository",
  "config": {
    "indices": "*",
    "include_global_state": true
  },
  "retention": {
    "expire_after": "366d",
    "min_count": 1,
    "max_count": 12
  }
}

① UTC 时间每个月1号 23:56 制作快照