DB2异机恢复实战：NBU备份配置与日志前滚避坑指南

发布时间：2026/10/11 20:03:51
DB2异机恢复实战：NBU备份配置与日志前滚避坑指南
简介文档围绕DB2异机恢复场景展开面向需要借助NetBackup实现数据库迁移与灾难恢复的DBA及运维工程师重点解决备份后在异机重建DB2数据库的配置与实操问题。资源为doc格式仅1个文件压缩包314KB内容精炼但覆盖完整。正文从DB2 Agent的配置入手说明运行db2_config将用户出口程序db2uext2复制到实例目录并开启userexit、logretain、trackmod三个参数以进入归档日志与增量备份模式同时强调在线备份前需断开所有应用连接并先完成一次全备份。随后重点分析备份脚本db2_backup中的环境变量含义以及db2.conf中对数据库备份和归档日志备份各自的策略设定包括OBJECTTYPE、POLICY、SCHEDULE以及ARCFUNC、RETDIR等关键项其中ARCFUNC用于指定归档日志保存方式RETDIR用于设定保存目录并给出可直接参考的示例配置。目前已有335人学习下载适合作为DB2异机恢复从环境准备到策略落地的参考资料。1. DB2 异机恢复为什么备份能成功、恢复却总卡在 NBU 的身份校验上DB2 异机恢复通俗讲就是在一台新机器上用 NetBackup 里已有的备份把源库完整还原出来。很多 DBA 的第一反应是「把备份文件拷过来再 db2 restore 不就行了」真动手才发现卡点几乎都不在 DB2 命令本身而在 NBU 的客户端识别机制上它默认不允许非源客户端发起恢复请求这一条就能拦住绝大多数人。这份资源是一整套 NBU for DB2 的备份恢复操作手册从 Agent 配置、DB2 参数调整、备份脚本、策略创建到 offline/online 恢复和异机恢复全都覆盖了正是生产环境里从零搭备份系统的完整路径。适合正在做 DB2 备份方案、或者手里有 NBU 备份但从没验证过异机恢复的运维和 DBA。即使你现在用的是 DB2 10.5 或 11.1这套接入逻辑也基本没变。我在实际项目里见过不少团队同机恢复跑通了就以为万事大吉直到机房迁移、备机接管那天才发现异机恢复根本没验证过。这类演练最好在备份系统上线时就完整走一遍等真要用再排错压力完全不同。下面按「配置 → 备份 → 恢复 → 异机 → 验证」的顺序把每一步的命令和容易踩的坑都标出来。2. 恢复前的两份关键配置三个 DB2 参数与 db2.conf 的每一行2.1 三个 DB2 参数userexit、logretain、trackmod 为什么必须一起改DB2 默认跑在循环日志模式下日志写满就覆盖这种模式只能做 offline 备份更谈不上把归档日志送到 NBU。要做在线备份和可靠的日志归档必须先把三个参数一起打开。很多人只改了 logretain忘了 userexit结果日志还是没进 NBU或者只开前两个、没开 trackmod等配增量备份策略时才发现数据库根本不支持。db2 update db cfg for sample using userexit on db2 update db cfg for sample using logretain on db2 update db cfg for sample using trackmod yes db2 terminate这三行命令执行的顺序无所谓但建议全部执行完以后跑一次db2 terminate确保没有连接挂在上面。参数要等所有应用和连接都断开后才会真正写入配置文件并生效这也是新手最容易忽略的执行完命令马上查配置发现还是 off就以为命令写错了。参数默认值作用不开启的后果userexitoff启用用户出口程序日志归档交给 NBU归档日志无法写入 NBUlogretainoff切换为归档日志模式无法做 online 备份trackmodoff跟踪页级修改支持增量备份增量备份策略不可用注意trackmod这个参数在多数 DB2 版本里接受的值是yes写成on会直接报参数无效。改完参数后必须对数据库做一次全备份否则数据库会处于不可连接状态这是归档日志模式切换的正常行为不是故障。2.2 db2_config 脚本与用户出口程序 db2uext2 的落位Agent 装完后NBU 会要求运行/usr/openv/netbackup/bin/db2_config它的核心工作是把用户出口程序db2uext2复制到实例目录db2instance/sqllib/adm/下。DB2 的 userexit 机制就是靠这个可执行文件在日志归档和取回时被调用没有它logretain 和 userexit 开了也白开。/usr/openv/netbackup/bin/db2_config ls -l $HOME/sqllib/adm/db2uext2如果机器上有多个 DB2 实例建议在执行前先把DB2INSTANCE环境变量指到目标实例否则 db2_config 可能把文件装到最后一个实例的目录下。跑完后确认db2uext2存在且带可执行权限顺便看下db2.conf和db2_backup是否自动生成到了 NBU 的安装目录里后面两节要改的就是这两个文件。2.3 db2.conf 两段配置DATABASE 段与 ARCHIVE 段的每一行含义db2.conf 是 NBU 执行备份和恢复时读取的配置文件内容分两段DATABASE 段管数据库本身的备份与恢复ARCHIVE 段管归档日志。每段都以DATABASE开头、ENDOPER结尾。异机恢复时关键就在这两段里都要加一行CLIENT_NAME这个问题后文会展开这里先把结构说清楚。DATABASE BI OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup CLIENT_NAME gdccas670 ENDOPER DATABASE BI OBJECTTYPE ARCHIVE POLICY User_Backup SCHEDULE UserBackup ARCFUNC SAVE CLIENT_NAME gdccas670 ENDOPER配置行作用常见错误DATABASE指定要恢复的数据库名写成源库实例名OBJECTTYPEDATABASE 或 ARCHIVE区分备份对象两段都写 DATABASEPOLICY对应 NBU 里创建的策略名ARCHIVE 段误用 DB2 类型策略SCHEDULE对应策略下的备份计划名与策略不匹配ARCFUNCSAVE 保存日志到 NBUCOPY 保存到本地目录不写则日志不归档CLIENT_NAME指定源客户端主机名异机恢复必填漏写导致恢复找不到备份ARCFUNC SAVE表示归档日志保存到 NBU 存储COPY模式会把日志复制到ARCDIR指定目录。多数生产环境用 SAVE日志直接进 NBU异机恢复时才能从 NBU 取回。如果你用了ARCFUNC COPY且把ARCDIR和RETDIR写在注释状态恢复时日志链路大概率是断的。3. 备份侧落地db2_backup 脚本改造与 NBU 策略创建3.1 db2_backup 脚本NBU 注入的环境变量决定备份类型Agent 装好后会自动生成一个备份脚本db2_backupNBU 的bphdb进程执行它时会往环境变量里塞入DB2_FULL、DB2_CINC、DB2_INCR值分别是 1 或 0。脚本靠这几个变量判断当前跑的是全备、累积增量还是差异增量。这几个变量的值由策略里的 Schedule 类型决定不用手动改。echo DB2_FULL $DB2_FULL # 1 表示全备份 echo DB2_CINC $DB2_CINC # 1 表示累积增量备份 echo DB2_INCR $DB2_INCR # 1 表示差异增量备份脚本下发时这些 echo 会写进 NBU 的任务日志。排错时先看任务日志里这几个变量的值能快速判断是不是 Schedule 类型配错了。比如策略配的是全备份 Schedule但日志里DB2_FULL0那问题一定出在策略与 Schedule 的对应关系上。MY_LIB是另一个必须改的变量它指定 NBU 提供的 vendor 库文件。不同平台、不同位数库文件名完全不一样选错会在备份命令执行时报“load library failed”。平台库文件名Solaris / Linux 32 位nbdb2.soSolaris 64 位nbdb2.so64AIX / HP-UX 32 位nbdb2.slAIX / HP-UX 64 位nbdb2.sl643.2 按备份类型拼接 CMD_LINE全备、增量与多数据库脚本的核心逻辑是把 DB2 备份命令拼成一行再以指定用户身份执行。这里给出一个改造后的骨架我在生产环境里一般会保留原脚本结构只改参数和追加数据库MY_LIB/usr/openv/netbackup/bin/nbdb2.sl MY_DB2DWDB MY_USERdwccbxm if [ $DB2_FULL 1 ]; then MY_SCHED elif [ $DB2_CINC 1 ]; then MY_SCHEDINCREMENTAL elif [ $DB2_INCR 1 ]; then MY_SCHEDINCREMENTAL else MY_SCHED fi CMD_LINEdb2 BACKUP DATABASE $MY_DB2 ONLINE $MY_SCHED LOAD $MY_LIB echo Executing: $CMD_LINE su - $MY_USER -c $CMD_LINE RETURN_STATUS$? exit $RETURN_STATUS逻辑说明脚本根据 NBU 注入的三个环境变量决定MY_SCHED是空还是INCREMENTAL。空字符串表示全备INCREMENTAL表示增量备份。生成的CMD_LINE由db2 BACKUP DATABASE、库名、ONLINE、增量关键字和LOAD $MY_LIB组成LOAD后面接的是 vendor 库路径DB2 通过它把备份流写进 NBU。su - $MY_USER -c保证备份命令以 DB2 实例用户身份执行避免权限问题。参数说明如果做 offline 备份要删掉ONLINE关键字。$MY_USER必须有该数据库的 dbadm 或更高权限。同一脚本里要给多个库做备份就多复制几行 CMD_LINE逐个su执行不要合并成一条命令否则一个库失败会影响后面所有库。3.3 NBU 策略创建DB2 类型策略 Standard 日志策略备份脚本准备好后要在 NetBackup Administration Console 里建策略。常规做法是先建一个类型为 DB2 的策略负责数据库备份如果做在线备份再建一个 Standard 类型的策略负责归档日志备份。只有 DB2 策略而没有日志策略日志不会自动进 NBU在线恢复时日志链路是断的。创建 DB2 策略的完整步骤是右键 Policies 选择 New输入策略名Policy type 选 DB2指定存储单元和卷池Clients 里添加数据库主机Backup Selections 里填 db2_backup 脚本的绝对路径注意这里填的是脚本路径不是数据库路径最后在 Schedules 里创建备份计划。Schedule 类型和备份动作的对应关系如下Schedule 类型对应备份Automatic Full Backup全备份Automatic Differential Incremental Backup差异增量备份Automatic Cumulative Incremental Backup累积增量备份User Backup手动触发日志归档策略用在线备份时另建的 Standard 策略关键是 Schedules 里要配一个 User Backup 类型的计划名字要和 db2.conf 的 ARCHIVE 段里SCHEDULE一致。这一步配错不会在备份时报错而是在恢复时日志取不回来属于典型的隐性坑。4. 同机恢复先跑通bplist 定位、restore 与 rollforward 的边界4.1 用 bplist 定位备份版本时间戳就是 restore 的 taken at 参数恢复前第一件事是确认恢复哪个备份版本。NBU 的命令行工具bplist可以列出指定客户端、指定类型的所有备份记录输出里那个长数字就是备份的精确时间点后面 restore 命令直接用它做taken at参数。bplist -C gdccas670 -t 18 -R //DB2/BI参数说明-C指定源客户端主机名-t 18表示按 DB2 备份类型过滤18 是 NBU 对 DB2 备份的类型编码-R是递归列出路径。输出里类似20050226120711的目录名就是备份时间戳格式是年月日时分秒。如果输出为空先确认策略类型是不是 DB2再确认客户端名大小写NBU 对主机名大小写敏感。4.2 OFFLINE 备份恢复without rolling forward 为什么不能省Offline 备份得到的数据库文件本身是一致的恢复后不需要做日志前滚。命令里必须带without rolling forward告诉 DB2 这是完整还原否则即使备份是一致的DB2 也会进入 rollforward pending 状态应用无法连接。su - db2inst1 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.sl without rolling forward without prompting参数说明load后面接 NBU 的 vendor 库路径DB2 通过它从 NBU 存储读取备份流without rolling forward跳过日志前滚without prompting避免恢复过程交互式询问。如果目标机上数据库不存在要加to /db_dir指定数据目录否则会报路径错误。恢复到指定版本时命令改成db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.sl taken at 20050226120711 without rolling forward without promptingtaken at的时间戳就是 bplist 查到的目录名注意保持 14 位数字完整少一位 DB2 会直接报语法错误。4.3 ONLINE 备份恢复restore 之后必须 rollforwardOnline 备份在备份过程中日志是活跃的备份文件内部时间点不一致所以恢复后必须做日志前滚把数据库推到一致状态。这也是 online 和 offline 恢复流程上最大的区别online 恢复永远带着 rollforwardoffline 恢复永远带着 without rolling forward。db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.sl taken at 20050226120711 db2 rollforward db bi to end of logs and complete第一行 restore 用taken at指定版本第二行 rollforward 把日志前滚到末端并结束。如果只需要恢复到某个时间点用db2 rollforward db bi to 2005-02-26-12:07:11 using local time and complete这里有个血泪经验部分 DB2 版本不支持using local time选项报错后直接去掉即可但此时要求操作系统时间与标准时间一致如果系统时间有偏差做时间点恢复时要手动把目标时间减去时差否则恢复出来的数据会是错的而且这个错误不会报出来只能靠数据核对发现。5. 异机恢复实战与避坑清单No.Restrictions、CLIENT_NAME 和五个翻车点5.1 异机恢复的启用开关No.Restrictions 空文件NBU 默认只允许发起备份的源客户端执行恢复操作这是它的客户端身份校验机制。异机恢复前必须在 Master Server 上用 root 权限创建一个空文件/usr/openv/netbackup/db/altnames/No.Restrictions作用是放行所有主机对备份的访问请求。touch /usr/openv/netbackup/db/altnames/No.Restrictions chmod 644 /usr/openv/netbackup/db/altnames/No.Restrictions创建后不需要重启 NBU 服务立即生效。No.Restrictions是全局放行如果担心安全边界可以在同一目录下创建以源客户端主机名为文件名、内容写入目标主机名的文件实现单对单放行。我一般在内网环境直接用 No.Restrictions跨网段或安全要求高的环境用单对单方式。这个文件缺失时恢复命令不会报“文件不存在”而是报找不到备份或权限错误非常容易误判。5.2 目标机准备与 db2.conf 加 CLIENT_NAME异机恢复的目标机需要提前装好与源库版本一致或更高的 DB2以及 NBU client并运行过db2_config。实例名尽量与源机保持一致因为备份记录里包含实例路径信息实例名不同会直接影响 restore 的路径映射。db2.conf 的关键改动是DATABASE 段和 ARCHIVE 段中都要增加一行CLIENT_NAME值为源客户端主机名。DATABASE BI OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup CLIENT_NAME gdccas670 ENDOPERCLIENT_NAME的作用是告诉 NBU虽然发起恢复的是本机但数据源来自 gdccas670 这台主机。漏写这一行restore 命令会去当前主机找备份结果自然是空的。如果目标机数据库名与源库不同restore 命令里要加to指定目录同时确认目标机磁盘路径可用且空间充足。5.3 异机恢复完整命令序列这里给出一套可照抄的命令序列前提是假设源库的最后一个备份是 online 备份需要前滚日志# Master Server 上以 root 执行一次 touch /usr/openv/netbackup/db/altnames/No.Restrictions # 目标机切换为 DB2 实例用户 su - db2inst1 # 从 NBU 读取备份并还原到指定目录 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.sl taken at 20050226120711 to /db_dir replace existing # 前滚日志到一致状态 db2 rollforward db bi to end of logs and complete逻辑说明replace existing用于目标机存在同名库的情况等价于先 drop 再 restore省一步操作to /db_dir是异机恢复里最常用的路径重定向参数因为目标机文件系统布局通常与源机不同。整套序列执行下来比同机恢复多出来的只有三处Master Server 的空文件、db2.conf 的 CLIENT_NAME、restore 命令里的to路径。参数说明如果源备份是 offline 备份去掉 rollforward 那行并在 restore 行加上without rolling forward。如果不知道备份时间点先bplist -C gdccas670 -t 18 -R //DB2/BI查出来再填。命令顺序不能反过来restore 没完成就 rollforward 会直接报数据库处于 restore pending 状态。5.4 五个常见翻车点1. 现象restore 报找不到请求的备份或提示客户端无权限。原因Master Server 上没有创建 No.Restrictions 文件或 db2.conf 漏写 CLIENT_NAME。解决确认ls /usr/openv/netbackup/db/altnames/No.Restrictions存在确认两段配置里都有CLIENT_NAME gdccas670然后重跑 restore。2. 现象restore 报 SQL2526N提示目标数据库已存在且与备份不匹配。原因目标机上已经有同名数据库。解决要么db2 drop db bi后重跑要么在 restore 命令加replace existing。注意 drop 前确认目标库没有需要保留的数据这一步没有后悔药。3. 现象rollforward 一直停在 waiting for log 状态或者报日志文件缺失。原因ARCHIVE 段的日志归档策略配置不对归档日志根本没进 NBU或者RETDIR指向的本地目录里没有日志。解决先查 db2.conf 的 ARCHIVE 段是否配了ARCFUNC SAVE再确认 Standard 策略和 User Backup Schedule 的名字与配置一致。4. 现象备份脚本执行时报 load library 失败。原因MY_LIB的平台库选错32 位系统配了 64 位库或反过来。解决按第 3.1 节的平台对应表核对AIX 上最常见的是把 nbdb2.sl44 和 nbdb2.sl64 搞混。5. 现象异机恢复后应用连接报错SQL6031N 或类似错误。原因目标机 DB2 版本低于源机或实例路径不同导致 db2nodes.cfg 不匹配。解决目标机 DB2 版本必须不低于源机恢复完成后用db2rbind重新绑定所有包这个命令能解决大部分跨主机恢复后的应用连接问题。6. 恢复后的三层验证与一个能救命的技巧6.1 验证恢复结果连接、表空间、日志序号恢复命令返回成功不代表数据能直接用。我每次恢复完都按下面三层验证缺一不可。第一层是应用层验证用业务账号连一次库执行简单查询确认库可用第二层是表空间状态验证重点看是否有表空间处于 restore pending 状态。db2 connect to bi db2 list tablespaces show detail db2pd -logsdb2 list tablespaces show detail的输出里State 字段应该显示0x00000000表示正常。如果显示0x00001000之类的值说明表空间还在 pending 状态通常是 rollforward 没做完整。第三层看日志序号db2pd -logs输出当前日志文件和时间点对照恢复前记录的源库日志序号能确认前滚是否真的追到了目标时间这一步是时间点恢复后核对数据最直接的手段。6.2 把恢复过程脚本化生产环境的恢复往往要重复多遍尤其是验证阶段。我习惯把 restore 和 rollforward 封装成一个带参数的脚本避免每次手敲命令敲错时间戳#!/bin/sh DBNAME$1 TAKEN_AT$2 TARGET_DIR$3 VENDOR_LIB/usr/openv/netbackup/bin/nbdb2.sl db2 restore db $DBNAME load $VENDOR_LIB taken at $TAKEN_AT to $TARGET_DIR replace existing if [ $? -eq 0 ]; then db2 rollforward db $DBNAME to end of logs and complete fi调用时执行sh restore.sh bi 20050226120711 /db_dir即可。脚本里对 restore 的返回码做了判断只有 restore 成功才执行 rollforward避免在 restore 失败时把数据库推到更糟的状态。从那以后我每次做异机恢复演练都强制走一遍这套流程先查 No.Restrictions 是否在位再核对 db2.conf 的 CLIENT_NAMErestore 完必查表空间和日志序号。这套习惯帮我挡掉过至少三次备机接管的翻车现场希望也能帮到你。本文还有配套的精品资源点击获取