• 先用一张图说明一下常见的备份方式
  

为什么需要永久增量备份

传统的数据库备份方案通常是间隔7天对数据库做一次全量备份（完整备份），每天会基于全量备份做一次增量备份，如此循环，这种备份方案在全备数据量过大场景下可能遇到如下问题：
每周的全量备份像一场“资源风暴”——磁盘I/O打满、业务响应延迟飙升，备份耗时长…
直到遇到永久增量备份，我才发现，原来备份可以如此“优雅”。今天，就带大家深入它的技术内核，看看它是如何用“一次全量+智能合并”颠覆传统逻辑的。

---

一、永久增量备份技术解剖

核心逻辑：“用计算换存储，用合并替全量”

1. 初始全量（Day 1）

   • 像给数据库拍一张“全景照片”，记录所有数据的初始状态。

2. 每日增量（Day 2~7）

   • 只记录变化的数据或数据块，类似Git的差异提交。 金仓数据库支持文件级别的增量备份和块级别的增量备份
     • 举例：若一个1TB的数据库每天仅1%数据变化，增量文件只需约10GB。

3. 智能合并（Day 8）

   • 最精彩的魔法：将Day 1的全量 + Day 2~7的增量合并为新的全量备份。
   • 合并过程解析（伪代码逻辑）：

     def 合并全量(old_full, increments):  
         new_full = old_full.copy()  
         for inc in increments:  
             new_full.apply_diff(inc)  # 将增量差异应用到旧全量  
         validate(new_full)           # 校验数据一致性  
         return new_full  
     

这里补充说明一下为什么需要做合并而不是持续只做增量备份，核心原因是增量备份越多，数据恢复的迭代恢复过程耗时会很长。

• 优势总结：
  • 新全量直接代表最新数据状态，后续增量只需基于它继续。
  • 旧备份链按需自动清理，清理后存储空间线性增长而非指数爆炸。
  • 无需对数据库进行全量备份，数据库资源消耗下降，业务影响大大降低 。

---

二、金仓数据库如何开启永久增量备份

• 以金仓数据库KINGBASE (KingbaseES) V009R001C002B0014为例：
• 在备份初始化时，可以选择是否开启永久增量备份
  控制参数：修改安装路径/Server/share/sys_backup.conf配置文件中的如下参数
  _continue_incr：是否启用永久增量备份功能，默认n，配置为y则代表开启永久增量备份功能。
  开启之后，定时任务中的全量备份动作，将变更为一次增量备份+合并备份集

# Continue Incr-Backup
# y means Incr-Backup will merge current backup-set and it's reference into one new FULL backup-set
#   merge into FULL applied in crontab-job by _crond_full_days
#   normal Incr-Backup applied in crontab-job by _crond_incr_days
# n means no merge
_continue_incr=n

---

其他配置和操作同普通备份配置一致
手动备份命令示例：

# 合并备份集，但是不移除旧的备份集
/home/kingbase/cluster/project/cluster/kingbase/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase --type=incr --merge_action=merge-no-delete backup

# 合并备份集，并且移除旧的备份集
/home/kingbase/cluster/project/cluster/kingbase/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase --type=incr --merge_action=merge-and-delete backup