快照与恢复(Snapshot and Restore)功能是构建健壮、可恢复的 Elasticsearch 集群的 核心基石,用于 灾难恢复、数据迁移、版本升级回滚、环境复制 等关键场景。
1.核心概念
- 快照:是 Elasticsearch 集群状态 和 索引数据 在特定时间点的 只读副本。它不是简单的文件拷贝,而是利用 Elasticsearch 底层(Lucene)的特性高效捕获数据。
- 快照仓库:快照存储的位置。这是一个 持久化的共享存储系统,集群所有节点都能访问。Elasticsearch 不管理存储的生命周期(如清理旧快照),需在仓库层面管理。
- 恢复:将存储在快照仓库中的一个或多个快照的数据和元数据 还原 到集群中的过程。可以恢复到原集群或新集群。
2.核心价值与优势
- 灾难恢复:应对硬件故障、人为误删、软件缺陷导致的数据损坏或丢失。
- 数据迁移:
- 跨集群迁移(同版本或升级)。
- 跨云迁移或混合云部署。
- 从开发/测试环境迁移到生产环境。
- 版本升级/回滚:在重大升级前创建快照,升级失败可快速回滚到之前状态。
- 环境复制:将生产环境的数据快照恢复到测试或预发布环境,进行真实数据测试。
- 长期归档:将不再频繁访问但仍需保留的数据(符合合规要求)归档到成本更低的存储介质。
- 增量高效:
- 首次快照:是全量备份。
- 后续快照:默认是 增量 的!Elasticsearch 只会备份自上次快照以来 新增或修改的 Lucene 段文件。这极大地节省了存储空间和备份时间。
- 一致性保证:快照过程保证捕获的是 一致的时间点视图,即使索引正在被写入。这是通过利用 Lucene 的不可变段文件特性实现的。
- 灵活粒度:
- 可以备份 整个集群。
- 可以备份 特定的索引。
- 可以备份 特定的数据流。
- 可以包含 集群状态(包含索引模板、ILM 策略、Ingest Pipeline、索引别名、持久化任务等元数据)。
- 并行恢复:恢复操作可以在多个节点上并行执行,加快恢复速度。
- 云原生支持:与主流对象存储(AWS S3、Azure Blob Storage、Google GCS)深度集成,通过仓库插件实现。
3.关键组件详解
3.1 快照仓库
- 类型:由插件实现。常见类型:
- 共享文件系统(
fs
):NFS、SAN、NAS。需确保所有节点挂载到同一路径,并有读写权限。 - 对象存储:
- AWS S3(
s3
):通过repository-s3
插件。 - Azure Blob Storage(
azure
):通过repository-azure
插件。 - Google Cloud Storage(
gcs
):通过repository-gcs
插件。 - 兼容 S3 API 的存储(如 MinIO、Ceph RGW):也可使用
s3
类型。
- AWS S3(
- HDFS(
hdfs
):通过repository-hdfs
插件。
- 共享文件系统(
- 注册:仓库必须 先注册 才能使用。注册是集群级别的操作。
PUT /_snapshot/my_backup_repo { "type": "s3", "settings": { "bucket": "my-elasticsearch-backups", "region": "us-west-1", "access_key": "YOUR_ACCESS_KEY", // 推荐使用 IAM 角色或 Keystore "secret_key": "YOUR_SECRET_KEY", // 推荐使用 IAM 角色或 Keystore "base_path": "snapshots/prod_cluster" // 可选,仓库内的路径 } }
- 验证:
- 检查节点是否能连接仓库:
GET /_snapshot/my_backup_repo/_verify
。
- 检查节点是否能连接仓库:
- 管理:
- 查看所有仓库:
GET /_snapshot
。 - 删除仓库(不会删除仓库内快照数据):
DELETE /_snapshot/my_backup_repo
。
- 查看所有仓库:
3.2 快照
- 创建:
PUT /_snapshot/my_backup_repo/my_snapshot_20230720?wait_for_completion=true { "indices": "index_1,index_2,data_stream_*", // 可选,默认备份所有 open 的索引和数据流 "ignore_unavailable": true, // 忽略不存在的索引 "include_global_state": true, // 可选,默认 true,是否包含集群状态 "partial": false // 可选,默认 false。true 允许部分索引备份成功(有未分配分片时)。生产环境慎用! }
wait_for_completion=true
会阻塞直到完成。大型集群建议设为false
,通过 API 监控进度。
- 增量性:自动识别并仅备份新/改的段文件。仓库维护一个快照链。
- 监控:
- 查看特定快照状态:
GET /_snapshot/my_backup_repo/my_snapshot_20230720
。 - 查看详细进度和统计信息:
GET /_snapshot/my_backup_repo/my_snapshot_20230720/_status
。 - 查看所有正在运行的快照:
GET /_snapshot/_status
。
- 查看特定快照状态:
- 删除:
DELETE /_snapshot/my_backup_repo/my_snapshot_20230720
。- 重要: Elasticsearch 会清理 仅被该快照引用 的段文件。被其他快照共享的段文件不会被删除。删除是安全的操作。
3.3 恢复
- 基本恢复:
POST /_snapshot/my_backup_repo/my_snapshot_20230720/_restore?wait_for_completion=false { "indices": "index_1,index_2", // 可选,默认恢复快照中所有索引 "ignore_unavailable": true, "include_global_state": false, // 强烈建议设置为 false!除非明确需要恢复集群级设置 "include_aliases": false, // 可选,是否恢复索引别名 "index_settings": { // 可选,覆盖恢复索引的设置 "index.number_of_replicas": 0 // 例如恢复时先不加副本加快速度 }, "ignore_index_settings": ["index.refresh_interval"] // 可选,忽略某些设置 }
- 重命名索引 / 更改数据流:使用
rename_pattern
和rename_replacement
参数在恢复时重命名索引或更改数据流名称。POST /_snapshot/my_backup_repo/my_snapshot_20230720/_restore { "indices": "logs-prod-*", "rename_pattern": "logs-prod-(.+)", "rename_replacement": "logs-test-$1" // 将 logs-prod- 前缀改为 logs-test- }
- 选择性恢复:可以只恢复特定索引,甚至使用
include_aliases
和index_settings
精细控制。 - 部分恢复:如果快照创建时允许
partial
,即使有分片缺失也能恢复(数据不完整)。 - 监控恢复:
- 恢复 API 返回的
task_id
可用于GET /_tasks/{task_id}
。 - 索引恢复状态:
GET /_recovery
或GET /index_1/_recovery
。 - 集群健康:
GET /_cluster/health
关注initializing_shards
和relocating_shards
。
- 恢复 API 返回的
- 冲突处理:如果要恢复的索引在目标集群中 已存在且打开,恢复操作 默认会失败。必须先关闭或删除目标集群中的现有索引。
4.最佳实践与注意事项
- 仓库选择:
- 生产环境:强烈推荐使用云对象存储(
S3
、GCS
、Azure Blob
)或高度可靠的共享文件系统。 避免使用本地路径。 - 权限与安全:严格配置仓库访问权限(IAM 角色、存储桶策略)。使用 Elasticsearch Keystore 存储敏感凭证。
- 生命周期管理:在存储系统层面配置策略,自动归档或删除旧快照(Elasticsearch 本身不自动清理)。
- 生产环境:强烈推荐使用云对象存储(
- 快照策略:
- 定期快照:使用
Elasticsearch SLM
(Snapshot Lifecycle Management
) 自动化创建、保留和删除快照。定义策略(如每小时、每天、每周),保留策略(如保留最后 30 30 30 天快照,每周保留一个快照持续 12 12 12 个月)。 - 命名规范:使用清晰一致的命名(如
daily-20230720
)。 - 测试恢复!定期进行恢复演练 是确保备份有效性的唯一方法。恢复到隔离环境验证。
- 定期快照:使用
- 恢复策略:
include_global_state: false
: 恢复生产快照到非生产环境时,几乎总是将此设置为false
! 避免覆盖目标集群的模板、ILM 策略等关键配置。- 副本设置:恢复时临时设置
index.number_of_replicas: 0
可以显著加快恢复速度(数据只恢复一份)。恢复完成后,再调整副本数。 - 资源规划 :恢复是资源密集型操作(网络 I/O、磁盘 I/O、CPU)。确保目标集群有足够资源,避免影响线上业务。考虑在维护窗口进行。
- 版本兼容性:快照具有 向后兼容性:
- 你可以将
N.x
的快照恢复到>= N.x
的集群(例如7.17
快照 →8.10
集群)。 - 不能 将
N.x
的快照恢复到< N.x
的集群(例如8.10
快照 →7.17
集群)。需要先恢复到同版本或更高版本,再使用 Reindex API 或 Logstash 等工具向下迁移。
- 你可以将
- 监控与告警:
- 监控 SLM 作业执行状态(成功/失败)。
- 监控快照创建/恢复的持续时间、速度。
- 监控仓库存储空间使用情况。
- 设置告警规则(如快照连续失败、仓库空间不足)。
- 性能考量:
- 快照/恢复速度受限于 网络带宽(到仓库)和 存储 I/O 性能(源/目标集群磁盘、仓库)。
- 大型集群的快照可能需要数小时。使用
wait_for_completion=false
并异步监控。 - 调整
thread_pool
(如snapshot
、generic
)大小需谨慎,评估对集群性能的影响。
5.总结
Elasticsearch 的快照与恢复是一个 强大、灵活且高效 的机制,是任何严肃的生产部署不可或缺的一部分。通过理解其增量备份原理、仓库管理、SLM 自动化以及细致的恢复策略(特别是 include_global_state
的处理),Elasticsearch 工程师能够构建可靠的数据保护、迁移和灾难恢复方案。
🚀 切记:备份的价值只有在成功恢复时才能体现,因此定期的恢复演练至关重要。