cdb骨架备份不可省略，因drop pdb会清空root元数据且rman无直接恢复命令；pdb级备份仅用于缩短特定恢复窗口，需配合cdb备份使用。
不能只按“全库”或“单PDB”二选一来规划，必须分层设计：CDB骨架备份是底线，PDB级备份是弹性补充，且两者恢复路径完全不可互换。
为什么CDB骨架备份不可省略
哪怕你只关心某个PDB，也必须定期执行包含 ROOT 和 CONTROLFILE 的备份。因为：
-
DROP PLUGGABLE DATABASE会立即清空CDB$ROOT中的元数据（如CDB_PDBS、服务名映射），RMAN 没有RECOVER PLUGGABLE DATABASE命令，无法跳过 CDB 直接挂载 PDB - 没有有效的控制文件和 ROOT 数据文件，
RESTORE PLUGGABLE DATABASE pdb1会直接报RMAN-06813: could not translate pluggable database pdb1 - 即使你有该 PDB 的单独备份集，RMAN 在
MOUNT状态下查不到其CON_ID，根本无法定位备份片
PDB级备份该在什么场景下启用
单独备份 PDB 不是为了替代 CDB 备份，而是为缩短特定恢复窗口。适用场景包括：
- 某 PDB 业务变更频繁、误操作风险高（如开发测试库），需要比 CDB 全备更短的 RPO
- CDB 包含十几个 PDB，但只有 2–3 个生产 PDB 需要小时级恢复能力，其余可接受天级
- 使用
BACKUP AS COPY对只读 PDB（如报表库）生成镜像副本，恢复时用SWITCH DATABASE TO COPY，避免解压/还原步骤 - 备份时加
PLUS ARCHIVELOG是冗余动作——PDB 自身不产生归档，归档只属于 CDB，所以应在 ROOT 上统一做
备份命令写法与常见陷阱
命令本身简单，但上下文错一点就失效：
- 在
CDB$ROOT中备份指定 PDB：BACKUP PLUGGABLE DATABASE pdb1;—— 必须确保当前 session container 是CDB$ROOT（SHOW CON_NAME验证） - 在 PDB 内部连接备份：
rman target sys/password@pdb1后执行BACKUP DATABASE;—— 此时不会备份控制文件、spfile、归档，仅数据文件 - 误用
BACKUP DATABASE在CDB$ROOT下执行：它会备份整个 CDB（含所有 PDB），但若没配PLUS ARCHIVELOG，归档日志可能丢失 - 未开启
CONTROLFILE AUTOBACKUP ON，又没手动BACKUP CURRENT CONTROLFILE，一旦控制文件损坏，所有备份都不可用
时间点恢复时最易被忽略的约束
想把某个 PDB 恢复到昨天 14:00，不是只找它的备份就行：
-
RECOVER DATABASE UNTIL TIME '2026-09-16 14:00:00'必须在 CDB 级别执行，且依赖该时间点前完整的控制文件 + ROOT 数据文件 + 所有归档日志链 - PDB 与 ROOT 可不同步恢复（如 ROOT 到 15:00，PDB 到 14:00），但前提是控制文件里已记录该 PDB 在 14:00 时的 SCN 和文件头信息
- 用
LIST BACKUP OF PLUGGABLE DATABASE pdb1查不到结果？别急着重备——先确认是否在CDB$ROOT下执行，且该 PDB 当前是否处于OPEN或MOUNTED状态（READ ONLY状态的 PDB 也能被列出）
真正卡住恢复的往往不是命令语法，而是控制文件中缺失某个 PDB 的创建记录，或归档日志链在 DROP 操作前就断了——这些必须靠定期验证备份可恢复性（RESTORE DATABASE PREVIEW + RECOVER DATABASE TEST）来提前暴露。
