备份空间不够用？金仓数据库破局！

 “什么？备份空间不够用了？”金仓大世界的 A 写字楼里，运维人员小王发出一声惊呼，眼前的告警系统变成了不安全的红色，提示某数据库系统备份空间容量不足。小王瞬间冒了一头冷汗，心里盘算：这存储空间之前已经规划过呀，为什么收到空间容量告警呢？如果需要扩容加硬盘的话，加多少合适呢？一边着急分析问题一边开始草拟故障报告……

正当小王一筹莫展之时，看到了办公桌上放着的一份《Kingbase Times》，里面正好摊放着福尔摩斯•K 与华生•K 专题报道，心中一喜，赶紧给两位侦探打去了电话······收到运维员小王的求助电话后，福尔摩斯•K 与华生•K 立即驱车赶往了现场。

华生•K 通过现场勘察发现：

• 该公司数据库系统预留 8T，data 目录存量数据有 2TB，近期的增量估算后续每天会有 10GB 的数据量，预留的存储容量至少满足 1 年的业务增长需求，无需扩容。

• 该公司针对数据库备份空间预留 16T，如今占用 15T 只剩余 1T 容量，触发低于 10%容量告警。

正当华生•K 低头思考之时，福尔摩斯•K 指出问题所在：“业务系统要求保留 1 个月的数据，按照以往的物理备份策略，周日凌晨做全量备份，周一到周六做增量备份，以当前系统每次备份的存储容量做预估，大概需要存储容量 49.4TB，当前预留的 16T 容量当然会告警了！”

华生·K 不解地问：“使用 49TB 的存储空间来保障一个 2TB 数据量的数据库系统，性价比实在是太低了。为什么需要这么多存储空间啊？”，随后盯着福尔摩斯•K 甩出的存储空间预估表格，眼前一亮，“原来一次增量备份竟然需要占用 1TB 的存储呀，可明明每天只有 10GB 的数据量啊！”，华生·K 抬头看向福尔摩斯•K，眼神带有疑惑。

福尔摩斯•K 一边在终端上噼里啪啦地执行着各种查询，一边解释道：“这个业务系统除了增量数据较多以外，同时还伴随着热点数据的频繁更新，这样就会导致大量表文件的小部分数据发生了改变，最终发生改变的文件是很多的，而现有的增量备份是文件级的增量备份，它会拷贝自上次备份以来发生改变的所有文件，无论是有大量新增数据的表文件还是只有一条记录变更的表文件都会被备份。”

“我们需要降低每次备份时的粒度，从文件级别降低到每次修改的数据块级别…… 在保证可用性的基础上，降低存储空间的要求是关键！所以······”

华生·K 恍然大悟，打断福尔摩斯•K 抢答：：“金仓 KingbaseES 数据库就能够实现！”

华生·K 接着解释道：“KingbaseES 数据库自带的物理备份工具 sys_rman 支持块级别的增量备份，备份粒度只有 8KB，只会备份发生改变的数据块。同时，KingbaseES 数据库提供永久增量备份方案，该方案将连续的块增量备份集合做合并，适应数据库动态变化频繁、备份窗口严格控制，同时寻求降低存储成本支出的场景，可完美解决刚才的问题。”

Part.1 全量备份初始化

首先完成 KingbaseES 数据库物理备份的初始化部署，部署时会自动启用数据块动态变化追踪功能（如图），并自动触发一次全量备份，以构建一个包含所有当前数据的基线，为后续备份提供基础副本。

Part.2 持续差异性块级别增量备份

后续默认每天都做块级别增量备份，块级别增量备份仅捕获自上次备份以来发生变化的数据块，无论数据库如何膨胀，仅需记录增量部分，极大削减了存储占用，同时减少了备份时间。之前文件级别增量备份集是 1TB，而现在块级别增量备份集只需要 10GB 即可。

Part.3 备份集合并成全量备份集

永久增量备份方案内置周期性（默认七天）备份集合并机制，将最近的全量备份集与累计的块级别增量备份集合并，生成新的全量备份集，旨在优化恢复速度。

福尔摩斯•K 接着补充道：“借助 KingbaseES 数据库的永久增量备份方案，小王只需要 11.6TB 即可保障一个月恢复窗口的存量数据 2TB 日增量 10GB 的数据库系统，预计可以比原方案缩减 76.5%的存储空间要求。”随后，他重新绘制了一个使用 KingbaseES 容量的预估表格。

小王有点兴奋，说道：“我现在就去申请安装 KingbaseES 数据库！眼见为实！”

很快，小王安装好 KingbaseES 数据库后就开始针对永久增量备份方案做实际的测试了，选择测试工具 benchmarksql：它构建了一个典型的应用场景，包含多张表和其索引，在 TPCC 测试时会触发主要业务逻辑，造成几张关键表数据和索引的变化，这与实际应用系统场景是基本匹配的。

该方案的实际表现究竟如何，让我们拭目以待。

1. 灌入 2TB 的基础数据，部署物理备份，完成一次全量备份，作为永久增量备份的基础备份集。

2. 跑 TPCC 测试，观察归档日志量，在归档目录容量增加了 10GB 时，停止 TPCC 测试，执行块增量备份，类似于实际环境时一天的增量后进行凌晨块增量备份。

3. 反复步骤 2，做 TPCC 测试构造 10GB 增量数据，再做块增量备份，模拟实际环境中的每天业务增量和自动块增量备份。

测试结果出炉，现在来看一下针对小王业务场景模拟的数据表现：

通过实测可以看出，永久增量备份方案每天增量备份的数据量大小仅有 12GB，比之前的 1T 下降 98%，确实是极大地减少了存储空间的占用，同时也缩减了每次备份的时间，是解决该应用系统物理备份存储空间占用问题的不二首选。

小王惊叹不已，说道：“这也太棒了，金仓数据库在数据保护策略上，省成本、智能化、高效率，解决了燃眉之急！”

针对业务场景特点总结

• 热点数据遍布大部分用户表，非集中特定表。

• 一定周期内，做更新、插入、删除操作散布均匀，在热点表中均有改写。

• 数据库系统的数据量规模在 TB 级别，存在大量的历史数据和现有数据。

• 物理备份的耗时和存储空间占用要求高。

金融、运营商、电子商务、社交媒体等是频繁更新用户数据、交易数据或实时数据的行业，针对上述特点的业务系统，金仓 KingbaseES 基于数据块级别的永久增量备份方案可以解决存储空间占用大和备份耗时久的痛点，常规可以节省近 80%的备份存储空间，加速 60%时间完成物理备份。

未知的世界隐藏了无尽的秘密，越是深入其中，越能发现更多的可能。解决了运维员小王的困扰后，福尔摩斯•K 与华生•K 驱车离开，奔赴下一场未知的挑战。