2TB 数据库增量备份还要 200GB？KES块级永久增量备份，存储省 80%、速度快 60%
引言：增量备份比全量备份还"心虚"
作为 DBA，你一定经历过这样的尴尬时刻：
“今天是增量备份日，预计耗时……嗯……大概两个小时吧。”
“增量？全量才两个半小时啊？”
“对……差不多吧。”
这并非段子。在传统数据库的增量备份方案中，增量备份的实际空间占用和耗时，往往逼近甚至接近全量备份。原因在于：大多数"增量"备份的最小粒度是文件或表空间级别，哪怕文件中只有几 KB 的数据发生了变化，整个文件（通常是几百 MB 甚至几 GB）也要完整备份一次。
对于 TB 级的数据库和热点频繁更新的场景，这个问题被进一步放大。每天几百万笔交易，修改的数据块散落在数百个文件中——传统的文件级增量备份，本质上就是把大部分没变动的数据再拷一遍。
金仓数据库在 V9R4C19 版本中推出了块级永久增量备份（Block-Level Permanent Incremental Backup），从根本上改变了增量备份的粒度模型。本文将从原理、实测和运维实践三个维度，完整解读这项特性。
核心能力一览
| 能力 | 说明 |
|---|---|
| 块增量备份 | 以 8KB 数据块为最小粒度，只拷贝发生改变的块 |
| 备份集合并 | 连续块备份集定期合并生成新全量，不再需要周期性全量备份 |
| 永久增量 | 理论上可以一直做增量备份，无需周期性地回退到全量 |
原理深度解析
传统增量备份为什么"不增量"？
传统的增量备份通常以文件为最小单元：
全量备份：拷贝所有数据文件 → 2043 GB 增量备份：拷贝有变更的数据文件 → 文件哪怕只改了 1 个字节，整个文件也要拷 结果 → ~2000 GB（几乎没有减少）这就好比你去超市，只买了两瓶水，但结账时要求你把整个购物车里所有的东西重新扫码一遍。
块级增量备份的工作原理
金仓的块级增量备份将最小粒度从"文件"缩小到8KB 数据块：
全量备份：拷贝所有 8KB 数据块 → 2043 GB 增量备份：只拷贝发生变化的 8KB 块 → 150~300 GB（具体取决于业务变更率）这就像超市的智能结算——只扫你真正购买的商品。
技术实现
┌─────────────────────────────────────────────────────┐ │ KingbaseES 实例 │ │ │ │ ┌──────────────┐ ┌─────────────┐ │ │ │ ktrack 插件 │───→│ 块变更追踪表 │ │ │ │ (跟踪变化) │ │ (哪些块变了) │ │ │ └──────────────┘ └──────┬──────┘ │ │ │ │ │ ┌───────────────────────────▼──────────────┐ │ │ │ 备份引擎 │ │ │ │ 1. 读取变更追踪信息 │ │ │ │ 2. 只拷贝变更的 8KB 块 │ │ │ │ 3. 生成增量备份集 │ │ │ └───────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────┐ │ │ │ 备份集合并引擎 │ │ │ │ F + P1 + P2 → 新 F1（压扁引用链） │ │ │ │ 类似 Git 的 commit squash │ │ │ └───────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────┘关键组件包括：
- ktrack 插件：跟踪每个 8KB 数据块的变化状态。每当一个数据块被修改（脏写），插件会在变更追踪表中标记该块。
- 差异 + 引用链机制：类似 Git 的版本管理。每个增量备份集包含变更块的快照，并引用之前备份集中未变化的块。通过引用链，任何一个时间点的备份集都可以还原出完整的数据库状态。
- 备份集合并：当引用链过长时，通过合并操作将多个增量备份集与基础全量备份集合并为新的全量备份，"压扁"引用链。这与 Git 中的 squash 操作异曲同工。
什么是"永久增量"？
传统备份策略通常遵循这样的周期：
周日：全量备份 周一：增量备份 周二：增量备份 周三：增量备份 ... 下周日：再来一次全量备份（因为增量链太长，合并/恢复代价太高）而块级永久增量备份打破了这个循环：
Day 0：全量备份（F） Day 1：增量备份（P1）——只含变更块 Day 2：增量备份（P2）——只含变更块 Day 3：增量备份（P3）——只含变更块 Day N：增量备份（Pn）——只含变更块 ... 定期：F + P1 + ... + Pk → 新 F1（备份集合并，后台异步执行）永久增量的核心意义在于：你不再需要周期性地停止增量备份链、重新做全量备份。备份集合并可以在后台异步进行，对在线业务几乎无感知。
实测数据
以下实测基于 2TB 数据库，每天约 200GB 数据变更的场景：
| 备份方式 | 备份大小 | 备份耗时 | 说明 |
|---|---|---|---|
| 全量备份 | 2043 GB | 205 分钟 | 基准 |
| 文件级增量 | ~2000 GB | ~200 分钟 | 几乎等同于全量 |
| 块级增量 | 150~300 GB | 60~120 分钟 | 仅变更块 |
换算为百分比：
| 指标 | 改善幅度 |
|---|---|
| 存储空间 | 节省近80% |
| 备份耗时 | 加速近60% |
场景分析
块级增量备份在以下场景中优势尤其明显：
- TB 级数据库：数据量越大，文件级增量的冗余越多，块级增量的收益越显著
- 热点频繁更新：高并发 OLTP 场景中，变更集中在部分热点数据块，大部分块长期不变
- 备份窗口紧张：增量备份速度提升 60%，为业务高峰留出更多可用时间
- 存储成本敏感：节省 80% 备份空间，直接降低存储采购成本
配置与操作
开启块级增量备份
-- 在 kingbase.conf 中设置以下参数_continue_incr=y-- 启用连续增量模式_incr_type=page-- 增量类型为页（块）级别注意：这两个参数以
_开头，表示它们是实验性或高级特性参数，需要在评估后谨慎启用。
备份集合并操作
# 使用 sys_rman 工具执行备份集合并# 将基础全量备份 F 与增量备份 P1、P2 合并为新的全量备份 F1sys_rman merge --backup-dir=/path/to/backup\--target-backup=F\--incremental-backups=P1,P2合并操作是后台异步执行的，不会阻塞在线业务。建议在业务低峰期执行。
恢复示例
# 从块级增量备份恢复sys_rman restore --backup-dir=/path/to/backup\--target-time="2026-04-24 14:00:00"恢复引擎会自动沿着引用链找到目标时间点所需的所有块，拼装出完整的数据库状态。
约束与注意事项
| 约束项 | 说明 |
|---|---|
| 不支持压缩 | 块级增量备份目前不支持压缩格式 |
| 不支持加密 | 备份集不支持加密存储 |
| HA 场景 | 高可用环境下需手动追加块增量备份，暂不支持自动同步 |
运维建议
- 定期合并备份集：虽然支持永久增量，但建议定期（如每周）合并备份集，避免引用链过长影响恢复速度
- 选择合适的合并窗口：合并操作消耗 I/O 资源，建议在业务低峰期执行
- 监控 ktrack 插件状态：确保变更追踪插件正常运行，否则增量备份将退化为全量
- 恢复演练：定期执行恢复演练，验证块级增量备份的可用性
与竞品的对比
| 特性 | KingbaseES V9R4C19 | 传统方案 |
|---|---|---|
| 增量备份粒度 | 8KB 块级 | 文件级 |
| 备份空间（2TB 场景） | 150~300 GB | ~2000 GB |
| 备份耗时（2TB 场景） | 60~120 分钟 | ~200 分钟 |
| 永久增量 | 支持 | 需定期全量 |
| 备份集合并 | 支持（类似 Git squash） | 不支持 |
总结
金仓数据库 V9R4C19 的块级永久增量备份，通过三项核心技术解决了长期困扰 DBA 的备份难题：
- 8KB 块级粒度：将备份单位从文件缩小到数据块，只拷贝真正变化的数据
- 永久增量模型：打破全量-增量的周期循环，一直做增量、不再需要定期全量
- 备份集合并：类似 Git 的引用链压扁机制，异步合并，不阻塞在线业务
对于 TB 级数据库和高并发更新场景，存储空间节省 80%、备份速度提升 60%的实测数据，意味着更低的运维成本和更短的业务恢复时间。如果你还在为"增量备份慢得像全量"而头疼，这项特性值得认真评估。
