1、为什么需要快照备份与恢复

随着社会的高速发展，数据量呈爆炸式增长，数据已成为企业最核心的资产之一。一旦发生数据丢失，不仅可能造成业务中断，甚至还会带来巨大的经济损失和信誉风险。TongSearch 的快照与备份功能就像是为数据投保了一份“安全保障”，在面对数据意外删除、系统故障或灾难恢复等场景时，能够第一时间实现数据回滚与业务恢复，为数据安全和系统稳定运行提供了坚实的支撑。因此，TongSearch的快照与备份功能的存在十分必要，它为企业和组织在数字化转型中提供了坚实的数据安全保障。

1.1 防止数据丢失

尽管TongSearch有副本机制，但面对硬件故障、软件错误甚至恶意攻击等意外情况，数据仍可能丢失。有了快照与备份，就能在出问题时迅速恢复数据，减少损失。

1.2保障业务连续性

快照操作不会阻塞集群的正常读写，可以在业务运行时进行备份，一旦集群故障或数据误删，能快速恢复，让业务尽快回归正轨。

1.3数据迁移和归档

当需要将数据从一个集群迁移到另一个集群，或者要将历史数据归档以释放在线集群存储空间时，快照功能都能轻松搞定。

1.4降本增效

快照是增量创建的，只备份有变化的数据，节省了存储空间和备份时间，间接降低了运维成本。

2、快照备份与恢复的基础概念

在 TongSearch 中，快照与备份功能的实现围绕四个核心概念展开，分别是 Snapshot（快照）、Repository（快照仓库）、Restore（恢复） 以及 快照状态（Snapshot Status）。理解这几个基础概念，有助于我们更好地掌握数据备份的流程和恢复机制。

2.1 Snapshot（快照）

快照可以看作是 TongSearch 某一时刻数据状态的“照片”，它记录了一个或多个索引在某个时间点的完整只读副本。与传统数据库那种大文件式全量备份不同，TongSearch 快照是增量式的，第一次快照会保存全部数据，后续快照只保存发生变化的部分，从而提高备份效率并节省存储空间。快照操作可以在集群运行过程中执行，不会中断正在进行的业务操作，是实现在线备份的关键手段。

2.2 Repository（快照仓库）

所有的快照都必须被存储在一个叫做“仓库”的地方。这个仓库可以是本地磁盘路径、共享文件系统，或者云服务（如 Amazon S3、HDFS、MINIO、Azure Blob 等）。在创建快照之前，必须先注册一个仓库，并配置其类型和路径等信息。仓库不仅存放数据快照本体，还管理着每个快照的元数据，例如索引的结构信息、段文件引用等，是整个备份系统的“存储基座”。

2.3 Restore（恢复）

恢复是快照功能的另一半，用于将快照中的数据重新加载到 TongSearch 集群中。当出现意外删除、索引损坏、集群迁移等情况时，可以通过恢复操作快速找回数据。恢复不仅可以将数据恢复到原来的索引名，也可以通过重命名的方式恢复为新索引，以便进行数据测试或分析操作。整个恢复过程灵活、可控，支持部分索引恢复、别名处理、只恢复设置或只恢复映射等多种高级用法。

2.4 快照与恢复状态（Snapshot & Restore Status）

由于 TongSearch 的快照和恢复操作都是异步执行的，整个过程中涉及多个节点和分片，因此状态监控显得尤为重要。TongSearch 提供了详细的 API 接口，帮助用户实时了解操作的执行进度和结果，确保数据安全可控。

2.4.1 快照状态（Snapshot Status）

在创建快照时，可以通过 _snapshot 相关 API 查询每个快照的执行状态。常见状态包括：

• IN_PROGRESS：快照正在进行中，系统正在协调各节点完成数据保存。
• SUCCESS：快照操作全部完成，所有分片备份成功。
• FAILED：快照操作失败，可能由于仓库配置问题、磁盘空间不足、网络异常或索引不可访问等原因。
• PARTIAL：部分分片成功备份，部分失败，可能是节点临时不可用或分片状态不稳定导致。
• INCOMPATIBLE：快照不兼容当前集群版本，无法被读取或恢复。
  通过这些状态，运维人员可以迅速判断快照操作是否成功、安全，是否需要重试或手动干预。

2.4.2 恢复状态（Restore Status）

在执行恢复操作时，TongSearch 也提供了相应的状态反馈机制。恢复过程可能涉及大量索引重建、数据重分片、集群资源调度等操作，典型状态包括：

• IN_PROGRESS：恢复操作正在执行，系统在逐个索引或分片地加载数据。
• SUCCESS：恢复完成，所有指定索引数据恢复成功。
• PARTIAL：部分索引或分片恢复失败，可能是快照不完整、恢复时命名冲突、目标节点存储不足等。
• FAILED：恢复失败，常见原因包括目标索引已存在但不可覆盖、仓库异常、快照格式错误等。

另外，恢复还支持细粒度的控制，比如：

• 仅恢复特定索引
• 设置是否覆盖已有索引
• 控制是否恢复索引设置和别名

3、快照备份与恢复功能相较于传统数据备份的优势

在分析优势前，我们先思考这样一个问题：直接拷贝文件能否实现tongsearch的数据备份？

这里直接说结论，直接拷贝文件能否实现tongsearch的数据备份？这是要区分备份时集群是处于运行时还是停机时。
运行时不可行，无法确保数据一致性问题，因为节点目录状态是动态的，集群会有事务日志，元数据变更等情况，备份数据目录无法将这些状态一起备份。
停机状态下是可行的，前提是操作中遵循规范并确保目录结构、权限以及配置文件正确。对于小型集群或临时迁移，这种方法是可用的。但对于复杂的生产环境，仍建议通过快照功能进行备份和迁移，以便更灵活地恢复和扩展。

3.1 安全性更高，避免数据损坏和丢失

传统数据库的备份通常需要在数据文件处于“静态”状态下进行，一旦备份过程中数据正在被写入或读取，就可能导致文件损坏、备份不完整，甚至在看似成功的备份文件中隐藏数据丢失的风险。而 TongSearch 的快照功能通过集群内部协调机制，在不中断服务的前提下，确保数据在一致性状态下完成备份，快照过程中会记录所有节点上的分片状态，避免了数据写入和备份“打架”的问题，大大提高了数据备份的可靠性和一致性。可以说，快照就是在“系统照常运行”的同时，悄无声息地为你完成了一次稳定而可靠的数据存档。

3.2 支持增量备份，节省空间与时间成本

传统备份方式通常采用全量备份策略，即每次备份都会完整复制全部数据，不仅耗时长，而且会占用大量磁盘空间。随着数据量的增长，特别是当数据达到 TB 级别甚至更高时，传统备份方式会变得越来越不现实。而 TongSearch 快照则天然支持增量备份机制，只会在首次全量快照之后，记录之后发生变化的数据部分，从而极大节省存储资源和备份时间。此外，快照是基于索引级别进行管理的，用户可以灵活指定要备份的具体索引，不仅可以保留索引别名，索引template配置，还可以避免了不必要的数据备份，也提升了操作的灵活性和效率。

3.3 原生 API 支持，集成与自动化更高效

传统备份通常依赖于底层操作系统的命令行工具或第三方脚本来进行磁盘层面的数据复制，难以与业务系统深度集成，且存在维护成本高、可控性差的问题。而 TongSearch 提供了原生快照与恢复 API，用户可以通过标准的 RESTful 接口进行备份策略配置、快照创建、状态监控和数据恢复等操作。这种 API 驱动的方式不仅易于脚本化与自动化，还便于集成到 CI/CD 流程中，实现更高层次的系统自治与弹性恢复能力，大幅提升了运维效率。

4、快照备份与恢复原理

4.1 TongSearch数据存储结构

进入某个节点data目录下，可以发现如下的目录结构：

drwxrwxr-x 70 es es  4096 Apr 11 09:59 indices/           # 索引数据存储目录
-rw-rw-r--  1 es es     0 Oct 28 14:37 node.lock          # 防止多实例同时访问目录的锁文件
drwxrwxr-x  2 es es 12288 Apr 11 09:59 _state             # 当前节点的元数据状态

数据目录结构框架图：

数据目录结构解析：

• 为了避免集群数据目录冲突，node.lock 文件可以确保一次只能从一个数据目录读取/写入一个 ES 相关的安装启动信息。

• global-1389.st 是一个包含元数据的状态文件，存储着集群状态以及集群分片映射等信息，global- 前缀表示这是一个全局状态文件，而 1389 是该文件的版本号，当集群状态发生变化时，会更新元数据文件。

• indices 文件夹下的是我们具体索引的数据文件，这里的 index 文件夹由 lucene 写入，而 translog 文件夹和 _state 文件夹由 ES 写入。lucene 每次添加/修改的数据先放在内存中，并不是实时落盘的，而是直到缓冲区满了或者用户执行 commit api，数据才会落盘，形成一个 segement，保存在文件中。ES 节点实现了 translog 类， 即数据索引前，会先写入到日志文件中。translog 用于在节点机器突发故障(比如断电或者其他原因)导致节点宕机，重启节点时就会重放日志，这样相当于把用户的操作模拟了一遍。保证了数据的不丢失。这里的操作有点类似 MySQL 的 redo log 和 bin log，redo log 作为机器异常宕机或者存储介质发生故障后的数据恢复使用，而 binlog 作为 MySQL 恢复数据使用，一般用作主从复制集群搭建或者第三方插件数据同步(比如：canal)。节点宕机重启后并非重放所有的 translog，而是最新没有提交索引的那一部分。所以必须有一个 checkpoint, 即 translog.ckp 文件，保证节点宕机重启后可以从最近已提交的文件处重放，类似 bin log 的 position.

index 文件是 lucene 框架维护的，主要是为写入的文档建立倒排索引，其具体文件格式和作用如下 :

文件名称	扩展名	描述
Segments File	segments.gen, segments_N	存储段相关信息
Lock File	write.lock	write lock 防止多个 IndexWriters 写入同一个文件
Compound File	.cfs	一个可选的“虚拟”文件，由经常用完文件句柄的系统的所有其他索引文件组成
Fields	.fnm	存储文档field字段相关信息
Field Index	.fdx	包含指向文档field字段数据的指针
Field Data	.fdt	存储文档的field字段
Term Infos	.tis	term词语词典，存储term词信息
Term Info Index	.tii	term词语文件的索引信息
Frequencies	.frq	包含每个term词和词频的文档列表
Positions	.prx	存储term词在索引出现的位置信息
Norms	.nrm	文档和字段的编码长度以及提升因子
Term Vector Index	.tvx	存储文档数据文件的偏移量
Term Vector Documents	.tvd	包含有关具有词项的文档信息
Term Vector Fields	.tvf	字段级别的词向量信息
Deleted Documents	.del	被删除的字段信息

4.2 TongSearch快照仓库数据存储结构

目录文件说明如下：

文件名或目录	作用
index-0	记录所有快照索引的元数据
index.latest	记录最新的快照信息
indices/ 目录	存放所有快照的索引数据文件（实际索引数据）
meta-xxx.dat	存储快照的元数据，描述索引及分片的状态
snap-xxx.dat	存储实际的快照数据，包含索引的 segment 文件及内容

备份索引index1后，快照仓库目录如下所示：

[root@ct2 pathrepo]# ll
total 20
-rw-rw-r-- 1 es es  632 Apr 11 11:10 index-0
-rw-rw-r-- 1 es es    8 Apr 11 11:10 index.latest
drwxrwxr-x 3 es es 4096 Apr 11 11:09 indices
-rw-rw-r-- 1 es es  256 Apr 11 11:10 meta-xz4EoNOwQWu4f1TT9uKWCg.dat
-rw-rw-r-- 1 es es  364 Apr 11 11:10 snap-xz4EoNOwQWu4f1TT9uKWCg.dat
[root@ct2 pathrepo]# cd indices/
[root@ct2 indices]# ll
total 4
drwxrwxr-x 3 es es 4096 Apr 11 11:10 3d8rubPRTHqjCRBmto8eBA
[root@ct2 indices]# cd 3d8rubPRTHqjCRBmto8eBA/
[root@ct2 3d8rubPRTHqjCRBmto8eBA]# ll
total 8
drwxrwxr-x 2 es es 4096 Apr 11 11:10 0
-rw-rw-r-- 1 es es 1075 Apr 11 11:10 meta-Ik7TIpYBzoenrSM9aIUJ.dat
[root@ct2 efDP5cZfSW2kea77kpdnwg]# cd 0/
[root@ct2 0]# ll
total 248
-rw-rw-r-- 1 es es    479 Apr 11 11:16 __9ZFwKaXRQ6ejdBy0-Vap9w
-rw-rw-r-- 1 es es 108681 Apr 11 11:16 __efXr-zh3S-utCuhPhDuvvg
-rw-rw-r-- 1 es es    479 Apr 11 11:16 __G9d-Wp3cRjqD-Un1so3HQQ
-rw-rw-r-- 1 es es    479 Apr 11 11:16 __h-EezOjsS1KrO4O9DMU5lg
-rw-rw-r-- 1 es es   5335 Apr 11 11:16 index-WyVrtrrfStqptzSNem9O_A
-rw-rw-r-- 1 es es    479 Apr 11 11:16 __JO6rhmn3TCaSv5pTH24qbw
-rw-rw-r-- 1 es es  13129 Apr 11 11:16 __LFfAzDM3RsCwWvr-YXc0Bg
-rw-rw-r-- 1 es es    479 Apr 11 11:16 __mKErZsQmTX-wMjvMG0c7MA
-rw-rw-r-- 1 es es  17556 Apr 11 11:16 __nGdd8Xc2Q5Ow_O7tS5bQjQ
-rw-rw-r-- 1 es es  15392 Apr 11 11:16 __PJHuapyiR8mYGU-jstH96w
-rw-rw-r-- 1 es es  26928 Apr 11 11:16 __rylNwcUyQgifH-ZYibDqYQ
-rw-rw-r-- 1 es es   4864 Apr 11 11:16 snap-qlr4DJvsRs-MSfmQXTR15A.dat
-rw-rw-r-- 1 es es    479 Apr 11 11:16 __trCMUTQmRSSGMw5LI311_A
-rw-rw-r-- 1 es es  19958 Apr 11 11:16 __zUz9EllBTwiPfPDHcqDCtA

接下来，我们在相同快照仓库下新建index2索引备份，快照仓库目录如下所示：

[root@ct2 pathrepo]# ll
total 28
-rw-rw-r-- 1 es es 1070 Apr 11 11:16 index-1
-rw-rw-r-- 1 es es    8 Apr 11 11:16 index.latest
drwxrwxr-x 4 es es 4096 Apr 11 11:16 indices
-rw-rw-r-- 1 es es  256 Apr 11 11:16 meta-qlr4DJvsRs-MSfmQXTR15A.dat
-rw-rw-r-- 1 es es  256 Apr 11 11:10 meta-xz4EoNOwQWu4f1TT9uKWCg.dat
-rw-rw-r-- 1 es es  360 Apr 11 11:16 snap-qlr4DJvsRs-MSfmQXTR15A.dat
-rw-rw-r-- 1 es es  364 Apr 11 11:10 snap-xz4EoNOwQWu4f1TT9uKWCg.dat
[root@ct2 pathrepo]# cd indices/
[root@ct2 indices]# ll
total 8
drwxrwxr-x 3 es es 4096 Apr 11 11:10 3d8rubPRTHqjCRBmto8eBA
drwxrwxr-x 3 es es 4096 Apr 11 11:16 efDP5cZfSW2kea77kpdnwg
[root@ct2 indices]# cd 3d8rubPRTHqjCRBmto8eBA/
[root@ct2 3d8rubPRTHqjCRBmto8eBA]# ll
total 8
drwxrwxr-x 2 es es 4096 Apr 11 11:10 0
-rw-rw-r-- 1 es es 1075 Apr 11 11:10 meta-Ik7TIpYBzoenrSM9aIUJ.dat

我们可以发现仓库新增了index2索引的备份信息.dat文件，更新了包括index-0为index-1，记录最新的快照信息index.latest，indices目录下新增了备份的索引数据。

4.3 备份原理分析

当发起备份快照请求至快照备份完成大致分为以下几个阶段：
请求解析阶段

1. 获取快照备份请求，解析快照备份语句，创建快照备份请求。
2. 备份请求创建后，TongSearch首先会对repository进行合规检查，状态检查。
3. 解析请求中的indices表达式，加载请求中指定的各类参数，加载插件状态；

请求构造阶段

1. 构造snapshot request，将通过客户端提交的备份请求解析为用于在TongSearch中执行的请求语句。
2. 初始化备份请求，主要进行快照ID的生成，监听器的注册，repository元数据的加载等。

请求准备阶段

1. 首先对snapshot request中的快照进行验证，判断是否已经存在或已经有同名snapshot处于流程中的状态。
2. 开始执行snapshot backup任务，需要对repository metadata进行校验，判断snapshot name在repository中的可用性。校验任务并发数是否超过参数值限制。
3. 获取snapshot中涉及到的indices列表，准备相关shard metadata与shard data。
4. 创建快照条目集合，开始维护快照状态。

请求执行阶段

1. 获取已经校验完成的index shard ID。
2. 检查获取的index shard是否为primary shard。这是因为快照仅作用于primary shard。
3. 检查index shard当前的状态，是否允许进行snapshot操作。当需要备份的shard处于relocating或recovering状态时进行backup操作时会发生冲突。
4. 获取snapshot中包含的indices的shard的底层segment文件和metadata文件。以Stream的方式将数据文件写入至远程repository。
5. 在snapshot backup Task执行期间，ActionListener会对备份请求的状态进行持续的监听。

请求完成阶段

1. 当有index shard备份完成后，快照进程会调用方法像集群中的master node 同步已经完成的shard信息，并发送完成的状态。同时向master node同步分片所在节点的shard备份状态。
2. 向shard所在节点更新特定快照的备份状态。
3. 接收ActionListener返回的回调信息并进行处理。
4. 当快照中所有的shard全部备份完成，状态全部更新完成后，snapshot backup进程会释放所占用的shard资源。TransportService threadpool也将结束对于snapshot相关thread的维护工作。

4.4 思考与总结

• 主节点将快照命令放到集群状态中广播下去，以此控制数据节点执行任务。数据节点执行完毕向主节点主动汇报状态。
• 快照写入了两个层面的元数据信息：集群层（集群元数据）和索引层（索引模版/别名）。
• 快照与集群是否健康无关，集群Red时也可以对部分索引执行快照备份。
• 数据复制过程中会计算校验和，确保复制后数据的正确性。
• 数据节点并发复制数据时取决于线程池的线程数的最大值，该值为min(5，(处理器数量)/2)。
• 快照只对主分片执行，在快照备份时，所有的分片分配相关功能都会被暂停。
• 快照备份过程中，集群宕机或取消备份后，再次执行备份不会延续之前的进度，会重新开始备份。
• 删除历史快照会对新的快照造成影响吗？不会，仅删除没有被任何快照引用的文件。
• 恢复完整数据的时候要如何恢复？需要从第一个快照开始一个一个恢复吗？从最新的开始恢复即可。
• 对一个正在恢复的索引删除会发生什么？恢复会停止，如果关闭索引，会关闭失败。
• 同一索引的同时备份，与同时恢复。快照备份，可以多个备份同时进行。恢复时，一个索引只能同时被一个快照恢复。