在PDB内执行BACKUP DATABASE是最稳妥方式，仅备份该PDB自身数据文件、控制文件快照和SPFILE副本（若启用自动备份），不涉及CDB$ROOT或其他PDB；需先切换容器并以SYSBACKUP/SYSDBA连接，且归档日志须在根下单独备份。
在PDB内部执行BACKUP DATABASE是最可靠路径
直接连进目标pdb再备份，是唯一不依赖其他pdb状态、也不受rman通道配置“侥幸影响”的方式。你连进pdb1后，backup database就只处理它自己的数据文件、当前控制文件快照和spfile副本（如果启用了configure controlfile autobackup on），不会碰cdb$root或其它pdb。
操作步骤：
- 先用
sqlplus / as sysdba登录，执行ALTER SESSION SET CONTAINER = pdb1; - 再用
CONNECT / AS SYSBACKUP（推荐）或CONNECT / AS SYSDBA重连，确保上下文落在该PDB内 - 运行
BACKUP DATABASE FORMAT '/backup/pdb1_%U.bkp';
注意：BACKUP DATABASE PLUS ARCHIVELOG在PDB内执行时，不会备份归档日志——归档日志始终是全CDB级别的，必须回到CDB根下单独执行BACKUP ARCHIVELOG ALL。
BACKUP PLUGGABLE DATABASE pdb_name在根下执行的三个硬性前提
这条命令看似方便，但RMAN不会主动校验前提条件，漏掉任意一个都会静默失败：不报错、不生成备份集、只打印一条RMAN-06207: WARNING: no channels allocated for maintenance就退出。
必须同时满足：
- 连接必须在CDB根容器中——即
CONNECT TARGET /后没执行过ALTER SESSION SET CONTAINER - 目标PDB必须为
OPEN状态（查SELECT NAME, OPEN_MODE FROM V$PDBS WHERE NAME = 'PDB1';，不能是MOUNTED或READ ONLY） - RMAN已配置默认设备类型：
CONFIGURE DEFAULT DEVICE TYPE TO DISK;或TO SBT;，否则即使磁盘有空间也会因找不到通道而失败
示例有效命令：BACKUP PLUGGABLE DATABASE pdb1 FORMAT '/u01/backup/pdb1_%U.bkp';
常见错误现象与对应排查点
你以为备份完成了，结果LIST BACKUPSET里找不到目标PDB的备份，或者恢复时报no backup of datafile，大概率踩了这些坑：
-
ORA-65040: operation not allowed from within a pluggable database：你在PDB里直接敲了BACKUP PLUGGABLE DATABASE——这个命令只能在CDB根下运行 - 备份集里只有
CDB$ROOT和PDB$SEED：说明你执行BACKUP DATABASE时，目标PDB是MOUNTED状态，RMAN默认跳过 - 执行
BACKUP DATABASE却没备份任何用户PDB：你在CDB根下运行该命令，但当时其它PDB都处于MOUNTED或READ ONLY状态，RMAN只备份了当前OPEN的容器
归档日志永远不属于某个PDB，它是CDB级资源；想保证可恢复性，必须在根下补做BACKUP ARCHIVELOG ALL，且时间窗口要覆盖PDB备份起点。
备份路径选择的关键差异点
BACKUP DATABASE ROOT和BACKUP DATABASE行为完全不同：
-
BACKUP DATABASE ROOT明确限定只备份根容器，忽略所有PDB（包括PDB$SEED），适合单独保护元数据，行为稳定可预测 -
BACKUP DATABASE在多租户下结果取决于运行时V$PDBS.OPEN_MODE快照，不是静态定义的范围；自动化脚本里必须前置状态校验，否则可能漏备
真正需要单PDB备份时，别贪图“在根下一条命令搞定”，优先走PDB内BACKUP DATABASE路径——它不依赖其它PDB状态，也不要求提前OPEN，只要该PDB能连上就行。
