BACKUP DATABASE ROOT不支持增量备份，RMAN禁止对其使用INCREMENTAL关键字，因BCT和SCN机制为CDB级全局特性，无法按容器隔离；唯一可行方案是定期执行该命令（等效LEVEL 0全备）并配合归档日志连续保护。
BACKUP DATABASE ROOT不支持增量备份
直接结论：backup database root 命令本身不接受 incremental 关键字，rman 不允许对根容器单独做增量备份。这不是语法遗漏，而是设计限制：oracle 未提供针对 cdb$root 的独立增量策略支持。
你可能会尝试写 BACKUP INCREMENTAL LEVEL 1 DATABASE ROOT，但 RMAN 会报错 RMAN-00571 或直接忽略 ROOT 并退化为全 CDB 范围的增量——前提是当前容器是 CDB$ROOT 且所有 PDB 都 OPEN。
- 根本原因：RMAN 的增量机制基于数据块变更跟踪（BCT），而 BCT 是数据库级特性，不是按容器隔离的；CDB$ROOT 的数据文件与 PDB 数据文件共享同一套 SCN 和检查点机制
- 实际效果：哪怕你只想要 root 的增量，RMAN 仍需扫描整个 CDB 的数据文件才能识别哪些块被修改过
- 替代路径只有两条：要么全 CDB 做增量，要么对 root 手动做 0 级全备 + 归档日志连续保护
想只保护 CDB$ROOT，只能靠 0 级全备 + ARCHIVELOG
如果你的业务场景明确只要保障 CDB$ROOT 可恢复（比如避免误删公共用户、改坏数据字典），又不想备份所有 PDB，唯一可行组合是：
- 定期执行
BACKUP DATABASE ROOT（本质是 0 级全备） - 确保归档模式开启：
SELECT LOG_MODE FROM V$DATABASE;必须返回ARCHIVELOG - 配合
BACKUP ARCHIVELOG ALL DELETE INPUT，保证归档日志链完整且不膨胀 - 启用控制文件自动备份：
CONFIGURE CONTROLFILE AUTOBACKUP ON;，否则恢复时可能找不到匹配的控制文件
这个组合能实现「逻辑上的增量效果」：每次 BACKUP DATABASE ROOT 是全量快照，但通过归档日志可前滚到任意时间点——只是不节省空间，只节省恢复窗口。
误用 BACKUP DATABASE 导致“以为只备了 root”
很多人在 CDB$ROOT 下执行 BACKUP DATABASE 后，发现备份集里混进了 PDB 数据文件，却以为是 bug。其实这是正常行为，关键看 PDB 当前状态：
-
PDB$SEED总是READ ONLY且OPEN，所以必然被包含 - 你创建的 PDB（如
PDB1）如果处于OPEN状态，也会被纳入；若为MOUNTED或CLOSED，则完全跳过 - 也就是说：
BACKUP DATABASE的范围是动态的，不是静态配置决定的
这种不确定性正是为什么不能依赖它来“精简保护 root”——PDB 状态一变，备份内容就变，运维不可控。
真正需要增量保护时，必须全 CDB 统一做
如果你的环境要求高效备份（比如夜间窗口紧张），且 CDB 中 PDB 数量多、变化频繁，那就别拆开想“只给 root 增量”。正确做法是：
- 在 CDB$ROOT 中执行：
BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG - 前提：已存在有效的 0 级备份（可以是
BACKUP DATABASE或BACKUP DATABASE ROOT，但后者不能作为增量基线） - 注意：
BACKUP DATABASE ROOT生成的备份集 不能 作为LEVEL 1的父备份，RMAN 会报ORA-19624或跳过匹配 - 验证增量链是否完整：
LIST INCARNATION OF DATABASE;+LIST BACKUP BY FILE;查看每个数据文件的最近 LEVEL 0 时间
最易被忽略的一点：即使你只关心 root 恢复，一旦用了增量策略，就必须把整个 CDB 视为一个备份单元——因为块变更跟踪文件（block_change_tracking.dbf）是 CDB 级的，无法按容器切分。
