必须使用RMAN备份主库归档日志，禁用cp或rsync；RMAN自动校验完整性、支持备份后联动删除、恢复时可按序列/时间自动定位，而手动方式易导致损坏备份、误删或恢复失败。
主库归档日志必须用 RMAN 备份，禁用 cp 或 rsync
生产环境里，RMAN 是 Oracle 官方唯一认可、且实际可用的归档日志备份方式。手动用 cp、rsync 或脚本搬运归档文件，看似简单，实则埋雷：
- 不校验归档日志完整性 —— 若某
arch_12345.arc文件在写入过程中被中断，cp会静默复制损坏副本，RMAN 则会在BACKUP ARCHIVELOG时自动跳过或报错 - 无法联动删除 —— RMAN 支持
DELETE INPUT或DELETE ALL INPUT，确保仅在备份成功后才清理源归档；手动删需额外逻辑判断，极易误删未传输完的日志 - 恢复时无法自动定位 —— RMAN 备份集元数据自带归档序列、线程、时间戳，
RESTORE ARCHIVELOG可直接按 SCN/时间/序列号还原；手动备份后恢复，DBA 得自己拼路径、查V$ARCHIVED_LOG、再ALTER DATABASE REGISTER LOGFILE
正确做法是统一走 RMAN 脚本，例如：
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES FORMAT '/backup/arch/%d_%T_%s_%p';
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
}
备库归档日志不需要单独备份
物理备库（PHYSICAL STANDBY）上的归档日志，本质是主库重做流的“镜像产物”，由 RFS 进程接收并写入本地 LOG_ARCHIVE_DEST_n 目录。这些文件：
- 内容与主库对应归档完全一致（相同
THREAD#、SEQUENCE#、FIRST_CHANGE#） - 不参与任何恢复决策 —— Data Guard 恢复只依赖主库产生的归档（或 Standby Redo Logs），备库自身归档只是副产品
- 若主库归档已通过 RMAN 备份，备库上同序列日志无额外价值；备份它只会浪费空间、干扰 RMAN CROSSCHECK
例外场景极少：仅当备库曾临时切换为主库（Switchover/Failover）并持续运行一段时间，期间生成的新归档才具备独立备份价值 —— 此时它已是新主库，应按主库规范用 RMAN 备份。
主库 RMAN 备份必须包含归档日志 + 控制文件 + SPFILE
单备一份归档日志远远不够。完整可恢复的 RMAN 备份集至少要含三类对象：
-
BACKUP DATABASE：数据文件快照 -
BACKUP ARCHIVELOG ALL：覆盖从上次全备至今所有归档（建议加NOT BACKED UP 1 TIMES避免重复） -
BACKUP CURRENT CONTROLFILE或BACKUP DATABASE PLUS ARCHIVELOG自动包含控制文件备份 —— 控制文件记录了归档日志的物理位置、序列号、是否已应用等关键元数据
漏掉控制文件备份，即使有全部归档，RESTORE DATABASE 后也无法知道该从哪个归档开始应用；漏掉 SPFILE，则可能因参数差异（如 db_unique_name、log_archive_config）导致备库启动失败。
归档日志备份路径不能放在主库归档目标目录下
常见错误：把 RMAN 备份输出路径设为 /u01/arch（即 LOG_ARCHIVE_DEST_1 所指目录）。这会导致：
- RMAN 备份文件被误识别为归档日志 ——
V$ARCHIVED_LOG可能将xxx.bak当作有效归档，引发ORA-00334等错误 - 归档目录空间被备份文件挤占，触发
ARCHIVE LOG FAILED，主库挂起 - 备份与归档混存，
DELETE ARCHIVELOG时可能误删备份文件
硬性隔离原则：归档目录（LOG_ARCHIVE_DEST_n）只放 Oracle 自动生成的 .arc 文件；RMAN 备份目录（FORMAT 路径）必须独立，例如 /backup/rman 或共享存储的专用卷。
