增量备份为什么还是这么慢?KingbaseES块级永久增量备份给出答案!

增量备份比全量备份还"心虚"作为 DBA,你一定经历过这样的尴尬时刻:
“今天是增量备份日,预计耗时……嗯……大概两个小时吧.”
“增量?全量才两个半小时啊?”
“对……差不多吧.”
这并非段子.在传统数据库的增量备份方案中,增量备份的实际空间占用和耗时,往往逼近甚至接近全量备份.原因在于:大多数"增量"备份的最小粒度是文件或表空间级别,哪怕文件中只有几 KB 的数据发生了变化,整个文件(通常是几百 MB甚至几GB)也要完整备份一次.
对于TB级的数据库和热点频繁更新的场景,这个问题被进一步放大.每天几百万笔交易,修改的数据块散落在数百个文件中——传统的文件级增量备份,本质上就是把大部分没变动的数据再拷一遍.
金仓数据库在 V9R4C19 版本中推出了块级永久增量备份(Block-Level Permanent Incremental Backup),从根本上改变了增量备份的粒度模型.本文将从原理、实测和运维实践三个维度,完整解读这项特性.废话不多说,下面跟着小编的节奏🎵一起去疯狂的学习吧!

1.核心能力概况

2.原理深度解析

2.1传统增量备份为什么"不增量"?

传统的增量备份通常以文件为最小单元:

全量备份：拷贝所有数据文件 → 2043 GB 增量备份：拷贝有变更的数据文件 → 文件哪怕只改了 1 个字节，整个文件也要拷 结果 → ~2000 GB（几乎没有减少）

这就好比你去超市,只买了两瓶水,但结账时要求你把整个购物车里所有的东西重新扫码一遍.

2.2KingbaseES如何做到8KB块级增量?

金仓的块级增量备份将最小粒度从"文件"缩小到8KB 数据块：

全量备份：拷贝所有 8KB 数据块 → 2043 GB 增量备份：只拷贝发生变化的 8KB 块 → 150~300 GB（具体取决于业务变更率）

这就像超市的智能结算——只扫你真正购买的商品.

技术实现

┌─────────────────────────────────────────────────────┐ │ KingbaseES 实例 │ │ │ │ ┌──────────────┐ ┌─────────────┐ │ │ │ ktrack 插件 │───→│ 块变更追踪表 │ │ │ │ (跟踪变化) │ │ (哪些块变了) │ │ │ └──────────────┘ └──────┬──────┘ │ │ │ │ │ ┌───────────────────────────▼──────────────┐ │ │ │ 备份引擎 │ │ │ │ 1. 读取变更追踪信息 │ │ │ │ 2. 只拷贝变更的 8KB 块 │ │ │ │ 3. 生成增量备份集 │ │ │ └───────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────┐ │ │ │ 备份集合并引擎 │ │ │ │ F + P1 + P2 → 新 F1（压扁引用链） │ │ │ │ 类似 Git 的 commit squash │ │ │ └───────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────┘

关键组件包括：

1. ktrack 插件：跟踪每个 8KB 数据块的变化状态.每当一个数据块被修改(脏写),插件会在变更追踪表中标记该块.
2. 差异 + 引用链机制：类似 Git 的版本管理.每个增量备份集包含变更块的快照,并引用之前备份集中未变化的块.通过引用链,任何一个时间点的备份集都可以还原出完整的数据库状态.
3. 备份集合并：当引用链过长时,通过合并操作将多个增量备份集与基础全量备份集合并为新的全量备份,"压扁"引用链.这与Git中的squash 操作异曲同工.

2.3永久增量:为什么不再需要周期性全量备份？

传统备份策略通常遵循这样的周期:

周日：全量备份 周一：增量备份 周二：增量备份 周三：增量备份 ... 下周日：再来一次全量备份（因为增量链太长，合并/恢复代价太高）

而块级永久增量备份打破了这个循环：

Day 0：全量备份（F） Day 1：增量备份（P1）——只含变更块 Day 2：增量备份（P2）——只含变更块 Day 3：增量备份（P3）——只含变更块 Day N：增量备份（Pn）——只含变更块 ... 定期：F + P1 + ... + Pk → 新 F1（备份集合并，后台异步执行）

永久增量的核心意义在于：你不再需要周期性地停止增量备份链、重新做全量备份.备份集合并可以在后台异步进行,对在线业务几乎无感知.

3.实测数据:2TB 数据库备份空间省80%、速度快60%

以下实测基于2TB数据库,每天约200GB数据变更的场景：

换算为百分比：

场景分析
块级增量备份在以下场景中优势尤其明显:

• TB 级数据库：数据量越大,文件级增量的冗余越多,块级增量的收益越显著
• 热点频繁更新：高并发OLTP 场景中,变更集中在部分热点数据块,大部分块长期不变
• 备份窗口紧张：增量备份速度提升60%,为业务高峰留出更多可用时间
• 存储成本敏感：节省80%备份空间,直接降低存储采购成本

4.配置实践:如何开启、合并与恢复？

4.1开启块级增量备份

-- 在 kingbase.conf 中设置以下参数_continue_incr=y-- 启用连续增量模式_incr_type=page-- 增量类型为页（块）级别

注意：这两个参数以_开头,表示它们是实验性或高级特性参数,需要在评估后谨慎启用.

4.2备份集合并操作

# 使用 sys_rman 工具执行备份集合并# 将基础全量备份 F 与增量备份 P1、P2 合并为新的全量备份 F1sys_rman merge --backup-dir=/path/to/backup\--target-backup=F\--incremental-backups=P1,P2

合并操作是后台异步执行的,不会阻塞在线业务.建议在业务低峰期执行.

4.3恢复示例

# 从块级增量备份恢复sys_rman restore --backup-dir=/path/to/backup\--target-time="2026-04-24 14:00:00"

恢复引擎会自动沿着引用链找到目标时间点所需的所有块,拼装出完整的数据库状态.

5.落地前需要关注哪些限制?

运维建议

1. 定期合并备份集：虽然支持永久增量,但建议定期(如每周)合并备份集,避免引用链过长影响恢复速度
2. 选择合适的合并窗口：合并操作消耗 I/O 资源,建议在业务低峰期执行
3. 监控 ktrack 插件状态：确保变更追踪插件正常运行,否则增量备份将退化为全量
4. 恢复演练：定期执行恢复演练,验证块级增量备份的可用性

6.对比传统方案:块级增量到底强在哪?

7.总结

金仓数据库 V9R4C19 的块级永久增量备份,通过三项核心技术解决了长期困扰 DBA 的备份难题：

• 8KB 块级粒度：将备份单位从文件缩小到数据块,只拷贝真正变化的数据
• 永久增量模型：打破全量-增量的周期循环,一直做增量、不再需要定期全量
• 备份集合并：类似 Git 的引用链压扁机制,异步合并,不阻塞在线业务

对于 TB 级数据库和高并发更新场景,存储空间节省 80%、备份速度提升 60%的实测数据,意味着更低的运维成本和更短的业务恢复时间.如果你还在为"增量备份慢得像全量"而头疼,这项特性值得认真评估.

敬请期待下一篇文章内容的更新

每日心灵鸡汤:你知道你为什么总是内耗吗?
因为你太有良心了,太给这个世界面子了,太把别人当回事了,太在乎别人的感受了,但是你知道吗?有时候太在乎别人的感受会迷失自我的,这个世界形形色色的人太多了,所以你完全没必要处处为别人着想,也没有必要为了别人而委屈你自己,与其内耗自己,不如发疯创飞所有人,你要明白你是为你自己而活的,所以你就不要为了别人而委屈自己,也不要再把眼泪流给不值得的人了,更不要让随随便便的一个人就影响你的情绪了,你就凡事多为自己考虑,多为自己而活.希望你能够停止内耗,能够去接纳自己,能够去寻回真正的自己.