RMAN的BACKUP命令中FORMAT只支持本地路径或DISK/SBT等设备类型，不识别scp://等网络协议；必须通过NFS挂载远程目录为本地磁盘，或使用SBT接口对接对象存储，才能实现跨网络备份。
为什么不能直接用 BACKUP ... FORMAT='remote_path'？
RMAN 的 BACKUP 命令中 FORMAT 只支持本地路径或 Oracle 支持的设备类型（如 DISK、SBT），不识别 scp://、rsync:// 或 NFS 远程挂载点以外的“网络路径”。试图写成 FORMAT 'user@host:/path/%U' 会报错 RMAN-00571 或 ORA-19504：无法创建文件。真正可行的跨网络备份，本质是让 RMAN 把文件写到一个“它认为本地、但实际可被远程访问”的位置。
最稳的方式：NFS 挂载远程目录为本地磁盘
这是 Oracle 19c 生产环境最常用、RMAN 原生兼容、无需额外插件的方案。关键不是“配置 RMAN”，而是让远程存储在目标数据库服务器上表现为一块可写的本地磁盘。
- 在远程备份服务器上导出目录（例如
/backup/oracle），启用no_root_squash，确保 Oracle 用户 UID 在两端一致 - 在数据库服务器执行挂载：
mount -t nfs -o rw,bg,hard,rsize=32768,wsize=32768,vers=3,proto=tcp remote_host:/backup/oracle /mnt/remote_bak - 确认 Oracle 用户可写：
sudo -u oracle touch /mnt/remote_bak/test.txt - RMAN 中只需配置标准磁盘通道：
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/mnt/remote_bak/%U.bkp'; - 注意：RAC 环境下所有节点必须挂载同一 NFS 路径，且使用相同挂载选项；否则备份可能只写到某一个节点本地，造成不一致
进阶方式：通过 SBT 接口对接对象存储（如 MinIO）
如果远程端是 MinIO、AWS S3 或兼容 S3 协议的服务，RMAN 可通过第三方 SBT 库（如 libobk.so 或 MinIO 提供的 minio-s3-plugin）实现原生对接。这不是“配置 RMAN”，而是替换 RMAN 的设备驱动。
- 下载并部署对应 SBT 库到
$ORACLE_HOME/lib，更新libobk.so符号链接指向新库 - 配置 RMAN 使用 SBT：
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE'; - 设置通道参数传递连接信息，例如：
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'SBT_LIBRARY=/u01/app/oracle/product/19c/dbhome_1/lib/libobk.so ENV=(STORAGE_URL=http://minio-host:9000,ACCESS_KEY=minioadmin,SECRET_KEY=minioadmin)'; - 验证是否生效：
ALLOCATE CHANNEL c1 DEVICE TYPE 'SBT_TAPE'; BACKUP CURRENT CONTROLFILE;—— 成功即表示已走 S3 协议上传 - 坑点：SBT 库版本必须与 Oracle 19c 兼容；
ENV中的密钥若含特殊字符需 URL 编码；MinIO 必须开启版本控制（mc version enable）防误删
别踩的坑：RMAN 不会自动传输已生成的备份集
有人误以为先本地 BACKUP DATABASE，再手动 scp 备份集到远程，就算“跨网络备份”。这不可靠：RMAN 元数据（控制文件中记录的备份片位置、校验和、归档日志应用关系）仍指向本地路径。恢复时若未同步更新这些元数据，RESTORE DATABASE 会失败并报 RMAN-06023: no backup or copy of datafile found to restore。
真正安全的做法只有两种：要么让 RMAN 写时就落在远程可见路径（NFS/SBT），要么用 DUPLICATE FROM ACTIVE DATABASE 直接流式拉取——后者虽不生成中间备份集，但本质也是跨网络备份，且更省空间、更实时。对 TB 级库，DUPLICATE 往往比“先备份再传”快得多，也少一个故障点。
