---
title: "Elasticsearch 备份：方案篇"
date: 2025-09-30
lastmod: 2025-09-30
description: "在 Elasticsearch 集群的日常运维中，制定完善的数据备份与恢复策略是保障业务连续性和数据安全的基石。在本文中，我们将探讨 ES 各类备份方案的实现逻辑，对比各自方案的优劣势，归纳它们适合的场景"
tags: ["Elasticsearch", "backup", "snapshot", "CCR", "Gateway", "esdump"]
summary: "1. 为什么要备份 # 在 Elasticsearch 集群的日常运维中，制定完善的数据备份与恢复策略是保障业务连续性和数据安全的基石。其中，备份作为数据保护的“最后一道防线”，其核心在于将某个时间点的集群完整快照，转储至可以快速恢复的存储介质或者离线数据库中，定期更新并长期保存。
一个有效的备份方案，不仅要求备份数据的完整性、一致性与可恢复性，还必须满足离线存储、周期执行与恢复验证等关键要求。其重要性不言而喻：在面对诸如硬件故障、数据中心级灾难、人为误操作（如误删数据）等极端场景时，备份是我们能够快速重建集群、找回关键历史数据，从而实现业务容灾与数据归档的唯一希望。因此，建立并严格执行备份方案，对于确保企业核心数据的长期安全与合规性至关重要。
2. ES 备份实现的方案 # 社区里，ES 的备份方案有很多，除了 ES 自带的 snapshot 和 CCR 外，还有社区里很多开源项目，如 esdump、gateway 等等，当然你也可以用 logstash+kafka 之类组件通过数据同步的自建方案（自建方案本文不进行阐述）实现数据备份的效果。
2.1 镜像备份 # Snapshot 是 Elasticsearch 自带的备份与恢复机制。它通过将索引底层的 Lucene segment 文件 拷贝到外部仓库来实现备份，首次备份是全量，之后为增量快照，只保存新增或变更的 segment。基于数据文件的备份，节省了数据内容的解析成本，对资源的占用更少，整体效率更高。
使用前需要配置快照仓库（repository），常见类型包括共享文件系统（NFS）、HDFS、S3、GCS 等，并保证所有节点都能访问该仓库。
基于底层数据文件的备份，使得镜像能支持到索引级和集群级的恢复。备份与恢复的耗时与数据规模密切相关，规模较小时可能仅需数分钟，而在数据量较大时，则可能延长至数小时甚至一天以上。同时也存在版本兼容的问题，具体可以 参见这里
Snapshot 是生产环境下一个不错的冷备方案，适合大规模数据的容灾恢复。
2.2 CCR # Cross Cluster Replication（CCR）是一种 Elasticsearch 提供的跨集群实时复制方案，可作为数据备份与容灾手段。其原理是将一个集群中的索引设为 leader index，在远程集群中配置对应的 follower index，通过内部的 shard-level replication 机制实时拉取并应用写入操作，保证目标索引与源索引保持高度一致。
使用 CCR 需要 X-Pack（商业功能） 支持，并要求两个集群之间网络能够互通，且 Elasticsearch 版本通常需保持一致。
CCR 是跨集群的分片复制功能，它和主副本复制类似。在首次链接复制完基础数据文件后，CCR 会从源集群的主分片持续拉取变更操作，然后在目标集群对应的分片上重放，从而保证两边分片的数据内容保持一致。因此 CCR 提供近实时的数据同步，RPO 接近 0。且对业务透明，无需改动应用。"
---
## 1. 为什么要备份
在 Elasticsearch 集群的日常运维中，制定完善的数据备份与恢复策略是保障业务连续性和数据安全的基石。其中，备份作为数据保护的“最后一道防线”，其核**心在于将某个时间点的集群完整快照**，转储至可以快速恢复的存储介质或者离线数据库中，定期更新并长期保存。
一个有效的备份方案，不仅要求备份数据的**完整性、一致性与可恢复性**，还必须满足**离线存储、周期执行与恢复验证**等关键要求。其重要性不言而喻：在面对诸如硬件故障、数据中心级灾难、人为误操作（如误删数据）等极端场景时，备份是我们能够快速重建集群、找回关键历史数据，从而实现业务容灾与数据归档的唯一希望。因此，建立并严格执行备份方案，对于确保企业**核心数据的长期安全**与合规性至关重要。
## 2. ES 备份实现的方案
社区里，ES 的备份方案有很多，除了 ES 自带的 snapshot 和 CCR 外，还有社区里很多开源项目，如 esdump、gateway 等等，当然你也可以用 logstash+kafka 之类组件通过数据同步的自建方案（_自建方案本文不进行阐述_）实现数据备份的效果。
{{% load-img "/img/blog/2025/es-backup-plans/backup1-1.png" "" %}}
### 2.1 镜像备份
Snapshot 是 Elasticsearch 自带的备份与恢复机制。它通过将索引底层的 **Lucene segment 文件** 拷贝到外部仓库来实现备份，**首次备份是全量，之后为增量快照**，只保存新增或变更的 segment。**基于数据文件的备份，节省了数据内容的解析成本，对资源的占用更少，整体效率更高**。
使用前需要配置快照仓库（repository），常见类型包括共享文件系统（NFS）、HDFS、S3、GCS 等，并保证所有节点都能访问该仓库。
{{% load-img "/img/blog/2025/es-backup-plans/backup1-2.png" "" %}}
基于底层数据文件的备份，使得镜像能支持到索引级和集群级的恢复。备份与恢复的耗时与数据规模密切相关，规模较小时可能仅需数分钟，而在数据量较大时，则可能延长至数小时甚至一天以上。同时也**存在版本兼容**的问题，具体可以[参见这里](https://www.elastic.co/docs/deploy-manage/tools/snapshot-and-restore#index-compatibility)
Snapshot 是生产环境下一个不错的**冷备方案**，适合大规模数据的容灾恢复。
### 2.2 CCR
Cross Cluster Replication（CCR）是一种 Elasticsearch 提供的跨集群实时复制方案，可作为数据备份与容灾手段。其原理是将一个集群中的索引设为 **leader index**，在远程集群中配置对应的 **follower index**，通过内部的 **shard-level replication** 机制实时拉取并应用写入操作，保证目标索引与源索引保持高度一致。
使用 CCR 需要 **X-Pack（商业功能）** 支持，并要求两个集群之间网络能够互通，且 **Elasticsearch 版本通常需保持一致**。
{{% load-img "/img/blog/2025/es-backup-plans/backup1-3.png" "" %}}
CCR 是跨集群的分片复制功能，它和主副本复制类似。在首次链接复制完基础数据文件后，CCR 会从源集群的主分片持续拉取变更操作，然后在目标集群对应的分片上重放，从而保证两边分片的数据内容保持一致。因此 CCR 提供**近实时的数据同步**，RPO 接近 0。且对业务透明，无需改动应用。
CCR 更适合对 **实时性与高可用要求极高** 的核心业务场景，能完成**数据热备**的要求。
### 2.3 esdump
esdump 是一种基于 Elasticsearch REST API 的轻量级数据导入导出工具，可用来实现逻辑层面的数据备份与迁移。其原理是通过调用 Elasticsearch 的 **Scroll API** 分批拉取文档数据，并利用 **Bulk API** 将数据写入目标集群或输出到 JSON 文件。除了文档数据外，它还支持索引 **mapping** 和 **settings** 的导出与恢复。
esdump 使用简单，命令行即可操作。它**不依赖外部存储仓库，部署简单**。支持导出到文件，便于异地保存或二次加工， 跨版本兼容性较好。
{{% load-img "/img/blog/2025/es-backup-plans/backup1-5.png" "" %}}
但是 esdump 仅支持全量导出，不具备增量备份能力。再加上性能有限，面对海量数据时效率较低，仅**适合小规模或跨版本的数据迁移**。
总体而言，esdump 更适合作为 **小规模备份、迁移或数据抽取** 的辅助方案，而在生产环境下的大规模冷备，仍建议使用 snapshot/ccr 等方案。
### 2.4 Gateway
[INFINI Gateway](https://docs.infinilabs.com/gateway/main/zh/) 实现 Elasticsearch 数据备份，其核心原理是在 ES 集群前部署网关，由它来**拦截并复制应用的写入请求**（如 bulk 操作）。这些请求会被网关记录到其内置的持久化队列中（如基于本地磁盘或 S3 的 INFINI Queue），然后**异步地将数据同步到备用的 ES 集群**。在主集群发生故障时，网关能将查询请求**自动切换**到备用集群，实现快速容灾。
{{% load-img "/img/blog/2025/es-backup-plans/backup1-4.png" "" %}}
Gateway 对于业务也是**透明**的。业务端通常只需修改访问地址，无需改动代码逻辑。它不仅通过主备集群和网关的故障切换能力，能有效保障业务连续性。同时基于请求复制的机制，结合队列的重试能力，能在复杂故障场景下最大限度地保证主备数据一致。并且 Gateway 对接入的 ES 集群并没有版本限制，**支持跨版本** ES、云上云下等多种场景，有着不可比拟的灵活性。
INFINI Gateway 能够充分**满足高实时性与高可用的热备需求**。这得益于其采用的数据内容复制模式，该机制显著降低了对环境同构性的要求，使其能够适应更多样化的部署场景。
## 3. 方案对比
那我们来对比一下上面几套方案的优缺点和适用场景。
| 方案 | 原理简述 | 优点 | 缺点 | 适用场景 |
| -------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------ |
| snapshot | 在存储或系统层面对整个数据目录做快照/拷贝 | 效率高,速度取决于底层存储性能 | 1.只能到索引或者集群级别；
2. 恢复时间最低分钟级，不满足热备条件；
3. 对于长期冷备的情况，需要大于索引大小的镜像存储空间。
4. 有主备版本限制 | 灾难恢复、**系统级冷备**，要求快速整体恢复的场景 |
| CCR | 在两个集群间实时复制索引的变更日志，保持主/从同步 | 实时/准实时复制 | 1. 仅限付费版本；
2. 两集群版本保持一致 | 异地容灾、**实时热备**，业务连续性要求高的场景 |
| esdump | 基于 Scroll API + Bulk API 导出文档数据、mapping、settings | 1.使用简单；
2.可导出到文件，方便迁移或二次加工 | 1. 性能差，处理大数据量耗时长;
2.无增量能力 | **小规模索引迁移**、调试数据导出、开发测试环境数据同步 |
| Gateway | 作为中间件或插件，将数据流式写入到对象存储/分布式存储，并支持恢复 | 1. 对应用程序和 es 都无感透明，部署简单;
2. 使用灵活，可配置度高；
3. 高性能同步工具。 | 暂无 | 异地容灾、**实时热备**，业务连续性要求高的场景 |
## 4. 小结
在本文，我们探讨了 ES 备份的一些主流方案，各自的优缺点，以及其适用的场景。在接下来的一篇里，我们将深入剖析 Snapshot 实现文件备份的原理，演示全量与增量备份的完整操作，并为大家解锁 Elasticsearch 一项颇为人知却至关重要的“隐藏技能”——高效的**增量恢复**。