RMAN备份CDB时默认只备份CDB$ROOT、PDB$SEED及当前OPEN的PDB；需显式指定BACKUP PLUGGABLE DATABASE或确保目标PDB处于OPEN状态，且备份归档日志覆盖全CDB但恢复需按容器区分。
备份整个CDB时，RMAN默认只备份ROOT和PDB$SEED
rman连接到cdb根容器执行 backup database，实际不会自动包含用户创建的pdb——这是最常被误以为“全备了”的坑。它只备份cdb$root、pdb$seed，以及当前open状态的pdb（注意：仅限当前rman会话连接时处于open状态的那个pdb，不是所有pdb）。
所以如果你在CDB根下运行：
BACKUP DATABASE;
而此时只有PDB$SEED和CDB$ROOT是OPEN的（比如其他PDB都处于MOUNT状态），那结果就是只备份这两个容器，PDB1、PDB2等完全没进备份集。
- 必须显式指定要备份的PDB：
BACKUP PLUGGABLE DATABASE pdb1, pdb2; - 或者先用
ALTER PLUGGABLE DATABASE pdb1 OPEN;确保目标PDB处于OPEN状态，再执行BACKUP DATABASE -
BACKUP DATABASE PLUS ARCHIVELOG同样受此限制，归档日志备份不受影响，但数据文件部分仍只覆盖当前OPEN的容器
单独备份某个PDB，必须在该PDB内连接RMAN
RMAN不支持从CDB根直接执行BACKUP PLUGGABLE DATABASE pdb1——这条命令语法上合法，但实际会报错：ORA-65040: operation not allowed from within a pluggable database？不对，反过来了：你得先进入PDB才能备份它。
正确路径是：
- 用
sqlplus / as sysdba登录后，先切换：ALTER SESSION SET CONTAINER = pdb1; - 再用
CONNECT / AS SYSBACKUP（或SYSDBA）连入该PDB上下文 - 此时运行
BACKUP DATABASE，才真正只备份pdb1的数据文件、控制文件快照、SPFILE副本（如果启用了CONFIGURE CONTROLFILE AUTOBACKUP ON） - 注意：
BACKUP DATABASE在PDB内执行时，不会备份CDB$ROOT或其它PDB——这点和根下执行完全不同
使用BACKUP PLUGGABLE DATABASE命令的三个关键前提
这个命令看起来像能“从根直接备份PDB”，但它有硬性依赖条件，缺一不可，否则静默跳过或报错。
- 必须在CDB根容器中连接RMAN（即
CONNECT TARGET /后未切换CONTAINER） - 目标PDB必须处于
OPEN状态（SELECT NAME, OPEN_MODE FROM V$PDBS确认） - RMAN配置项
CONFIGURE DEFAULT DEVICE TYPE TO SBT或DISK需已设置，否则可能因找不到默认通道而失败 - 示例有效命令：
BACKUP PLUGGABLE DATABASE pdb1 FORMAT '/u01/backup/pdb1_%U.bkp'; - 常见错误现象：
RMAN-06207: WARNING: no channels allocated for maintenance→ 本质是没配通道，不是语法错
备份归档日志时，CDB与PDB视角一致，但恢复点需按容器区分
无论你在CDB根还是某个PDB里执行BACKUP ARCHIVELOG ALL，RMAN都会扫描并备份整个CDB范围的归档日志——因为归档日志物理上属于CDB，不按PDB切分。
但问题出在恢复阶段：
- 用
RESTORE DATABASE在CDB根下执行，会还原所有容器（包括PDB$SEED） - 用
RESTORE PLUGGABLE DATABASE pdb1，只还原该PDB的数据文件，但归档日志应用（RECOVER PLUGGABLE DATABASE）仍需CDB级归档日志参与 - 容易踩的坑：误以为备份了
pdb1的归档日志——其实没有独立归档日志，所谓“PDB归档”只是逻辑概念；恢复时若只保留了某段时间的归档，必须确认它覆盖了所有待恢复PDB的SCN范围
多租户环境下，备份策略真正复杂的地方不在语法，而在容器状态一致性与归档日志生命周期管理——一个PDB长期READ ONLY，另一个频繁DML，归档压力和保留策略就得拆开设计，这点RMAN本身不帮你判断。
