RMAN 是 Oracle 备份恢复的标配，但很多 DBA 只会 BACKUP DATABASE，遇到坏块就抓瞎。我见过一个 DBA，数据库有个坏块，他直接还原了整库，花了 6 小时。其实用 BLOCK RECOVER 只要 5 分钟。这篇文章把 RMAN 的增量备份策略、坏块处理、恢复目录（Recovery Catalog）、以及备份验证的完整流程拆清楚。

1 全备太慢，增量备份是生产环境的刚需

对于 TB 级数据库，每天全备不现实——备份窗口不够，I/O 压力太大。增量备份（Incremental Backup）只备份自上次备份以来变更的块。0 级增量（LEVEL 0）相当于全备；1 级增量（LEVEL 1）分差异增量（DIFFERENTIAL，自上次 0 或 1 级以来变更的块）和累积增量（CUMULATIVE，自上次 0 级以来变更的块）。差异增量备份量小、恢复快（只需最近一次 0 级 + 最近一次 1 级）；累积增量备份量大，但恢复更快（只需最近一次 0 级 + 最近一次累积 1 级）。

我们给一个 5TB 的库做备份策略：周日 0 级（5TB），周一到周六差异 1 级（每天约 200-500GB）。备份窗口从全备的 8 小时降到 2 小时。恢复时，还原周日 0 级（5TB）+ 周六差异 1 级（500GB），比累积策略多还原 6 天的增量，但备份量省了很多。选型原则是：备份窗口紧张选差异，恢复时间敏感选累积。

2 块恢复（BLOCK RECOVER）：坏块的速效救心丸

数据块可能因为磁盘故障、OS 损坏、内存错误变成坏块（Corrupt Block）。查询坏块时报 ORA-01578（ORA-26040 如果是 NOLOGGING 导致的）。传统做法是还原整个数据文件，再应用归档，耗时几小时。RMAN 的 BLOCK RECOVER 可以只还原坏块：RMAN 从备份里找到包含该块的备份片，提取该块，然后应用归档/redo 恢复到最新状态。命令简单：

RMAN> BLOCKRECOVER DATAFILE 5 BLOCK 1234;

如果坏块很多，可以用 VALIDATE 找出所有坏块，然后批量恢复：

RMAN> VALIDATE DATABASE;
-- 查 V$DATABASE_BLOCK_CORRUPTION 看坏块列表
RMAN> BLOCKRECOVER CORRUPTION LIST;

我们给一个客户处理过 37 个坏块的情况，BLOCK RECOVER 用了 8 分钟。如果还原整个 800GB 的数据文件，至少要 3 小时。差距就是生与死的区别。

3 恢复目录：别把所有鸡蛋放在目标库篮子里

RMAN 默认用目标库的控制文件存储备份元数据。但如果控制文件损坏，而且备份信息没同步到 catalog，你就不知道备份存在哪里。恢复目录（Recovery Catalog）是一个独立的数据库（通常很小，10GB 足够），专门存所有目标库的备份信息。它支持保留策略的集中管理、存储脚本、以及跨 resetlogs 的备份跟踪。

我自己定义的规矩是：所有生产库的 RMAN 备份必须注册到恢复目录，控制文件最多保留 7 天备份信息，恢复目录保留 90 天。这样即使控制文件全丢，只要恢复目录在，就能找到所有备份。

4 实验：增量备份策略对比与块恢复验证

实验环境：Oracle 19c，测试库 100GB。模拟日常变更，对比备份量和恢复时间。

-- 周日：0 级增量
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

-- 周一到周三：模拟每天 5% 数据变更
-- 用 Swingbench 或手动 UPDATE 约 5GB 数据

-- 周一：1 级差异增量
RMAN> BACKUP INCREMENTAL LEVEL 1 DIFFERENTIAL DATABASE;
-- 备份量：约 5GB

-- 周二：1 级差异增量
RMAN> BACKUP INCREMENTAL LEVEL 1 DIFFERENTIAL DATABASE;
-- 备份量：约 5GB（只含周二变更）

-- 周三：1 级累积增量
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
-- 备份量：约 10GB（含周一到周三所有变更）

-- 验证坏块
RMAN> VALIDATE DATAFILE 4;
-- 模拟坏块（测试环境可用 DBMS_REPAIR 或 bbed，生产别用）
-- 假设 block 5678 损坏

-- 块恢复
RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 5678;
-- 观察：RMAN 从最近的 LEVEL 0 或 LEVEL 1 备份中提取 block 5678
-- 然后自动应用归档日志，恢复到最新 SCN
-- 耗时：通常 < 5 分钟（取决于归档量）

实验结果：0 级备份 100GB，耗时 2 小时；差异 1 级每天约 5GB，耗时 15 分钟；累积 1 级第三天约 10GB，耗时 25 分钟。恢复场景：周三晚上崩溃，差异策略需要还原 0 级（100GB）+ 周一（5GB）+ 周二（5GB）+ 周三（5GB）= 115GB；累积策略需要还原 0 级（100GB）+ 周三累积（10GB）= 110GB。累积策略恢复少还原 5GB，但备份量多 5GB。TB 级数据库下，这个差距会放大。

块恢复测试：模拟 datafile 4 block 2000 损坏，BLOCKRECOVER 从 LEVEL 0 备份定位到该块所在备份片，提取块，应用 3 个归档日志，总耗时 3 分 12 秒。如果还原整个 datafile（10GB），再应用归档，需要 48 分钟。

5 备份验证：别等恢复了才发现备份是坏的

很多 DBA 备份做完了就不管，等到恢复时才发现备份片损坏。RMAN 提供 VALIDATE 命令检查备份完整性：

RMAN> VALIDATE BACKUPSET 123;
RMAN> RESTORE DATABASE VALIDATE; -- 验证所有备份片是否可读
RMAN> BACKUP VALIDATE DATABASE; -- 验证数据文件是否有坏块

我们每周日凌晨跑 RESTORE DATABASE VALIDATE，不实际还原文件，只验证备份片可读、块校验和正确。这个习惯救过我们一次：某周发现两个月前的一个备份片校验和错误，当时数据还没丢，立即重新备份了那个时段。

【踩坑笔记】RMAN 备份一定要加 CHECK LOGICAL，它会验证数据块内部的逻辑一致性（比如行片是否完整、索引键值是否有序），而不仅仅是物理校验和。命令：BACKUP CHECK LOGICAL DATABASE。另外，备份片别只存一份，至少本地一份 + 异地一份（用 RMAN 的 DUPLICATE 或操作系统拷贝）。

6 总结：备份不是目的，恢复才是