备份是数据库运维中绕不开的话题。对于一个生产环境的Oracle数据库来说，数据量往往以百GB甚至TB计，如果每天都执行全量备份，不仅备份窗口难以承受，存储成本也会直线上升。Oracle提供的增量备份机制正好解决了这个问题：它只备份自上次备份以来发生变化的数据块，跳过未修改的部分，从而把备份时间和空间压缩到一个可控的范围内。本文将从增量备份的原理入手，详细讲解差异增量与累计增量的区别，并结合RMAN给出可以直接落地的配置方案。
一、增量备份的基本原理：为什么0级备份不可或缺
Oracle的增量备份基于数据块级别的变化追踪。数据库的最小I/O单位是数据块，当某个块中的数据被修改后，这个块就被标记为“已变更”。增量备份做的事情，就是把这些变更过的块复制出来，而不是整库扫描复制。这样一来，一张几百万行记录的表哪怕只更新了一行，备份时也只会读取包含该行的那几个块，效率提升非常明显。
这里必须先澄清一个关键概念：增量备份必须建立在0级备份（Level 0）的基础之上。0级备份相当于一个“基线”，它备份的是执行时刻数据库中所有已使用的数据块，作用等同于全量备份，但它与全量备份有一个本质区别——全量备份不能作为增量备份的基础，0级备份才可以。很多刚接触RMAN的朋友会直接执行backup database做全量，之后又执行1级增量，结果恢复时发现增量备份根本无法应用，原因就在这里。正确的做法是先执行一次0级备份：
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG DELETE INPUT;
有了0级备份这个基线之后，后续的1级增量备份都只备份基线之后发生变化的块。如果长期不做新的0级备份，增量备份的链条会越来越长，恢复时需要依次应用每一次增量，恢复时间会随之增加，因此0级备份需要定期重新生成，一般建议每周或每两周做一次，具体频率取决于业务的数据变更量和对恢复时间的要求。
二、差异增量与累计增量：两种策略的取舍
Oracle的1级增量备份分为两种：差异增量备份（Differential）和累计增量备份（Cumulative）。差异增量备份的是自最近一次0级或1级备份以来变化的块；累计增量备份的则是自最近一次0级备份以来所有变化的块，无论中间做过多少次1级备份。两者在RMAN中的写法只差一个关键字：
-- 差异增量备份（默认方式） RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE; -- 累计增量备份 RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
举一个具体的例子来说明区别。假设周日凌晨做了0级备份，周一到周六每天各做一次1级增量。如果采用差异增量，周四的备份只包含周三到周四之间变化的块；恢复时需要按顺序应用周一、周二、周三、周四这四个增量备份。如果采用累计增量，周四的备份则包含周日到周四之间所有变化的块，恢复时只需要应用周四这一个增量备份即可。
从这个例子可以看出两种策略的权衡点：差异增量每次备份的数据量小、备份速度快，但备份链条长，恢复时步骤多、耗时长，而且中间任何一次备份损坏都会影响恢复；累计增量正好相反，恢复简单快速，但如果数据每天变更量很大，后期的累计备份体积会逐渐膨胀，接近重新做一次全量。生产环境中，如果更看重备份窗口短，通常选差异增量；如果对恢复时间（RTO）要求苛刻，比如要求一两小时内必须恢复完毕，累计增量或者干脆缩短0级备份周期会更稳妥。
三、启用块变更跟踪，让增量备份快起来
在没有开启块变更跟踪（Block Change Tracking）的情况下，RMAN做增量备份时仍然需要扫描整个数据文件的所有数据块，通过读取块头的SCN来判断块是否发生变化。也就是说，虽然备份出来的数据量小了，但读取的物理数据量并没有减少，对于超大数据库来说增量备份依然很慢，这就失去了增量的意义。
块变更跟踪功能通过一个专门的跟踪文件解决这个问题。数据库后台的CTWR进程会把变更块的位置实时记录到这个文件里，RMAN做增量备份时直接读取跟踪文件，就能精确定位哪些块需要备份，完全跳过未变更的块，备份速度可以提升数倍甚至数十倍。开启方式非常简单：
-- 查看是否已启用（STATUS为DISABLED表示未启用） SQL> SELECT status, filename FROM v$block_change_tracking; -- 启用块变更跟踪，指定跟踪文件位置 SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING 2 USING FILE '/u01/app/oracle/bct/rman_change_trk.dbf'; -- 如需重置跟踪文件大小 SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/app/oracle/bct/rman_change_trk.dbf' REUSE;
需要注意的是，跟踪文件本身会占用少量空间（初始约10MB以上，随数据量增长），并且需要存放在可靠存储上。如果做过0级备份之后才启用跟踪，第一次增量备份仍然需要全扫描，从第二次开始才能享受加速效果。另外在Data Guard环境中，物理备库也可以启用块变更跟踪来做增量备份，从而把备份压力从主库卸载掉，这是很多企业常用的架构手法。
四、一套可落地的自动化备份方案
讲了这么多原理，最终还是要落到具体的执行计划上。下面给出一套常见的组合策略：每周日做0级备份，周一到周六做差异增量，归档日志每次随备份一起处理并删除已备份的，保留策略设置为保留最近两周的恢复能力。
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/%F';
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/db_%U';
-- 每周日的0级备份脚本 level0.rman
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
BACKUP INCREMENTAL LEVEL 0
DATABASE PLUS ARCHIVELOG
DELETE ALL INPUT;
DELETE NOPROMPT OBSOLETE;
RELEASE CHANNEL c1;
RELEASE CHANNEL c2;
}
-- 周一到周六的增量备份脚本 level1.rman
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
BACKUP INCREMENTAL LEVEL 1
DATABASE PLUS ARCHIVELOG
DELETE ALL INPUT;
DELETE NOPROMPT OBSOLETE;
RELEASE CHANNEL c1;
}
脚本写好后放到crontab中定时执行即可，例如周日凌晨一点执行0级备份，其他每天凌晨一点执行增量备份：
0 1 * * 0 su - oracle -c "rman target / cmdfile=/home/oracle/scripts/level0.rman log=/backup/logs/level0_`date +\%Y\%m\%d`.log" 0 1 * * 1-6 su - oracle -c "rman target / cmdfile=/home/oracle/scripts/level1.rman log=/backup/logs/level1_`date +\%Y\%m\%d`.log"
这套方案里有几个细节值得注意。一是CONTROLFILE AUTOBACKUP一定要开启，这样控制文件和spfile会随备份自动保存，恢复时才不会丢失备份记录；二是归档日志必须纳入备份并删除已备份部分，否则归档目录写满会导致数据库挂起；三是备份完成后要检查日志中的ORA错误，很多备份故障都是静默失败的，等到真正要恢复时才发现备份不可用，为时已晚。有条件的话还应该定期在测试环境做恢复演练，一个从未验证过可恢复性的备份策略，本质上等于没有备份。
五、增量备份的恢复思路
备份的最终目的是恢复。基于增量备份的恢复过程大致是：先恢复0级备份，再按时间顺序依次应用各级增量备份，最后应用归档日志和联机重做日志把数据库推进到故障时刻。如果使用了恢复目录（Recovery Catalog），RMAN可以自动完成整个编排：
RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE; RMAN> ALTER DATABASE OPEN;
如果控制文件也丢失了，则需要先从自动备份中恢复控制文件，再执行上述步骤。整个过程看起来简单，但强烈建议把恢复步骤写成文档并在测试库演练通过，因为真实故障发生时往往伴随着时间压力，临时翻资料查语法的代价非常高。另外，从Oracle 12c开始还提供了增量更新备份（Incrementally Updated Backup）技术，通过RECOVER COPY OF DATABASE命令把增量备份直接合并到之前的镜像副本中，使镜像副本始终保持接近最新状态，恢复时只需应用少量归档日志，感兴趣的话可以在此基础上进一步研究，它是大库场景下兼顾备份窗口和恢复速度的利器。
Oracle增量备份RMAN备份策略数据库备份恢复修改时间：2026-09-06 15:02:47