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 GB205 分钟基准文件级增量~2000 GB~200 分钟几乎等同于全量块级增量150~300 GB60~120 分钟仅变更块换算为百分比指标改善幅度存储空间节省近80%备份耗时加速近60%场景分析块级增量备份在以下场景中优势尤其明显TB 级数据库数据量越大文件级增量的冗余越多块级增量的收益越显著热点频繁更新高并发 OLTP 场景中变更集中在部分热点数据块大部分块长期不变备份窗口紧张增量备份速度提升 60%为业务高峰留出更多可用时间存储成本敏感节省 80% 备份空间直接降低存储采购成本配置与操作开启块级增量备份-- 在 kingbase.conf 中设置以下参数_continue_incry-- 启用连续增量模式_incr_typepage-- 增量类型为页块级别注意这两个参数以_开头表示它们是实验性或高级特性参数需要在评估后谨慎启用。备份集合并操作# 使用 sys_rman 工具执行备份集合并# 将基础全量备份 F 与增量备份 P1、P2 合并为新的全量备份 F1sys_rman merge --backup-dir/path/to/backup\--target-backupF\--incremental-backupsP1,P2合并操作是后台异步执行的不会阻塞在线业务。建议在业务低峰期执行。恢复示例# 从块级增量备份恢复sys_rman restore --backup-dir/path/to/backup\--target-time2026-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%的实测数据意味着更低的运维成本和更短的业务恢复时间。如果你还在为增量备份慢得像全量而头疼这项特性值得认真评估。