企业官网建设流程全解析

简介：NetBackup（NBU）在Oracle备份场景中的配置，是DBA与备份管理员经常需要处理的环节。以NBU 8.3.0.2为例的配置文档，面向Linux/Unix环境下的Oracle 11.2.0.4数据库，完整演示了安装Oracle客户端代理、输入Master/Media服务器与授权token、创建Oracle备份策略、选择脚本客户端以及定制RMAN热备份脚本的全过程。包内为单个docx文档，体积5.9MB，步骤说明配合界面描述，突出了hosts配置、1556/13724端口互通和token粘贴无回显等实际易错点，并给出脚本关键参数的位置与修改思路，便于读者直接套用或调整。该文档发布以来已有836人学习，适合具备一定Oracle基础、正在部署NetBackup备份方案的运维与DBA人员参考。

1. 为什么说 NBU 备份 Oracle 要用 RMAN 通道而不是文件级备份

做 DBA 或者备份管理员的人，十有八九都搜过“NBU备份oracle详细配置文档”这句话。遇到的情况通常是：Oracle 跑在 Linux 上，机房里有一台 NetBackup 主服务器，业务要求做全量备份加归档日志备份，并且恢复时不能丢超过一个 RPO。NBU 虽然叫网络备份，但用它备份 Oracle 绝不是把数据文件当成普通文件拷贝一遍，那样出来的备份在恢复时要么只能做冷备份回滚，要么在热备状态下数据文件之间 SCN 不一致。真正可靠的做法是把 Oracle 交给 NBU 的 Oracle 策略，走 RMAN 的 SBT 接口，让 RMAN 控制备份内容，NBU 负责写介质、管生命周期。

这份配置文档会按“原理层 → 安装与策略配置 → 踩坑排查 → 恢复验证”的顺序展开，覆盖从裸机环境到第一次全备成功，再到拿备份做恢复演练的完整路径。适合两类人看：一类是刚接手 Oracle 备份、还不清楚 NBU 和 RMAN 怎么分工的；另一类是把备份脚本跑通过，但遇到状态码 59、ORA-19506、备份集“假成功”等问题需要快速定位的。下面所有配置项都以 Linux 平台为主，Windows 上的路径规则不同，但配置思路一致。

2. NBU 备份 Oracle 的数据流与版本差异：10.4.0.1 里 SBT 路径和策略默认值改了哪些

2.1 先理解 NBU 备份 Oracle 时数据流到底怎么走

NBU 备份 Oracle 依赖 RMAN 的 SBT（System Backup to Tape）通道，本质上是 RMAN 把备份数据流交到一个动态库里，这个动态库再去连 NBU 的客户端进程。生产环境里常见的调用链路是：RMAN 的allocate channel type 'SBT_TAPE'加载 NBU 提供的libobk.so64，Oracle 进程把读出来的数据块组装成 RMAN 备份集，通过这个库发给本机 NBU 客户端服务，再经bpdm、vnetd等进程转发到 NetBackup 主服务器，最终落到存储单元上。

这个架构决定了几个关键点。第一，块级别的一致性问题由 RMAN 保证，NBU 不需要关心 Oracle 数据文件是否在复制过程中被修改，它拿到的是 RMAN 已经切好的备份集。第二，备份集的完整性检查、归档日志的装载和删除，都由 RMAN 的delete input控制，NBU 不会主动删任何 Oracle 文件。第三，NBU 对 Oracle 备份的映像记录依赖客户端上报的信息，所以策略名、客户端名、SID 这些标识必须和 RMAN 脚本里 send 命令的参数完全对得上，错一个字符恢复时都找不到映像。

明白了这条链路，后面配置时就知道哪些地方不能省。很多“备份失败”不是网络问题，而是 RMAN 脚本里分配了 SBT 通道，但 NBU 客户端这边没有可用的策略名字，或者bp.conf里SERVER写法跟主服务器 hostname 不一致，导致客户端不知道把数据发给谁。

2.2 文件备份与 Oracle 备份的差异：不要把 NBU 的 Standard 策略套在数据库上

NetBackup 策略类型里有一类叫“标准文件备份”，很多新手图省事直接建一个这样的策略，把/u01/app/oracle/oradata目录选进去，运行完看到任务状态是成功，就觉得备份完成了。这类备份在数据库关闭状态下做冷备份还行，但生产库基本不允许长时间停机；热备状态下直接拷贝数据文件的后果是，恢复时数据库可能报ORA-01113、ORA-01110，因为数据文件头部检查点不一致。

NBU 里专门有一类策略类型叫 Oracle，选了它之后，备份选择里填的不是目录路径而是 RMAN 脚本内容或脚本文件路径。前者是文件级备份，后者走 SBT 通道，这二者对 Oracle 来说有本质区别。在 10.4.0.1 版本的 NetBackup 客户端安装界面里，安装包会要求额外勾选“NetBackup for Oracle”选件，安装完成后才会生成 RMAN 需要的 SBT 库文件。所以做配置前先确认客户端包含这个选件，不然策略建好后 RMAN 一分配通道就报ORA-27211之类的错误。

从备份策略角度说，Oracle 策略能识别 RMAN 的备份内容类型，知道哪个备份集是数据文件、哪个是归档日志、哪个是控制文件。文件级备份做不到这一点，更做不了“恢复某个表空间”这种粒度操作。

2.3 版本差异：10.4.0.1 在 Oracle 备份上的表现与兼容性注意点

NetBackup 10.4.0.1 这个版本，Oracle 备份相关的功能没有特别激进的重构，但有几处细节和旧版本不一样。首先是 SBT 库文件的位置，在主流 Linux 发行版下还是/usr/openv/netbackup/bin/libobk.so64，但 10.4 的安装包会把 Oracle 插件独立拆成一个选项，没勾选就不会有这个文件存在或不会被注册到系统库里。其次是客户端与主服务器之间的版本兼容矩阵，10.4 的客户端配老版本主服务器或反过来的组合，有时会出现控制台能看到客户端，但任务一提交就状态码 25 或者 59 的怪问题。

第二个变化在策略属性里。10.4 控制台创建 Oracle 策略时，“备份选择”标签页里的默认处理逻辑是逐行把脚本内容当作 RMAN 命令送进rman，而不是像旧版本那样需要你在脚本里额外写run{}包裹。这个变更对老脚本的影响是：如果你手里的 RMAN 脚本原本是为 NBU 9.x 写的，用了大段的allocate channel加send组合，在 10.4 下也能跑，但要注意“备份选择”里如果写了多行，每一行都会被单独执行一次，容易重复分配通道。

还有一点容易忽略：10.4 的主服务器上如果配置了“自动映像复制”功能，Oracle 备份生成的映像在复制到副本存储单元时，NBU 会默认带上 Oracle 的恢复元数据。这本身是好事，但要注意主映像和副本映像的保留时间必须一致，否则恢复界面里能看到的映像集合会被拆散，出现“有备份但恢复不了到指定时间点”的尴尬情况。

3. 用 NBU 10.4 配置 Oracle 全量备份：策略、客户端属性与 RMAN 脚本三件套

3.1 安装 NBU 客户端和 Oracle 插件：一条命令和两个验证点

客户端安装建议选英文路径，装中文或带空格的安装目录在 RMAN 调用 SBT 库时偶尔会出引号问题。Linux 下安装 NetBackup 客户端一般执行安装盘里的INSTALL脚本，但生产环境更常见的做法是用主服务器推送安装，或者直接解压 tar 包后运行./install。安装过程中会出现交互式问答，其中“安装 NetBackup for Oracle 选件”这一步务必选择是；装完后检查/usr/openv/netbackup/ext/db_ext/oracle目录是否存在，存在说明插件文件已经到位。

接着做两个验证。第一个是验证客户端和主服务器之间的通信，可以执行bpclntcmd -pn，返回结果里能看到已经解析到的主服务器名；再用bpclntcmd -self看客户端自身的主机名是否与主服务器上注册的名字一致。第二个是验证 SBT 库文件是否能被 RMAN 加载，直接ls -l /usr/openv/netbackup/bin/libobk.so64，确认它在，不需要额外做 ldconfig，RMAN 是显式加载这个路径的。

# 安装完成后，先手动执行这两个命令确认基础通信 /usr/openv/netbackup/bin/bpclntcmd -pn /usr/openv/netbackup/bin/bpclntcmd -self

第一行命令是“打印主服务器信息”，能看到当前客户端配置的主服务器 hostname；第二行是“客户端自检”，它会告诉你在主服务器眼里你这台机器的名字。这两条输出必须是一致的，如果-self出来的名字跟bp.conf里的SERVER不一致，后续分配 SBT 通道时会报“无法连接 NetBackup server”。

主机名解析这一点看着基础，却是翻车率最高的环节。我会在安装完后顺手确认/etc/hosts里主服务器和本机的解析记录，保证不依赖 DNS。很多机房 DNS 有内部后缀，主服务器的 fully qualified hostname 和短名都能解析到才行。

3.2 创建 Oracle 策略：这些参数别照抄默认

在 NetBackup 管理控制台里创建新策略，策略类型选 Oracle。这一步选错的话，后面的备份选择界面完全不一样。策略建好后，关键配置项集中在“客户端属性”和“Oracle”这两个标签页里，下面这张表是我每次配置都对着核一遍的参数。

“客户端属性”里如果没有 Oracle 实例列表这个入口，说明客户端插件没装好，或者主服务器还没识别到客户端的 Oracle 扩展。此时回到 3.1 节的验证步骤重新查。

“备份选择”标签页里内容值得单独强调。Oracle 策略下这里写的是 RMAN 命令或脚本文件路径，不是要备份的目录。如果你填了一个 Linux 路径，NBU 会把它当成普通文件备份的对象来处理，结果备份出来的映像里全是脚本和日志，数据库数据根本没进去。这类情况就是任务显示成功、备份集却毫无用处的最典型原因。

3.3 写一个能被 NBU 调度的 RMAN 全量备份脚本

Oracle 策略的备份选择如果指向一个.rcv文件，NBU 在执行备份时会调用rman逐行执行里面的命令。下面的脚本是一份可拿来改的全量加归档日志备份模板，要求数据库运行在归档模式。

# /backup/scripts/nbu_full.rcv RUN { ALLOCATE CHANNEL ch1 TYPE 'SBT_TAPE'; SEND 'NB_ORA_SERV=nbumaster, NB_ORA_CLIENT=oradb01, NB_ORA_POLICY=ORACLE_FULL'; BACKUP INCREMENTAL LEVEL 0 FORMAT 'bk_%U' DATABASE INCLUDE CURRENT CONTROLFILE PLUS ARCHIVELOG DELETE INPUT; RELEASE CHANNEL ch1; }

这里先解释SEND这行的三个参数：NB_ORA_SERV是主服务器主机名，NB_ORA_CLIENT是 NetBackup 里注册的客户端名，NB_ORA_POLICY是刚才创建的策略名。这三个值必须与 NBU 控制台里的实际名称完全一致，RMAN 脚本里引用的策略名如果写错，备份任务会正常启动，但映像归属到错误的策略下，恢复时找不到。

BACKUP INCREMENTAL LEVEL 0是累积全备的写法，Oracle 备份中 level 0 全备是后续增量备份的基础，不能只靠 level 1 增量。DATABASE INCLUDE CURRENT CONTROLFILE保证了备份集里带一份当前控制文件，异机恢复时会用到。PLUS ARCHIVELOG DELETE INPUT表示在备份数据库的同时，把尚未备份的归档日志一并备份，成功后再删除源归档日志。这个选项解决了一个常见的容量问题：归档日志累积不清理，导致rman备份老是满或归档目录所在的文件系统被写满。前提是策略的保留期限设置比归档日志覆盖周期更长，否则会出现当前备份还没成功、旧归档已经被删的情况。

要手动验证这个脚本能不能跑，以 oracle 用户执行：

rman target / cmdfile=/backup/scripts/nbu_full.rcv log=/backup/logs/nbu_full_$(date +%Y%m%d).log

手动能跑通再交给 NBU 调度。注意 NBU 调度的执行用户一般也是 oracle，这是主服务器推送任务时使用的默认凭证。调度的“优先级”和“窗口”按机房维护窗口设置即可，全量备份建议放在业务低谷。

4. 避坑指南：NBU 备份 Oracle 最常见的 5 个故障与排查路径

4.1 现象：备份任务显示“成功”，但 RMAN 日志里全是 ORA-19506

备份完成后打开 NBU 控制台，任务状态是“成功”，但点开日志发现 RMAN 报错，内容类似ORA-19506: failed to create archival backup或ORA-27028: cannot create file。任务最终退出码是 0，于是没人注意到备份实际没写成。

原因通常是数据库没有开启归档模式。RMAN 在非归档模式下执行PLUS ARCHIVELOG，或者执行ALTER SYSTEM ARCHIVE LOG CURRENT这类命令，会直接触发 ORA-19506。NBU 认为备份结束了就把任务标记为成功，因为它只管调用介质，不管 Oracle 内部的 SQL 执行结果。

解决方法是先确认数据库模式：SELECT log_mode FROM v$database;如果结果是NOARCHIVELOG，要么改成在线备份所需的归档模式，要么在策略里把在线备份勾选去掉、使用离线备份类型。生产库长期不归档本来就是事故隐患，我见过有些系统 dbf 文件坏了之后能恢复的日志窗口只有一天，就是因为归档模式没开。这属于配置前先要确认好的前提条件，不是 NBU 本身的错。

4.2 现象：状态码 59，正在连接 NetBackup media manager 时卡死

备份任务在“正在连接 NetBackup media manager”时长时间不动，最后状态码 59，RMAN 日志里能看到ORA-19511: Error received from media manager layer。

原因是客户端无法与主服务器建立通信。常见的两个小坑：一是/usr/openv/netbackup/bp.conf里SERVER =后面写的名称跟主服务器的SERVER_NAME不一致，或者写了 IP 地址而主服务器用的主机名；二是防火墙阻止了 13782 监听端口和 13720 的 vnetd 端口。

解决路径是先用bpclntcmd -pn看配到的主服务器，再用bpclntcmd -self看客户端自识别名称。两侧对不上就修改 bp.conf，然后执行/usr/openv/netbackup/bin/nbftconfig -set或者重启 NetBackup 客户端服务。端口方面，在客户端机器上执行netstat -an | grep 13782，如果看不到监听或 ESTABLISHED，检查机房防火墙策略。

4.3 现象：备份脚本手动跑没问题，NBU 调度一跑就失败

在 oracle 用户下手工执行 RMAN 脚本一切正常，但只要交给 NBU 调度，日志里就是RMAN-04006: error from preprocess callback或者直接找不到ORACLE_SID。这个属于典型的黑匣子式问题——你以为是 NBU 调用逻辑有毛病，其实是环境变量没传进去。

NBU 执行 Oracle 策略任务时，虽然以 oracle 用户身份运行，但不会自动加载.bash_profile，ORACLE_HOME和ORACLE_SID可能都是空的。解决方式是脚本第一行写上这两个环境变量：

#!/bin/sh export ORACLE_HOME=/u01/app/product/19.0.0/dbhome_1 export ORACLE_SID=ORCL

另一种常见做法是在策略备份选择的第一行用#oracle_home和#oracle_sid作为前缀，例如#oracle_home /u01/app/oracle/product/19.0.0/dbhome_1，NBU 会解析这类特殊注释行并注入到执行环境中。用这对注释头的好处是脚本可以不用export，但注意不同版本解析规则有差异，10.4 版本两种方式都支持，我更推荐脚本内export，因为手动执行时也不会忘记环境变量。

4.4 现象：备份“成功”了，但 NB_ORA_POLICY 对应的策略下查不到映像

任务成功、RMAN 日志正常，但bpimagelist里按照策略名过滤，看不到这次生成的备份映像；或者恢复界面里的备份集只有零星几个旧记录。这种假成功很容易在换人或换库之后出现。

原因多半是 RMAN 脚本里的NB_ORA_POLICY写错了名字，或者SEND命令没有写，让备份映像默认归属到客户端默认策略下。还有一种情况：备份选择里填的脚本路径本身在策略中也被解释成了“要备份的文件”，于是这行路径产生的普通文件备份和 Oracle 备份混在一个任务里。

解决方法是打开策略的“备份选择”标签，查看内容是文件路径还是 RMAN 脚本。如果是脚本文件路径，确保策略里没有把该路径本身再纳入任何文件系统备份的列表中。另外检查SEND行的NB_ORA_POLICY与策略名是否大小写完全一致，NBU 对策略名区分大小写，Oracle_Full和oracle_full是两个东西。

4.5 现象：恢复演练时发现备份集在 NBU 里还在，RMAN 却提示 backup not found

最恐慌的场景不是没备份，而是备份明明在，恢复时却找不到。RMAN 里执行RESTORE DATABASE，提示RMAN-06053或者“backup not found”，但 NBU 控制台里映像还显示着可用。

原因大多是备份保留策略在两边不一致。NBU 策略的保留期限控制着介质上映像是否过期可回收，而 Oracle 控制文件里的 RMAN 备份记录受CONFIGURE RETENTION POLICY控制。如果 NBU 保留 30 天，RMAN 保留 7 天，RMAN 里早把这批备份标记为EXPIRED，虽然物理映像还在，恢复时 RMAN 不认。反之如果 RMAN 保留长而 NBU 先删了介质，恢复时就会提示找不到备份集。

解决方法是让两边保留期对齐。推荐在 RMAN 里设置CONFIGURE RETENTION POLICY TO REDUNDANCY 1;或按天数配置，并把 NBU 策略的保留期限设置成相同的时间窗口。Oracle 控制文件里查询LIST BACKUP SUMMARY;能看到过期状态，NBU 里用bpimagelist -U -L看映像的过期时间，两相对比即可定位。

5. 验证你的备份真正可恢复：restore validation 与异机恢复的最小动作

备份跑得再好，恢复不了就是零。我见过不少环境，全量备份跑了一年，从没做过恢复验证，直到生产库有人误删表空间，才发现备份的归档日志缺了一段，恢复的数据只能到三天前。所以配置文档的最后，一定要加一个定时恢复演练的习惯。

验证分成两步。第一步是RESTORE VALIDATE，它不会真正恢复数据，但会读取备份集并逐块校验，能确认备份集完整、没有物理损坏。命令执行方式：

rman target / <<EOF RESTORE DATABASE VALIDATE; EOF

这个命令如果跑通，说明备份集可用。但注意，它验证的是备份集本身，不验证恢复到指定时间点是否能成功。第二步才是真正有底气的验证：在另一台相同版本 Oracle 的机器上，安装同版本 NBU 客户端，注册成新的客户端名，然后用RESTORE CONTROLFILE加RESTORE DATABASE恢复一套环境出来。异机恢复的坑比同机恢复多，尤其是控制文件内容带路径信息这一点，记得先把参数文件里的DB_NAME、DB_UNIQUE_NAME确认好，必要时用SET NEWNAME重定向数据文件路径。

关于误删数据这类事故，如果库没有任何备份，唯一可能的后悔药是开启过 FLASHBACK DATABASE，能回闪到删除前的某个时间点。但那个前提在大多数生产库上并不成立，所以更推荐的做法是：每次做完 NBU 的 Oracle 配置，就从备份集里挑一个最旧的全备，做一次恢复演练，确认从第一天到现在的备份历史都能连贯起来。

日常巡检时，我习惯用bpimagelist -U -L | grep -A 20 "ORACLE_FULL"看策略下的映像列表，确认每次全量备份都对应产生了 level 0 映像，归档日志备份也没有断档。顺手查一下目标客户端的logs/bpbm.log，看有没有非零退出码。这些习惯帮我避免过两次因为升级后策略参数被重置导致的备份空转事故，希望帮到你。

本文还有配套的精品资源，点击获取