接手过不少 RMAN 环境之后我越来越觉得备份脚本本身不难写难的是把“增量备份的依赖关系”真正理顺。很多 DBA 开口就是“我做了全备、做了增量”但一遇到恢复演练问题就全暴露出来了。今天要聊的这几个点和这个标题直接相关RMAN 0级不等于全备、1级可能和0级一样大但不可用于恢复、备份分片管理以及 delete backup 之后为什么要先安排一次0级备份。这些话看着像绕口令实际上是事故高发区的真实经验总结值得仔细拆一遍。1. 0级备份和全量备份数据块相同身份完全不同1.1 从块的角度看两者确实长得一样先明确一个基础结论BACKUP INCREMENTAL LEVEL 0 DATABASE和BACKUP DATABASE全备在数据块层面做的事情几乎一样——都是把数据文件中所有被使用过的块读出来写入备份集。所以常有人误以为“0级就是全备全备就是0级”从内容上看没问题。但从 RMAN 的管理逻辑和恢复依赖关系上看完全不是一回事。全备在 RMAN 的备份记录里是一个独立可用的完整镜像它的典型标识是FFull。而0级备份是增量备份策略中的“锚点”它的典型标识是0Level 0后续的1级增量备份必须建立在这个锚点之上。你可以用这条命令看备份类型RMAN LIST BACKUP SUMMARY;输出中的 Level 列会明确标出F、0、1。这个区别不是给人看的备注字段而是 RMAN 在做恢复计算时真正使用的依据。1.2 为什么说“0级不等于全备”如果只是磁盘上留下的物理文件两者都是“完整备份”。但在增量恢复链路里只有0级能被当作增量链的父备份。普通全备不能承担这个角色。这意味着什么举个例子某环境每天都执行BACKUP DATABASE同时每天也执行BACKUP INCREMENTAL LEVEL 1 DATABASE。从业务方角度看RMAN 既做了“全备”也做了“增量”感觉天衣无缝。但实际上这个1级增量备份没有对应的0级基础备份它在恢复时根本派不上用场。真正的隐患在于RMAN 执行BACKUP INCREMENTAL LEVEL 1 DATABASE时不一定立刻报错。它可能正常跑、正常生成备份文件甚至在备份集里还记录了完整的检查点S CN。直到你需要恢复时才发现RESTORE DATABASE找不到一个合法的0级备份作为起点于是整个恢复链条断掉。所以我的建议很直接如果打算用增量备份策略就别把普通全备当成“基础备份”用。需要基础备份时明确写成BACKUP INCREMENTAL LEVEL 0 DATABASE。全备可以用于归档日志恢复但不要指望它扛起后续的增量链。提示全备加归档日志是可用组合全备加1级增量不是。0级加1级加归档日志才是正确的增量恢复组合。2. 1级备份为何可能和0级一样大却救不了场2.1 1级备份到底备份了什么RMAN 的1级增量备份分为两种常见形式差异增量Differential备份自最近一次0级或1级备份以来所有发生过变化的块。累积增量Cumulative备份自最近一次0级备份以来所有发生过变化的块。不管哪种核心逻辑都是“只备份变化的块”所以正常情况下1级备份应该明显小于0级。但“正常情况”在真实系统里很短暂。一个繁忙的库尤其是一些在线交易系统或批处理系统每天可能有大范围的数据更新。比如某个大表经常被定时任务整体刷写、大量行被无条件 UPDATE、索引频繁重建、分区表天天做交换分区和合并操作这时候变化块的范围会非常广。当数据库块变化率接近100%时一级备份的内容自然也会接近0级备份的大小。2.2 大小虚胖的本质有的 DBA 会犯一个经验主义错误看到1级备份和0级一样大就认为“既然内容都全了那它应该也能单独用来恢复”。这个想法很危险。1级备份的元数据里清楚地记录着它的父备份信息。它是一份“基于某个0级备份的增量”不是完整的、可独立的备份。就算它碰巧把所有块都包含进来了RMAN 在恢复时也不会把它当成一个独立基础备份来使用。它会去找那个0级父备份找不到就恢复失败。我用一个场景来说明某个 50GB 的数据库周日晚上跑0级备份周一到周五跑1级差异备份。因为业务活动很重周一的1级备份就跑去45GB几乎和0级一样大。周四发现磁盘空间紧张有人把周日的0级备份删了只留下周四的1级备份。这时候有人觉得“反正1级45GB和全备差不多恢复应该没问题吧”真到恢复时就会发现这45GB的备份无法单独恢复数据库因为它不是一个完整的恢复起点。2.3 判断备份可用性不能只看大小判断一个备份能不能用于恢复核心看它的类型和依赖关系而不是看它占用了多少空间。下面这张表值得贴在值班文档里备份组合能否恢复说明全备 归档日志可以全备独立可用配合归档日志可以做恢复全备 1级增量不可以1级增量不属于该全备的增量链0级 1级增量可以1级增量应用在0级基础之上只有1级增量不可以缺少父级0级备份无法作为恢复起点以后看到“1级备份和0级一样大”这类情况不要高兴太早。它只说明系统的变化块很多、增量备份收益在下降不代表备份的安全性提升了。真正要做的是去排查变化率为什么这么高以及增量策略是否需要调整。3. 备份分片并行、切片和恢复依赖3.1 备份集与备份片的关系RMAN 备份里有两个容易混淆的名词备份集Backup Set和备份片Backup Piece。备份集是逻辑概念一次BACKUP DATABASE可能产生一个备份集。备份片是物理文件一个备份集由一个或多个备份片组成。配置了多个通道并行时RMAN 会把备份集拆成多个备份片交给多个通道分别写这样就缩短了备份时间。这个“分片”过程不是随便拆的它受几个因素影响通道个数。每个通道的格式串。备份集大小限制参数比如MAXPIECESIZE。大文件是否使用SECTION SIZE切片。实际查看备份片可以用这条命令RMAN LIST BACKUPPIECE;如果备份文件不在 RMAN 的记录里即使物理文件还摆在磁盘上RMAN 也无法用它做恢复。这一点在手工清理备份时特别容易踩坑。3.2 用多通道给备份“分片”提速最常见的分片方式是加大并行度。比如CONFIGURE DEVICE TYPE DISK PARALLELISM 4; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT /backup/%U MAXPIECESIZE 8G;这样配置之后执行BACKUP DATABASE时RMAN 会尽量把备份内容分散到多个通道。多个备份片同时写入整体耗时往往能明显降下来。需要注意RMAN 默认对单个数据文件不会并行处理。如果一个库里有几个几百GB的大数据文件就算你把并行度调到8单个大文件也可能只由一个通道单独处理其他通道只能干等。解决办法是使用SECTION SIZE。3.3 大文件切片备份对于超大文件RMAN 提供了按区间切分的功能BACKUP DATABASE SECTION SIZE 10G;意思是把每个数据文件按 10GB 一段切分每个段生成独立的备份片可以由不同通道并行处理。这样既能利用并行能力也能把单个备份片控制在一个合理大小方便管理和传输。但切片带来的副作用是恢复时的依赖关系变多了。一个数据文件被切成 N 段恢复时就要把 N 个备份片全部找齐。任何一个切片丢失、损坏、没被CROSSCHECK扫描到都会导致这个数据文件无法完整恢复。所以分片提高的是性能增加的是管理复杂度这两者需要一起考虑。3.4 备份片缺失时的恢复风险有人习惯在操作系统层面直接删掉某些大的备份文件来腾空间但 RMAN 控制文件里的记录还在。这时候做恢复RMAN 会去找一个不存在的备份片然后报文件找不到。正确做法是让 RMAN 重新核对一遍RMAN CROSSCHECK BACKUP; RMAN DELETE EXPIRED BACKUP;这样物理文件和 RMAN 记录才能保持一致。不要直接rm掉备份片除非你已经确认这条备份记录不再需要并且所有依赖它的增量备份也都不需要了。4. delete backup 之后为什么必须先安排0级备份4.1 删除备份不只是删了几个文件DELETE BACKUP在 RMAN 里是一个“重操作”。它会同时处理物理备份片和控制文件里的备份记录。如果误用可能把所有可用备份一次性清掉。但真正危险的场景不是“删得一件不剩”而是“删完之后旧的增量链断了新的基础还没建立”。比如原来有一套备份链0级 1级 1级 1级。为了腾空间执行了一次DELETE BACKUP把历史备份全部删掉。接着备份任务照常触发了一个1级增量备份。这个新的1级备份虽然成功完成但它是一个“孤儿备份”——因为没有0级基础。等到下次恢复时RMAN 对这个1级备份的处理结果就是无法作为独立备份使用同时找不到父级0级备份恢复失败。4.2 为什么 delete obsolete 也会踩雷有人觉得只要用DELETE OBSOLETE而不是DELETE BACKUP就安全了。其实不然。DELETE OBSOLETE是根据保留策略来删除的。假设保留策略是REDUNDANCY 1RMAN 在判断时可能会把已经不具备恢复价值的旧0级备份标记为 obsolete。如果新的0级备份还没完成或者完成得不完整那么旧0级被删掉后后续的1级增量照样会变成孤儿。尤其常见的一种值班顺序错误是早上先 DELETE OBSOLETE 晚上再跑 0级备份 凌晨再跑1级增量在“删除旧0级”到“新0级完成”之间的窗口内如果数据库出了问题你手里只有一堆1级增量和归档日志没有可用的基础备份恢复会非常被动。所以我的操作习惯是先完成新的0级备份并验证通过再执行DELETE OBSOLETE。顺序反过来恢复风险会显著上升。4.3 正确的操作顺序如果你确实想把备份体系整体重置一遍推荐按这个顺序来# 1. 确认当前数据文件状态和数据库可用性 RMAN LIST DATABASE; # 2. 做新的 0 级备份 RMAN BACKUP INCREMENTAL LEVEL 0 DATABASE FORMAT /backup/lv0_%U.bak; # 3. 再做 1 级增量备份如果策略里需要 RMAN BACKUP INCREMENTAL LEVEL 1 DATABASE FORMAT /backup/lv1_%U.bak; # 4. 最后再清理旧备份 RMAN DELETE NOPROMPT OBSOLETE;核心原则就一句话新基础备份安全落地之前旧基础备份绝对不能提前删。如果是因为磁盘空间紧张实在没法先做完0级再删旧备份那也要先把空间问题拆开处理。可以分通道、分文件、分表空间来做0级备份边备份边释放空间但一定要保证在某个时间点有一个完整的0级备份先存在。5. 一套可落地的增量备份与分片策略5.1 备份方案选型根据不同容灾要求RMAN 备份方案通常可以归为三类只做全备 归档日志。做0级 1级差异增量。做0级 1级累积增量。第一种方案简单可靠恢复时直接拿全备做起点配合归档日志恢复。缺点是备份时间长、空间占用大不适合变化量大的库做高频备份。第二种方案最常见周末做0级工作日每天做1级差异。备份窗口短恢复时从0级起步再应用最近一次1级差异最后应用归档日志。第三种方案适合恢复要求更快、不想在恢复时应用太多段1级备份的场景。累积1级的备份内容比差异1级大但恢复时只需要0级 最近一次累积1级链路更短。5.2 关键配置和脚本示例假设数据库每天业务量重但恢复窗口要求比较严格我一般会这样配置RMAN CONFIGURE CONTROLFILE AUTOBACKUP ON; RMAN CONFIGURE RETENTION POLICY TO REDUNDANCY 2; RMAN CONFIGURE DEVICE TYPE DISK PARALLELISM 4; RMAN CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT /backup/%U MAXPIECESIZE 8G;周日0级备份脚本RMAN BACKUP INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG DELETE INPUT FORMAT /backup/lv0_%U.bak;周一到周六1级备份脚本RMAN BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG DELETE INPUT FORMAT /backup/lv1_%U.bak;如果想减少一级备份的大小可以打开变更追踪功能SQL ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;开启之后RMAN 在计算变化块时不需要扫描全表数据文件增量备份速度会快很多二级备份的体积也更容易控制。但要注意这个功能只是提升备份性能不能让1级备份单独用于恢复。备份依赖关系并不会变。5.3 验证备份是否有效很多备份事故不是没做备份而是备份做了但没验证。我习惯在每次备份任务结束后再补一条验证命令RMAN RESTORE DATABASE VALIDATE;这个命令不会真正落盘恢复数据但会检查备份片是否完整、能否被正常读取。如果备份片有损坏这里就能提前暴露而不是等到真出故障时才发现。还可以用RESTORE DATABASE PREVIEW来预览恢复时将使用哪些备份。如果发现恢复计划里缺少预期的0级基础命令会给出明显提示。5.4 恢复演练怎么设计真正检验备份策略是否安全的手段只有恢复演练。我建议在测试环境里做一次完整的“0级 1级 归档日志”恢复记录整个恢复时间、应用的增量备份数量、有没有碰到缺失分片等问题。演练频率不用太高但每次大版本升级、存储变更、备份脚本调整之后都要做。演练时重点看两件事RMAN 是否找到了正确的0级备份。1级备份能否顺利应用到0级之上。如果这两步都顺畅那么这个备份链才是可用的。6. 常见问题与排查技巧实录6.1 备份记录里看不到0级备份执行LIST BACKUP SUMMARY时如果只看到F和1级别的备份说明增量链缺了0。这种情况通常是历史脚本里写的是全备而不是INCREMENTAL LEVEL 0。解决方式很简单手动补一次0级备份或者修改备份脚本把全备命令改成BACKUP INCREMENTAL LEVEL 0 DATABASE。6.2 删除备份后遇到恢复失败某一次值班场景是这样的周一清理磁盘执行了DELETE BACKUP删掉一批旧备份周二早上数据库故障恢复时发现只有周三前的1级增量没有0级基础。恢复命令一直报“找不到可用备份”。排查命令RMAN LIST BACKUP SUMMARY; RMAN LIST BACKUP OF DATABASE;如果发现缺少0级备份而归档日志完整只能从最早的全备如果有加归档日志恢复1级增量备份基本作废。这也是为什么我反复强调删除备份前先确认新基础备份已经生成。6.3 1级备份体积突然变大一级备份异常变大通常意味着数据库变化块比例飙升。处理思路不要只落在“怎么压缩备份”上先排查业务变更或数据操作是否有大表重建。是否有批量 UPDATE 或 DELETE。是否做过分区表拆合。是否迁移了大量数据。如果是正常业务变化导致的变化块增加可以评估是否调整为累积增量、是否调大0级备份频率。如果确实存在低效操作比如一次性更新一张大部分行都变化的表与其用1级增量承载这种变化不如考虑在业务低峰期直接做一次0级备份把恢复链路重新拉直。6.4 备份分片缺失的处理备份片文件丢失一般先CROSSCHECK BACKUP确认哪些备份记录失效。如果确认失效的备份片没有其他依赖直接DELETE EXPIRED BACKUP清理。如果失效的是当前恢复链上的基础备份就要立刻安排新的0级备份不能拖着不管。在清理备份前评估依赖关系最省事的方法是先把LIST BACKUP SUMMARY和RESTORE DATABASE PREVIEW的输出留档。这样每次删除之前都知道当前恢复链最关键的备份是哪一组。6.5 一个更稳妥的日常习惯接手新环境时不要急着调优备份速度先把现有备份情况摸一遍0级在哪、1级在哪、全备在哪、归档日志覆盖范围是什么。然后再决定要不要调整备份策略。我自己实践的固定动作是每周末跑完0级备份后顺手导出一次LIST BACKUP SUMMARY放到值班文档里。这样任何人接到这个环境都能在十分钟内判断出当前恢复链是否完整。这套方法不复杂但真的能避免很多“看起来备份都正常、恢复时却各种失败”的尴尬。备份管理这个事最怕的不是命令不会写而是概念不清晰。0级、全备、1级增量、备份分片、delete backup每一个词背后都牵着一套完整的依赖逻辑。把这些依赖关系理顺了恢复演练才有底气。