★ FEATURED ARTICLE 简介面向Oracle数据库管理员与系统运维人员这份资源针对NetBackupNBU8.3.0.2备份Oracle 11g数据库场景提供了从客户端代理安装到备份策略配置、RMAN脚本修改的完整操作指南覆盖Linux环境下安装agent、主服务器新建Oracle类型策略、存储指向Media Server等关键步骤。压缩包内含1个docx文档大小5.9MB文档以逐步讲解方式呈现并前置说明了环境要求与网络端口1556、13724连通性等注意事项。已有836人学习下载适合具备一定NBU与Oracle基础、希望快速落地备份方案的实践者。除常规配置外还特别提示了安装token在密码界面不可见时应直接粘贴回车、修改脚本需在副本上进行以免升级覆盖以及热备份脚本中环境变量、通道、备份类型与保留策略的调整思路能有效减少排障时间并提升配置成功率。1. 在 NBU 上配置 Oracle 备份先排掉这几个拦路坑再动手生产库的备份从来不是“装上 agent、建个 policy”就完事的事儿。我接手过好几套 NBU 备份 Oracle 的环境真正出问题的地方往往不在大流程上而是藏在安装交互、hosts 解析、RMAN 脚本变量这几处细节里。这套环境是 NBU master 8.3.0.2、RedHat 6.8、Oracle 11.2.0.4不算新但代表了一批还在生产线上跑着的典型组合。这份配置文档把从 Oracle 主机装 agent、到 master 上建 Oracle 类型的 policy、再到定制 hot_database_backup.sh 的完整路径都串起来了。适合两类人一类是第一次给 Oracle 库接入 NBU 的 DBA 和备份管理员照着步骤能把任务跑起来另一类是已经配过但备份偶尔失败的运维用来对照排查顺序。备份方案选 RMAN 走 SBT 通道是当前的主流做法下面从安装侧开始拆。2. Oracle 主机安装 NBU 客户端选对包、处理 token、验证安装2.1 安装包怎么选两个 CLIENT 包的名字藏着平台信息Veritas 下载页面上8.3.0.2 版本会同时列出NetBackup_8.3.0.2_CLIENTS1.tar.gz和NetBackup_8.3.0.2_CLIENTS2.tar.gz两个包。最初我也以为这俩只是拆分卷后来才发现名字里的含义CLIENTS1 对应 Windows 系列CLIENTS2 对应 Linux/Unix 系列。Oracle 主机是 RedHat 6.8所以选 CLIENTS2。# 在 Oracle 主机上执行解压 tar -xzf NetBackup_8.3.0.2_CLIENTS2.tar.gz解压出来之后是一个install脚本和一堆*.tar包每个 tar 包对应一种 OS 平台或一种 NetBackup 组件。你需要先ls看一下解压目录里的内容找到匹配 RedHat 的那个包例如Linux_x86_64对应的子目录再做安装。直接跑解压目录根下的 install 也能装但确认一下里面有没有与你内核版本匹配的包更稳妥尤其在老版本小版本如 6.8 上。2.2 安装交互里最容易翻车的 token 输入环节执行安装脚本后会进入 NetBackup 的交互安装界面它会依次询问Master Server 的 IP 或主机名Media Server 的地址授权 token前两项好办正常填。重点是 token。这个 token 不是随便填的需要在 master 服务器上找有效凭证并复制。打开 master 上的 NetBackup Administration Console进入主服务器属性或授权管理相关页面可以看到当前生成的 valid token选中复制。注意一个非常反直觉的细节安装界面里的 token 输入框是密码框粘贴进去后屏幕上没有星号、没有光标变化什么回显都没有。我第一次装的时候在这卡了十分钟以为自己没粘贴成功反复按回车重试结果 token 被拆成了多次回车安装直接失败。正确做法是粘贴一次、直接回车耐心等它继续往下走。# 在 master 服务器上确认 token 有效性的常用命令可用则能列出版本信息 /usr/openv/netbackup/bin/admincmd/bpminidaemon -version这个命令不是用来生成 token 的token 要从管理控制台里拿。这里列出来是想说明安装前先确认 master 服务正常如果 master 上的 NetBackup 服务没起来token 的有效性也就无从谈起。2.3 安装完别急着建 policy先做三件事安装过程本身不长但装完立刻去建 policy 是个常见跳步操作。我一般会先做三个验证动作成本很低能省掉后面好几轮排错。第一确认 agent 进程在跑# 查看 NetBackup 客户端相关进程 ps -ef | grep -i netbackup正常应该能看到bpcd进程。bpcd是接受 master 连接的 Daemon端口就是 13724。如果bpcd没起来后面 master 怎么连都连不上。第二确认安装目录结构完整# 确认 RMAN 脚本样例目录存在 ls -l /usr/openv/netbackup/ext/db_ext/oracle/samples/rman/这个路径下的hot_database_backup.sh等样例脚本是后面备份选择的依据目录不存在说明 Oracle agent 的数据库扩展组件没装上。第三用bpclntcmd检查客户端与 master 的通信# 在本机验证 master 主机映射和 client 名 /usr/openv/netbackup/bin/bpclntcmd -pn这一步做的是反向查找看 Oracle 主机认为自己的主机名在 master 那边是否能被解析。这个命令的输出会告诉你 master 侧认识你的名字是什么万一 master 上注册的主机名跟你本机 hostname 不一致这里就能提前发现。3. Master 上配置备份计划policy 类型、存储单元和 host 映射一次说清3.1 创建 Oracle policy两个下拉框决定了任务能不能被识别Oracle 主机的 agent 装完master 侧一般能在主机列表里看到它。接下来新建 policy核心操作不多但有两个关键下拉框必须选对。Policy 的 type 要选Oracle这一项决定了 NBU 会用 Oracle 数据库的 agent 接口去发起备份而不是当成普通文件去抓取数据。如果选成Standard即使备份选择里填了 RMAN 脚本NBU 也只会把它当成一个 shell 命令去执行环境变量和通道行为都不对。Policy 的 storage 要选对应的 media 服务器或存储单元。这个决定备份数据写到哪、走哪个介质。media 服务器和存储单元的概念有区别前者是主机后者是基于主机和路径/磁带驱动器的组合。在 policy 里选的是存储单元而存储单元已经绑定了 media 服务器。建议在一开始就把存储单元的名字起得明确一些比如ORA_MEDIA_POOL这样的格式否则多套 policy 挂在一起后光凭名字很难区分这个存储单元是给数据库备份用还是给文件备份用的。3.2 hosts 文件和端口1556、13724 不通时备份任务会卡在队列里Oracle 主机、master 主机、media 主机之间的网络解析问题是数据库备份失败里最常见的隐性因素而且往往不会马上暴露通常是任务启动后卡几分钟然后报连接超时。需要确认的端口有两个13724客户端bpcd监听端口master 发起备份指令时要用它跟 Oracle 主机通信1556NBU 的 private network 相关端口涉及 master 与 media 之间、以及 client 与 media 之间的数据连接# 在 master 上测试到 Oracle 主机 13724 端口的连通性 telnet oracle-host 13724 # 测试到 media 主机的 1556 端口 telnet media-host 1556telnet 命令算是排查端口问题最快的手段。连不上时先区分是防火墙拦了还是服务没起来。客户端上执行netstat -lnp | grep 13724能看到 bpcd 是否在监听没有监听说明 agent 服务没起来或者被防火墙策略挡了。还有一个很隐蔽的点三个主机的/etc/hosts中的名字要跟 NBU master 上注册的 client 名称保持一致。NBU 对 client 的识别不是按 IP 来的是主机名。主机名不一致会导致 master 下发任务时使用的目标主机名与 Oracle 主机实际的 hostname 不匹配表现为备份任务失败、日志提示 client 无法连接。建议把三台主机的 IP 和主机名都写进彼此的/etc/hosts并且使用完整的短主机名不要混用 FQDN 和短名。3.3 Clients 配置的两个选项不能选错policy 的 Clients 部分有两个层次容易混淆。第一层是选择client for use with scripts也就是让这个 policy 以脚本方式驱动备份。第二层是在客户端列表里添加实际的数据库客户端——这里的客户端是 Oracle 主机本身选的是那个装了 agent 的机器。有人会问直接选client for use with scripts然后把 Oracle 主机加进列表是不是就行了还不够。备份选择Backup selections里指到 RMAN 脚本才是整个逻辑闭环的关键一步。默认的示例脚本路径在 agent 安装目录下/usr/openv/netbackup/ext/db_ext/oracle/samples/rman常用的脚本是hot_database_backup.sh。它的名字已经说明用途热备份要求数据库处于 ARCHIVELOG 模式否则无法保证一致性。3.4 Schedule 设置Full、Incremental 和 Cumulative 分别对应什么Schedule 的设定大多数人都会做但容易忽略的是Oracle 类型的 schedule 名称和类型会被传递到 RMAN 脚本中变成NB_ORA_FULL、NB_ORA_INCR、NB_ORA_CINC这样的环境变量。也就是说你在 master 上建一个名为 “FULL_BACKUP” 的 schedule、类型选 Automatic Full实际执行时这个信息会传给 RMAN 脚本进而决定本次备份是 level 0 的全量还是 level 1 的增量。Schedule 类型NBU 传入变量脚本生成的备份行为Automatic FullNB_ORA_FULL1INCREMENTAL LEVEL0即全备Automatic Differential IncrementalNB_ORA_INCR1INCREMENTAL LEVEL1差异增量Automatic Cumulative IncrementalNB_ORA_CINC1INCREMENTAL LEVEL1 CUMULATIVE累积增量这个映射关系在脚本内部以 if/elif 分支处理下面一章展开讲。这里先记住一个结论schedule 类型的选择不是 master 侧的事它会直接改变 RMAN 脚本的备份行为。4. 定制 hot_database_backup.sh变量修改、调度映射与通道参数4.1 为什么不能直接改原脚本升级会覆盖不是玩笑NBU 客户端升级时会重新覆盖/usr/openv/netbackup/ext/db_ext/oracle/samples/rman/目录下的示例脚本。如果你直接把生产用的变量改在了原文件里一次客户端小版本升级后你精心调好的 ORACLE_HOME、连接串、SBT 库路径就全部回到默认值。备份任务继续跑但它连接的是默认库还是报错取决于你的环境有多幸运。稳妥做法是从样例目录把脚本复制到一个独立目录例如/home/oracle/scripts/或/usr/openv/scripts/然后在副本上修改。备份选择里填的路径也指向副本。# 复制脚本到独立位置 mkdir -p /home/oracle/scripts cp /usr/openv/netbackup/ext/db_ext/oracle/samples/rman/hot_database_backup.sh /home/oracle/scripts/ chmod 755 /home/oracle/scripts/hot_database_backup.sh chown oracle:dba /home/oracle/scripts/hot_database_backup.sh注意最后两步脚本要能被执行需要有可执行权限因为有su - oracle切换逻辑属主最好设成 oracle 用户避免权限边界问题。4.2 用户自定义变量段只动这一段就够了脚本中明确标注了 USER CUSTOMIZABLE VARIABLE SECTION正常情况下你只需要修改这一小段。其他部分像是日志重定向、信号处理、SBT 通道构建保持原样就行。ORACLE_HOME/u01/app/oracle/product/11.2.0/db_1 ORACLE_SIDorcl1 ORACLE_USERoracle ORACLE_TARGET_CONNECT_STRsys/sys_password RMAN_EXECUTABLE$ORACLE_HOME/bin/rman RMAN_SBT_LIBRARY/usr/openv/netbackup/bin/libobk.so64 RMAN_CATALOGnocatalog BACKUP_SCHEDULE BACKUP_TAGhot_db_bk export ORACLE_HOME ORACLE_SID逐项说清楚这些变量是干什么的ORACLE_HOME目标库的安装路径11.2.0.4 的典型路径是/u01/app/oracle/product/11.2.0/db_1但每台机器可能不同以grep ORACLE_HOME /etc/oratab或者echo $ORACLE_HOME的实机结果为准不要照抄。ORACLE_SID要备份的实例名。一个主机上如果装了多个实例每个实例需要一套独立的脚本副本变量不能混用。ORACLE_TARGET_CONNECT_STRRMAN 连接目标库的连接串格式是sys/密码tns别名或直接sys/密码。这里不建议用/操作系统的 sysdba 认证因为脚本是通过 su 切换用户执行的结合信任关系可能会出现奇怪的认证环境。明确写用户名密码虽然放在脚本里有安全隐患但生产上普遍是这种妥协配合文件权限管控即可。RMAN_SBT_LIBRARYSBT 媒体管理库路径。/usr/openv/netbackup/bin/libobk.so64是 Linux 64 位的标准位置这个值基本不用动。RMAN_CATALOG用nocatalog即不依赖独立的恢复目录控制文件自身记录备份信息。如果公司有 catalog 库改成catalog rman_user/rman_passcatalog_tns也行但要注意恢复时对 catalog 的依赖关系。这里有一个常见误区是只改 ORACLE_HOME 和 ORACLE_SID不改连接串。默认脚本里的示例连接串格式不完全一样直接跑会出现target database not started或者权限不足之类的问题。每份脚本副本的ORACLE_TARGET_CONNECT_STR必须确认可用。4.3 调度类型怎么驱动备份级别三个环境变量的分支逻辑脚本中段有一段 if/elif 分支根据 NBU 传入的环境变量决定备份动作。这段逻辑是理解“master 上的 schedule 为什么会改变备份类型”的关键。if [ $NB_ORA_FULL 1 ]; then BACKUP_TYPEINCREMENTAL LEVEL0 BACKUP_TAG${BACKUP_TAG}_inc_lvl0 elif [ $NB_ORA_INCR 1 ]; then BACKUP_TYPEINCREMENTAL LEVEL1 BACKUP_TAG${BACKUP_TAG}_inc_lvl1 elif [ $NB_ORA_CINC 1 ]; then BACKUP_TYPEINCREMENTAL LEVEL1 CUMULATIVE BACKUP_TAG${BACKUP_TAG}_inc_lvl1_cinc elif [ $BACKUP_TYPE ]; then BACKUP_TYPEINCREMENTAL LEVEL0 BACKUP_TAG${BACKUP_TAG}_inc_lvl0 fi这段逻辑说明几件事NBU 的 Full 调度实际会生成 RMAN 的 level 0 备份不是特殊标记的全备而是“可以作为增量备份基准的全备”。Differential 调度生成 level 1只备份上次 level 0 或 level 1 之后变化的数据块。Cumulative 调度生成 level 1 CUMULATIVE备份上次 level 0 之后所有变化的数据块文件更多但恢复时只需要最后一个 cumulative level 0。手工执行脚本且 NBU 环境变量为空时会落入最后一个 elif默认也是做 level 0 全备。这意味着你手动在 shell 里跑这个脚本触发的是全量备份不要等它跑完以为是增量。4.4 通道分配与 FORMAT 参数两个通道、格式必须以 %t 结尾脚本里的 RMAN RUN 块分配了两个 SBT 通道 ch00、ch01。SBT 通道的含义不是本地磁盘是让 RMAN 把数据写到 NetBackup 的介质管理服务。ALLOCATE CHANNEL ch00 TYPE SBT_TAPE PARMS SBT_LIBRARY/usr/openv/netbackup/bin/libobk.so64; ALLOCATE CHANNEL ch01 TYPE SBT_TAPE PARMS SBT_LIBRARY/usr/openv/netbackup/bin/libobk.so64;数据库备份部分的关键参数BACKUP INCREMENTAL LEVEL0 SKIP INACCESSIBLE TAG hot_db_bk_inc_lvl0 FILESPERSET 5 FORMAT bk_%s_%p_%t DATABASE;几个参数各自的用途FILESPERSET 5控制每个备份集最多包含 5 个数据文件。文件数设得越大备份集越少但单个文件集损坏时影响面也越大。生产库我一般保留这个默认值。FORMAT bk_%s_%p_%t这个格式字符必须足够唯一且以%t结尾。%s是备份集编号%p是通道内的片段号%t是时间戳。以%t结尾能保证文件名的唯一性避免多个备份周期之间出现同名镜像。如果你在%t后面又加了别的字符可能导致 NetBackup 在恢复时解析镜像失败。SKIP INACCESSIBLE遇到不可读的数据文件时跳过而不是整个备份失败。注意这会让备份成功但实际缺少文件所以备份完成后要核对镜像内容不能只看任务状态。归档日志备份块会单独分配两个通道FILESPERSET 20格式为al_%s_%p_%t最后带DELETE INPUT。这个 DELETE 是在归档日志成功写入备份介质后才删除源文件释放数据库空间的机制。担心日志被提前删掉的可以改掉但长期不删会导致磁盘被归档日志撑满两害相权还是保留原样更合理。4.5 脚本里的 su 切换与日志机制理解了两处就能排查一半问题脚本设计成由 root 执行内部su - oracle切换到数据库属主用户再调用rman。这样脚本本身可以由 NBU 的调度进程以 root 身份拉起又能在 oracle 用户环境下操作数据库。日志输出被重定向到了$0.out也就是脚本同目录下以脚本名命名的 .out 文件。每次执行前会先删除旧日志避免无限增长。这个行为有双面性好处是日志文件不会撑爆磁盘坏处是上次的失败现场被清掉了排查问题时拿不到历史记录。建议在删除日志那块代码前加一行cp $RMAN_LOG_FILE $RMAN_LOG_FILE.$(date %Y%m%d%H%M%S)保留最近几次的执行现场。if [ -f $RMAN_LOG_FILE ]; then cp $RMAN_LOG_FILE $RMAN_LOG_FILE.$(date %Y%m%d%H%M%S) rm -f $RMAN_LOG_FILE fi这样每个备份周期都会留下轮转日志排查问题时看时间戳最新的那个就好。5. 常见问题与避坑指南五条高频故障的定位与处理这一节列的五个问题全部来自实际环境中反复出现的情况每一条都按现象、原因、解决三个层次展开。5.1 现象token 界面粘贴后按回车安装卡住不动现象是安装进程在“Enter token”界面永远无响应看起来像死机。原因是 token 输入框是密码框粘贴后无任何回显很多人以为没粘贴上又点了一次或者按了多次回车把换行符也当成了输入内容token 实际是不完整的。安装流程里 token 校验失败后并不会立刻报错它会停留在这个界面等用户重试给人“卡住”的错觉。解决方法是粘贴一次、回车一次然后耐心等待。判断 token 是否真正粘贴上可以在粘贴后随便敲一个字符再删掉观察界面是否有变化——密码框允许输入删除也是没有回显的但行为上是一个完整输入过程。这个办法土但能解决至少一半的“token 卡死”问题。5.2 现象备份任务在队列里转圈最终状态显示“Client is not connected”现象是 master 上已经提交的任务长时间处于 Active/Queued最终失败错误信息指向 client 连接失败。原因是三台主机之间的主机名解析不一致。master 通过bpcd连 Oracle 主机时用名字连而不是用 IPmaster 认识的名字跟 Oracle 主机自己/etc/hosts里写的名字不一样导致连接目标错误。解决方法是统一三台主机的/etc/hosts配置。三台机器必须能互相用短主机名解析对方。然后再在 Oracle 主机上执行bpclntcmd -pn确认本机被 master 认可的名称如果显示的名称跟hostname命令的结果不一致需要检查 NBU client 注册名配置。5.3 现象RMAN 报ORA-01017: invalid username/password或target database not started现象是手动或调度执行脚本时RMAN 连接目标数据库失败。原因是ORACLE_TARGET_CONNECT_STR写错或者脚本运行用户因为 su 切换后的环境变量问题导致 RMAN 连接串解析异常。另一种可能是密码中带了特殊字符如、#不加处理时会被解析成分隔符。解决方法是先手动验证连接串su - oracle -c export ORACLE_HOME/u01/app/oracle/product/11.2.0/db_1; export ORACLE_SIDorcl1; $ORACLE_HOME/bin/rman target sys/密码orcl1 nocatalog如果密码带考虑加双引号包住整个连接串或者临时改用操作系统认证模式确认 RMAN 本体能跑通再回切到密码认证。5.4 现象备份报告成功但恢复时发现缺少部分数据文件现象是任务状态 Success但实际恢复时缺文件。原因通常出在SKIP INACCESSIBLE参数上。它让 RMAN 跳过不可访问的数据文件但 NBU 的任务状态依然显示成功。解决方式是每次备份完成后检查控制文件中的备份记录su - oracle -c export ORACLE_HOME/u01/app/oracle/product/11.2.0/db_1; export ORACLE_SIDorcl1; $ORACLE_HOME/bin/rman target / nocatalog RMAN list backup of database;重点看这份列表里的数据文件数量是否跟v$datafile中的记录一致。另一个更直接的办法是把SKIP INACCESSIBLE注释掉让备份失败得明明白白而不是成功得稀里糊涂。5.5 现象升级客户端后备份行为异常现象是 NBU 客户端从 8.3.0.2 升级到更高版本后备份脚本行为与之前不同或直接报错。原因是脚本被覆盖了。/usr/openv/netbackup/ext/db_ext/oracle/samples/rman/下的样例脚本在升级过程中会被重置所有自定义变量丢失。解决方式在前面已经讲过生产脚本必须放到独立目录并且把 policy 的 Backup selections 指向独立目录的副本。从那以后我每次部署前都会先确认脚本路径不在samples目录之下从源头杜绝这个问题。6. 备份完成后的验证手法bplist 查镜像与最小恢复测试6.1 任务状态与备份镜像的双重确认备份任务跑完之后第一件事不是看任务栏打勾就收工。NBU 控制台的 Activity Monitor 显示 Successful 只代表作业执行完毕不保证数据可恢复。我会把任务状态和备份镜像列表结合起来确认。6.2 用 bplist 检查数据库备份镜像bplist 是 NBU 提供的命令行查询工具能按策略和客户端列出备份镜像。Oracle 数据库备份的镜像路径通常是客户端的绝对路径加政策信息直接查镜像是确认介质上真的有数据可用的最快方式。/usr/openv/netbackup/bin/bplist -C oracle-host -S master-server -r /oracle/orcl1 -l参数说明-C文件名加客户端名这里是 Oracle 主机名-S指定 master server 名称-r表示递归列出目录内容-l输出详细信息包含备份时间与实际文件路径如果这个命令列出的镜像列表是空的即便控制台显示成功这次备份也大概率没有把数据真正传到位。出现这种情况时去检查 policy 的 Backup selections 路径是否指向了正确的脚本副本以及脚本里RMAN_SEND部分的NB_ORA_*环境变量传给 NetBackup 后是否正确。6.3 最小化恢复验证不建完整库也能验证镜像可读完整恢复测试在有些环境里成本很高但至少要做一次控制文件的恢复验证。控制文件的备份在脚本末尾通过FORMAT cntrl_%s_%p_%t完成恢复控制文件只需要在 RMAN 里执行一条命令su - oracle -c export ORACLE_HOME/u01/app/oracle/product/11.2.0/db_1; export ORACLE_SIDorcl1; $ORACLE_HOME/bin/rman target / nocatalog RMAN STARTUP NOMOUNT; RMAN RESTORE CONTROLFILE FROM cntrl_*; RMAN ALTER DATABASE MOUNT;这里FROM cntrl_*是通配符匹配 NetBackup 介质中的控制文件备份。控制文件能恢复成功基本可以确认 SBT 通道、备份格式、连接都没问题。至于数据文件和归档日志的完整恢复找一个下游窗口做一次全量恢复演练更稳妥但控制文件已经是第一道让大多数问题现形的验证。归档日志删除策略也要在这里验证。脚本里ARCHIVELOG ALL DELETE INPUT会在备份成功后删除已备份的本地归档。如果备份任务跑了几天后磁盘空间告急先看这次备份是否真实成功、介质上有没有对应镜像。曾经遇到过DELETE INPUT正常执行但备份镜像损坏的情况导致归档日志已经没了、镜像又不可用恢复手段直接清零。这就是为什么每次配完我都强制走一遍 bplist 加控制文件恢复两件事加起来用不了十分钟但能把“纸面成功”变成“手里有粮”的确定性。从那以后我每接到一套新环境第一件事就是跑这个验证组合再谈后续的备份策略优化。希望这次整理的配置与排查过程能让你在这个过程中少走几个我走过的弯。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
