Elasticsearch 備份：方案篇

在 Elasticsearch 集群的日常運維中，制定完善的數據備份與恢復策略是保障業務連續性和數據安全的基石。在本文中，我們將探討 ES 各類備份方案的實現邏輯，對比各自方案的優劣勢，歸納它們適合的場景

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。且對業務透明，無需改動應用。

CCR 更適合對 實時性與高可用要求極高 的核心業務場景，能完成數據熱備的要求。

2.3 esdump

esdump 是一種基于 Elasticsearch REST API 的輕量級數據導入導出工具，可用來實現邏輯層面的數據備份與遷移。其原理是通過調用 Elasticsearch 的 Scroll API 分批拉取文檔數據，并利用 Bulk API 將數據寫入目標集群或輸出到 JSON 文件。除了文檔數據外，它還支持索引 mapping 和 settings 的導出與恢復。

esdump 使用簡單，命令行即可操作。它不依賴外部存儲倉庫，部署簡單。支持導出到文件，便于異地保存或二次加工， 跨版本兼容性較好。

但是 esdump 僅支持全量導出，不具備增量備份能力。再加上性能有限，面對海量數據時效率較低，僅適合小規?；蚩绨姹镜臄祿w移。

總體而言，esdump 更適合作為 小規模備份、遷移或數據抽取 的輔助方案，而在生產環境下的大規模冷備，仍建議使用 snapshot/ccr 等方案。

2.4 Gateway

INFINI Gateway 實現 Elasticsearch 數據備份，其核心原理是在 ES 集群前部署網關，由它來攔截并復制應用的寫入請求（如 bulk 操作）。這些請求會被網關記錄到其內置的持久化隊列中（如基于本地磁盤或 S3 的 INFINI Queue），然后異步地將數據同步到備用的 ES 集群。在主集群發生故障時，網關能將查詢請求自動切換到備用集群，實現快速容災。

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 一項頗為人知卻至關重要的“隱藏技能”——高效的增量恢復。

作者：金多安，極限科技（INFINI Labs）搜索運維專家，Elastic 認證專家，搜索客社區日報責任編輯。一直從事與搜索運維相關的工作，日常會去挖掘 ES / Lucene 方向的搜索技術原理，保持搜索相關技術發展的關注。
原文：https://infinilabs.cn/blog/2025/es-backup-plans/