Curl 命令方式对elasticsearch备份和恢复

https://blog.csdn.net/qq_34777982/article/details/131340478

之前也写过使用API请求的方式对ES数据进行快照方式备份，这里主要对之前的内容进行完善和补充。

版本兼容性

快照包含构成索引的磁盘上数据结构的副本。这意味着快照只能还原为可以读取索引的 Elasticsearch 版本：

在5.x中创建的索引快照可以还原为6.x。

在2.x中创建的索引快照可以还原为5.x。

在1.x中创建的索引快照可以还原为2.x。

相反，在1.x中创建的索引的快照不能还原为5.x或6.x，在2.x中创建的索引的快照不能还原为6.x。

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

重要的：在升级前备份数据时，请记住，如果快照包含在与升级版本不兼容的版本中创建的索引，升级后将无法还原快照。

如果在需要还原与当前运行的群集版本不兼容的索引快照的情况下结束，可以在最新的兼容版本上还原该快照，并使用「reindex-from-remote」在当前版本上重建索引。只有在原始索引启用了source时，才能从远程重新索引。检索和重新索引数据可能比简单地还原快照要花费更长的时间。如果你有大量的数据，我们建议你在继续之前使用数据子集测试远程进程的reindex，以了解时间要求。

Elasticsearch 保证高可用性的方式

Elasticsearch 保证集群高可用的方式包含但不限于如下三种：

方式一：

        副本分片。主分片失效后，副本分片会被提升为主分片。

方式二：

       跨集群复制主从同步。简称：CCR，指的是索引数据从一个 Elasticsearch 集群复制到另一个 Elasticsearch 集群。对于主集群的索引数据的任何修改都会直接复制同步到从索引集群。

方式三：

      快照。快照在给定时刻对集群或者索引按了暂停键且拍摄了当时的全部"照片"。这样，当在之后的某个时间点，倘若集群或索引出现故障，可以基于之前的快照进行快速恢复。

Elasticsearch 7.x 之前版本备份

参考：Curl 命令方式对elasticsearch备份和恢复------ 筑梦之路_筑梦之路的博客-CSDN博客

Elasticsearch 7.x 之前版本备份方式及存在问题

7.x之前的版本快照都是手动创建、手动控制的，不支持定时快照、定时删除历史快照等功能。

实际业务中，如何定时创建快照、定时删除时间比较久的历史快照呢？

关于快照的定时管理功能在 Elasticsearch 7.x+ 版本已经实现。7.4已经支持单个索引快照SLM定时快照管理，7.6+已经支持多个索引快照SLM定时并行管理备份。

借助什么实现的呢？快照生命周期管理 (SLM) !

快照生命周期管理 (SLM) 是定期备份集群的最简单方法。SLM 策略会按照预设计划自动拍摄快照。该策略还可以根据用户自定义的保留规则（retention）删除快照。

配置ES快照仓库路径

配置快照仓库

cat elasticsearch.yml

path.repo: ["/usr/share/elasticsearch/data/snapshot_backup"]

注册快照仓库

PUT _snapshot/snapshot_backup

{

"type": "fs",

"settings": {

"location": "/usr/share/elasticsearch/data/snapshot_backup"

}

配置定时快照任务

PUT _slm/policy/daily_snapshots

{

"schedule": "0 0/15 * * * ?", # 定时任务 0/15 代表每15分钟创建一次快照

"name": "<test-snap-{now/d}>", # 快照的名称格式

"repository": "snapshot_backup", # 备份的repository

"config": {

"indices": "*", # 备份的索引

"include_global_state": true # 设置为true（默认为true），则创建的快照包括集群状态以及 feature 状态

"retention": {

"expire_after": "30d", # 快照存储的天数

"min_count": 5, # 最少存多少快照

"max_count": 50 # 最多存多少快照

}

手动执行快照任务
POST _slm/policy/daily_snapshots/_execute
retention定时任务

PUT _cluster/settings

{

"persistent" : {

"slm.retention_schedule" : "0 30 1 * * ?"

}

retention立即执行

POST _slm/_execute_retention

快照恢复

查看指定仓库下的快照

GET _snapshot/snapshot_backup/*?verbose=false

注意：原恢复索引若存在是不可以的，需要提前删除后再恢复。

示例如下：

DELETE .kibana-event-log-8.1.3-000001

POST _snapshot/mytx_backup/test-snap-2022.05.04-13d-_6dore-kc1x0-fdaiq/_restore

{

"indices": ".kibana-event-log-8.1.3-000001"

}

SLM快照生命周期管理常用命令

检查当前正在运行的快照

GET _snapshot/mytx_backup/_current

检查当前正在运行快照的详细信息

GET _snapshot/_status

查看全量SML poclicy执行历史

GET _slm/stats

"snapshots_taken" : 67 是执行快照的次数

查看特定SLM policy执行历史

GET _slm/policy/test-snapshots

参数说明：

last_success 代表上一次执行成功快照的名称;。

start_time 快照执行时间：2022-05-05 14:29:59。

next_execution_millis 下一次快照执行时间：2022-05-05 14:45:00。

snapshots_taken - snapshots_deleted 之差和retention 里规定的 50 个是基本一致的。

删除快照

DELETE _snapshot/mytx_backup/test-snap-2022.05.05-uhbwjyj8qwwhdxqvcgejbq

停止快照

POST _slm/stop

Stop snapshot lifecycle management API | Elasticsearch Guide [8.8] | Elastic

Elasticsearch 6.6 官方文档之「快照和还原」_path.repo_CG国斌的博客-CSDN博客

Elasticsearch 7.4错误地报告快照已在运行 - 问答 - 腾讯云开发者社区-腾讯云

原文链接：https://blog.csdn.net/qq_34777982/article/details/131340478