简介《DB2异机恢复》是一份面向DB2数据库管理员与备份运维人员的实战型文档聚焦借助NetBackup完成DB2数据库的异机恢复与备份配置适合需要掌握企业级数据库容灾流程的初中级技术人员参考。压缩包内仅含1个doc文件大小约314KB内容围绕Agent安装后的db2_config配置、db2uext2用户出口程序复制、userexit与logretain参数调整、trackmod增量备份启用以及db2_backup脚本和db2.conf策略文件展开。文档还涉及备份策略、归档日志、ARCFUNC与RETDIR等关键设置可帮助读者理解在线备份与异机恢复的配置脉络。目前已有340人学习适合用作NetBackup环境下DB2备份恢复的查阅资料与实操参照。1. DB2 异机恢复不是把 restore 敲一遍这次换机器捞库的完整落地手里管着一套跑了几年 DB2 的环境最怕听到的一句话是“备份每天都在跑没问题”。备份作业在 NBU 里全绿只能说明作业调度没掉链子证明不了真出事时换一台机器能把库捞出来。DB2 异机恢复是另一码事源主机上的 Agent 配置、db2uext2 出口程序有没有落到实例目录、LOGRETAIN 和 USEREXIT 到底开没开、db2.conf 里的 CLIENT_NAME 写没写、目标端的库文件名和路径对不对任何一环错位restore 都会在最后一步告诉你找不到镜像或者库起不来。这篇按我自己跑过的一轮演练顺序写先把版本和组件列清并固化再落地备份侧的 db2.conf 和 db2_backup然后开异机开关、跑恢复命令最后给一套能验证“确实恢复到点上了”的检查动作。手上管着 DB2 加 NBU、被要求做容灾演练或者真要搬库的人可以照着走一遍。2. 装前盘环境DB2 实例、NBU 客户端与 db2uext2 出口程序这一章别急着敲 restore。异机恢复和同机恢复最大的区别在于执行恢复的机器不是产生备份的机器NBU 要先相信“这台机器有资格取走别人的备份”DB2 要先相信“这台机器上装好了能跟 NBU 对接的出口程序”。这两件事在装的时候没做全后面所有命令都只是在验证失败原因。我习惯先画一张两列的清单源主机一行、目标主机一行把实例名、实例用户、实例目录、NBU 客户端版本、库文件名、备份策略名全部对齐然后再动手。2.1 把源端和目标端的组件盘成一张表DB2 异机恢复的失败八成以上不是命令写错而是两边环境不一致。先把下面这张表填满填不出来的格子就是你要补的活。检查项源主机 db2src01目标主机 db2tgt02确认方式DB2 实例名bi建议建同名实例db2ilist实例用户与家目录db2inst1 //home/db2inst1同名同路径最省事id db2inst1NBU 客户端是否安装已装必须装且版本与 Master 对齐ls /usr/openv/netbackup/bin/admincmdDB2 Agent 组件已装已装ls /usr/openv/netbackup/bin/ | grep db2db2uext2 出口程序在sqllib/adm下恢复端可不落但归档要继续就得落ls /home/db2inst1/sqllib/adm平台与位数决定库文件名决定库文件名getconf LONG_BIT、uname -pMaster Server 可达1556 端口通1556 端口通bpps -a表里最容易被跳过的是“平台与位数”这一行。DB2 调用的不是 NBU 的通用接口而是一个专门给 DB2 用的 Vendor I/O Library文件名随平台和位数变。列清楚这一行后面 db2_backup 和 restore 里的load参数才不会写错。# 确认实例清单别把源端的实例名和恢复端的实例名搞混 db2ilist # 确认 DB2 是 32 位还是 64 位直接决定库文件用 so 还是 so64 getconf LONG_BIT uname -p # 确认 NBU 客户端进程是否起来了 /usr/openv/netbackup/bin/bpps -a # 从目标主机反查 Master 是否可达端口按现场实际写 /usr/openv/netbackup/bin/bpclntcmd -pndb2ilist输出的是当前主机上所有实例异机恢复时目标实例名建议和源端保持一致因为db2 restore的库名是写在命令里的两边不一致就得额外处理实例目录映射。bpps看的是本机 NBU 客户端进程bpclntcmd -pn做的是客户端与 Master 的握手校验这条命令返回正常后面 bplist 才有意义。位数这条尤其要注意64 位系统上装了 32 位的 NBU 客户端库文件仍然是nbdb2.so照着别人 64 位的示例写nbdb2.so64restore 会直接报加载失败。提示源端与目标端的 NBU 客户端版本尽量保持一致跨大版本时先查一遍兼容矩阵别在图省事。2.2 装 NBU DB2 Agent 并把 db2uext2 落到实例目录DB2 Agent 装完之后NBU 需要把自带的用户出口程序db2uext2复制进 DB2 实例目录DB2 归档日志时才有东西可调。这一步是执行脚本不是手工拷贝文件因为脚本还会顺手把权限和属主设对。# 切到 DB2 实例用户别用 root 直接跑 su - db2inst1 # 执行 NBU 提供的 DB2 配置脚本把 db2uext2 投放到实例的 adm 目录 /usr/openv/netbackup/bin/db2_config # 确认出口程序已就位属主必须是实例用户 ls -l /home/db2inst1/sqllib/adm/db2uext2*db2_config干的事情就一件把 NBU 侧的db2uext2复制到db2instance/sqllib/adm并确保属主是实例用户。这一步用 root 跑也没关系但复制出来的文件属主必须是 db2inst1否则 DB2 在归档日志时调用不到这个程序表现出来就是日志一直堆在活动日志目录里NBU 那边的归档作业永远是空的。这一步做完之后Agent 还会在 NBU 侧生成备份用的脚本模板路径通常在/usr/openv/netbackup/ext/db_ext/db2/下面。别急着改模板先把数据库参数调好脚本里的变量和参数是配套的。提示如果sqllib/adm下已经有旧版本留下的 db2uext2先备份再覆盖不然回退时找不到原始文件。2.3 三个参数把库从循环日志切到归档日志DB2 默认是循环日志模式日志写满一圈就覆盖这种模式下 NBU 没有任何日志可归档只能做离线全备。要做在线备份、要能做时间点恢复就必须把库切成归档日志模式。原文给的是三个参数LOGRETAIN、USEREXIT、TRACKMOD这套写法在较新的 DB2 版本上已经被LOGARCHMETH1收编了但老环境里仍然是这三个开关。# 先确认当前有哪些应用连着参数改动必须在全部断连后才生效 db2 list applications for db bi show detail # 打开日志保留日志不再被循环覆盖 db2 update db cfg for bi using logretain on # 打开用户出口让 DB2 通过 db2uext2 把日志交给 NBU db2 update db cfg for bi using userexit on # 打开增量跟踪这是做增量备份的前置条件 db2 update db cfg for bi using trackmod yes # 参数改完库会进入 backup pending 状态必须做一次全备解除 db2 backup db bi to /db2backuplogretain on和userexit on是一对前者让日志不被覆盖后者告诉 DB2“归档这件事交给外部程序”也就是上一步落地的db2uext2。两个都打开之后数据库才算真正进入归档日志模式。trackmod yes是独立的一步它记录页面的修改状态增量备份靠它判断哪些页面变过不开这个参数db2 backup ... incremental会直接报错或者在老版本上悄悄退化成全备。这三个参数有一个共同的坑必须所有应用都断开连接之后修改才会生效。db2 list applications里只要还有一条连接update db cfg会执行成功但只在下次实例启动时才起作用你在当次会话里查参数看到的是新值实际运行还是老模式。改完参数做的那次全备也不能省——归档日志模式下没有一次完整备份打底库会处于 backup pending 状态连接直接失败。这次全备既是解除 pending 的动作也是后面增量备份链的起点。3. 备份侧落地db2.conf 与 db2_backup 脚本DB2 侧的参数是“允许数据库把日志交出去”NBU 侧的两个文件才是真正告诉 NBU“交给谁、备份到哪个策略、用哪个 Schedule”。这两个文件名字很像作用完全不同db2.conf是策略映射表db2_backup是实际被调起的备份脚本。前者写错作业根本不会启动后者写错作业起来了但备了个空库或者备了错的库。3.1 db2.conf数据库对象和归档日志对象是两段db2.conf里一个数据库要出现两次一次描述数据备份一次描述归档日志备份。两段的OBJECTTYPE不同指向的策略类型也不同。# /usr/openv/netbackup/db2.conf # 第一段数据库本身的备份策略类型必须是 DB2 DATABASE bi OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup ENDOPER # 第二段归档日志的备份策略类型必须是 StandardUNIX 环境 DATABASE bi OBJECTTYPE ARCHIVE POLICY DB2_Log SCHEDULE User_Backup ARCFUNC SAVE ENDOPER第一段的POLICY必须指向一个Policy type为 DB2 的策略SCHEDULE必须是这个策略下真实存在的 Schedule 名写错一个字母作业启动时就会报策略不存在。第二段的POLICY指向的是 Standard 类型策略因为归档日志在 NBU 眼里就是普通文件走的是文件备份通道ARCFUNC SAVE表示日志通过 NBU 存到存储单元如果换成ARCFUNC COPY日志会落到本地磁盘目录这时候才需要配ARCDIR和RETDIR两个路径。DATABASE这一行在实际备份时其实不是必选项NBU 主要靠脚本里指定的库名来定位但写上更直观尤其是同一个人管着十几个库的时候。注意第二段的OBJECTTYPE ARCHIVE只对开了userexit的库有意义参数没开的情况下这一段配了也不会被触发。3.2 db2_backup库文件、实例名、返回码三处必须改脚本模板是 Agent 安装时自动生成的直接拿来用之前至少有三处要按现场改库文件路径、实例用户、返回码处理。#!/bin/sh # NBU 备份脚本由 bphdb 在作业启动时调起 echo DB2_SERVER $DB2_SERVER echo DB2_POLICY $DB2_POLICY echo DB2_SCHED $DB2_SCHED echo DB2_FULL $DB2_FULL # 1 表示本次是全备 echo DB2_CINC $DB2_CINC # 1 表示本次是累积增量 echo DB2_INCR $DB2_INCR # 1 表示本次是差异增量 # 库文件按平台和位数选Linux 64 位就是 nbdb2.so64 MY_LIB/usr/openv/netbackup/bin/nbdb2.so64 # 实例用户必须对目标库有 SYSADM 或 SYSCTRL 权限 MY_USERdb2inst1 # 根据 Schedule 类型决定备份粒度 if [ $DB2_FULL 1 ] ; then MY_SCHED elif [ $DB2_CINC 1 ] ; then MY_SCHEDINCREMENTAL elif [ $DB2_INCR 1 ] ; then MY_SCHEDINCREMENTAL DELTA else MY_SCHED fi CMD_LINEdb2 BACKUP DATABASE bi ONLINE $MY_SCHED LOAD $MY_LIB echo Executing: $CMD_LINE su - $MY_USER -c $CMD_LINE RETURN_STATUS$? exit $RETURN_STATUSMY_LIB是 Vendor I/O Library 的绝对路径db2 backup通过LOAD关键字挂上这个库备份数据才会写进 NBU 的存储单元而不是本地磁盘。库文件名对应关系如下这一步写错是最常见的翻车点之一平台与位数库文件名完整路径Linux / Solaris 32 位nbdb2.so/usr/openv/netbackup/bin/nbdb2.soLinux / Solaris 64 位nbdb2.so64/usr/openv/netbackup/bin/nbdb2.so64AIX / HP-UX 32 位nbdb2.sl/usr/openv/netbackup/bin/nbdb2.slAIX / HP-UX 64 位nbdb2.sl64/usr/openv/netbackup/bin/nbdb2.sl64MY_USER后面的su -不能省NBU 调起脚本时是 root 身份DB2 的命令必须在实例用户下执行才有正确的环境变量。RETURN_STATUS是脚本的最后一行也是 NBU 判断这次作业成功还是失败的唯一依据如果把exit $RETURN_STATUS删了或者写成exit 0作业永远是绿的但库可能根本没备上。sleep分支那段值得单独说一句原文里DB2_INCR的判断分支是空的也就是说调度的是差异增量脚本却按全备去跑。这不算错但会让每天的备份量远超预期存储单元很快就被撑满。我把这个分支补成INCREMENTAL DELTA对应 DB2 的差异增量语法累积增量仍然是INCREMENTAL。3.3 NBU 策略与 Schedule变量名和类型对不上就白配脚本里的DB2_FULL、DB2_CINC、DB2_INCR三个变量不是脚本自己算出来的是 NBU 根据 Schedule 类型注入的环境变量。所以策略里的 Schedule 类型必须和脚本里的判断分支一一对上Schedule 类型注入变量脚本里 MY_SCHED 取值Automatic Full BackupDB2_FULL1空走全备Automatic Cumulative Incremental BackupDB2_CINC1INCREMENTALAutomatic Differential Incremental BackupDB2_INCR1INCREMENTAL DELTA建策略的顺序大致是登录管理控制台在 Policies 下新建策略Policy type选 DB2指定存储单元和卷池在 Clients 里把源主机加进去操作系统类型要和实际一致在 Backup Selections 里填 db2_backup 脚本的绝对路径不是填数据库名最后在 Schedules 里按上表建对应类型的计划配好备份周期和保留周期再设一个发起窗口。在线备份还有一条额外要求归档日志走的是 Standard 类型策略所以还得单独建一个 Standard 策略里面配一个User Backup类型的 Schedule。这个 Schedule 不需要配周期它是被 DB2 归档动作触发的配了周期反而会跟自动备份打架。提示策略建完先手动跑一次全备在 Activity Monitor 里看到作业成功并且有实际数据量再去配 Schedule顺序反了会很难定位问题。4. 异机恢复三件套altnames 开关、CLIENT_NAME、restore 与 rollforward备份侧跑通之后异机恢复只剩下三件事要确认Master 允不允许这台机器取走别人的备份、恢复端的 db2.conf 有没有指明备份来自哪台源主机、restore 和 rollforward 的参数怎么配。前两件是开关第三件才是命令。4.1 在 Master Server 上开异机恢复许可NBU 默认只允许客户端恢复自己产生的备份异机恢复要先在 Master Server 上放行否则 restore 一开始就会被打回来。# 在 Master Server 上以 root 执行 # 方式一放行所有客户端发起异机恢复演练环境用这个最省事 touch /usr/openv/netbackup/db/altnames/No.Restrictions chmod 644 /usr/openv/netbackup/db/altnames/No.Restrictions # 方式二只放行指定的源客户端文件名就是源客户端名生产环境建议用这个 touch /usr/openv/netbackup/db/altnames/db2src01 chmod 644 /usr/openv/netbackup/db/altnames/db2src01 # 改完确认文件存在且属主正确 ls -l /usr/openv/netbackup/db/altnames/No.Restrictions是一个空文件存在即生效内容不重要权限和属主才重要。这个目录下如果放了具体主机名的文件NBU 就只允许这些主机被异机恢复。演练环境图快用第一种生产环境我一般用第二种按源客户端逐个放行避免谁都能来取别人的备份。4.2 恢复端 db2.conf 必须补 CLIENT_NAME恢复端的db2.conf和备份端不是同一份最大的差别是每段OPER里要多一行CLIENT_NAME告诉 NBU“我要恢复的备份是这台源主机产生的”。少了这一行NBU 会去恢复端自己的备份里找自然什么都找不到。# 恢复端 /usr/openv/netbackup/db2.conf DATABASE bi OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup CLIENT_NAME db2src01 ENDOPER DATABASE bi OBJECTTYPE ARCHIVE POLICY DB2_Log SCHEDULE User_Backup CLIENT_NAME db2src01 ARCFUNC SAVE ENDOPER策略名和 Schedule 名必须和备份端完全一致因为它们指向的是 Master 上同一个策略对象。CLIENT_NAME填的是备份产生时的源客户端名不是恢复端的主机名这一行写反是所有异机恢复里最常见的错误报出来的错还往往很含糊只说找不到 image。注意恢复端的 POLICY 名如果和源端不一样要确认这个策略的 Clients 列表里包含源主机否则 NBU 依然认为这份备份不属于你指定的策略。4.3 OFFLINE 与 ONLINE 两条恢复路线恢复命令的差别来自备份是怎么做的。离线备份恢复时库是关闭的日志没有前进恢复完不需要 rollforward在线备份恢复完库处于 rollforward pending 状态必须再前滚一次才能打开。# 切到恢复端的实例用户 su - db2inst1 # 先确认能取到源主机的备份镜像时间戳后面要用 bplist -C db2src01 -t 18 -R -l / # 路线一离线备份恢复到最新版本 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.so64 \ without rolling forward without prompting # 目标实例上还没有这个库时用 to 指定新的库目录 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.so64 \ to /db2data without rolling forward without prompting # 路线一恢复到指定的某个备份版本时间戳来自 bplist 输出 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.so64 \ taken at 20250318093012 without rolling forward without promptingbplist的-t 18是 DB2 备份的固定类型号-R表示递归列出镜像里的对象。without rolling forward是离线备份恢复的关键参数不加这个参数DB2 会认为后面还有日志要前滚恢复完库一直卡在 pending 状态连不上。without prompting是免交互脚本里调起 restore 时要加不加会被提示符卡住直到超时。to参数只在目标实例上不存在同名库时使用路径要提前建好并属于实例用户。# 路线二在线备份恢复先 restore 再 rollforward db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.so64 db2 rollforward db bi to end of logs and complete # 路线二恢复到指定时间点 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.so64 \ taken at 20250318093012 db2 rollforward db bi to 2025-03-18-09:30:12 using local time and complete在线恢复的第一条 restore 不能加without rolling forward因为后面要靠 rollforward 把日志追平。to end of logs表示把能取到的归档日志全部追完to 时间点则是追到指定时刻。using local time这个选项不是所有版本都有没有这个选项的老版本上如果操作系统时间和标准时间有偏差写进去的时间要先把差值减掉否则 rollforward 会告诉你目标时间点超出了日志范围。5. 避坑与排查五个在恢复现场最容易翻车的点这一章按我实际踩过的顺序写每条都是“现象、原因、解决”三段。异机恢复的报错大多不指向根因照着错误码去搜往往搜不到按这五条挨个排一遍命中率比乱试高得多。5.1 restore 一开始就报 not authorized现象命令刚从实例用户敲下去立刻返回权限相关错误连备份镜像都没开始读bplist 也同样取不到数据。原因Master Server 上没有放行异机恢复。/usr/openv/netbackup/db/altnames/目录下既没有No.Restrictions也没有以源客户端命名的放行文件。解决在 Master 上以 root 建放行文件生产环境建议按源客户端名逐个建演练环境用No.Restrictions。建完不用重启服务直接重试 restore。5.2 找不到镜像db2.conf 少了 CLIENT_NAME现象restore 能启动但很快报找不到 image或者 bplist 在恢复端查不到任何东西而同样的 bplist 命令在源主机上跑是正常的。原因恢复端的db2.conf里没有写CLIENT_NAMENBU 默认按恢复端自己的主机名去找备份自然找不到。解决在恢复端db2.conf的两段OPER里都补上CLIENT_NAME 源客户端名两段都要补只补数据备份那段的话rollforward 阶段会因为找不到归档日志再次失败。5.3 参数改了不生效应用连接没断干净现象db2 update db cfg显示执行成功db2 get db cfg也能看到新值但归档日志就是不产生NBU 的归档作业一直是空跑。原因改参数时还有应用连接着数据库参数只在下次实例启动才真正生效当前实例仍在用旧的日志模式。解决先用db2 list applications for db 库名 show detail把所有连接列出来逐个断开或者force application再重新执行一遍update db cfg然后做一次完整备份解除 pending 状态。5.4 SQL1031N库文件名和平台位数对不上现象restore 或 backup 执行到一半报 SQL1031N提示找不到数据库目录或者无法加载指定的库。原因LOAD后面跟的 Vendor I/O Library 文件名和实际平台位数不匹配例如 64 位系统上写了nbdb2.so或者 AIX 上写了.so后缀。解决按 3.2 节的对照表重新确认文件名getconf LONG_BIT看位数uname -p看处理器改完再跑。同一台机器上如果同时装了 32 位和 64 位客户端以实际被 DB2 进程加载的那个为准。5.5 恢复完连不上OFFLINE 备份忘了 without rolling forward现象restore 显示成功但db2 connect to bi报数据库处于 rollforward pending 状态无法连接。原因离线备份恢复时没有加without rolling forwardDB2 认为还有日志要前滚把库挂在 pending 状态等 rollforward。解决重新执行一次 restore 并带上without rolling forward如果不想重跑也可以直接执行db2 rollforward db bi to end of logs and complete把状态清掉但离线备份后面没有日志可追这个动作只是为了让库能打开语义上不如重跑 restore 干净。6. 装完怎么验证做一次带时间点的异机恢复演练配置类的活跑通一次不等于配对了。下面这套验证动作是我每次异机恢复上线前必走的顺序不能乱每一步的返回值都有意义。第一步在恢复端用 bplist 列出源主机的镜像确认能取到数据同时记下最新的时间戳# 列出源主机上 DB2 类型的所有备份镜像输出里的时间戳后面要用 bplist -C db2src01 -t 18 -R -l /第二步按 4.3 节的在线路线做一次恢复到指定时间点的操作时间点选在最近一次业务低峰之后。恢复完成后立刻检查库状态db2 list rollforward pending应该返回空db2 connect to bi应该能连上。第三步比对数据。这一步别只看库能不能连要挑两三张有代表性的表做行数和时间字段的核对确认恢复到的确实是目标时间点而不是某个更早的全备。核对完执行db2 terminate断开。第四步检查归档日志有没有继续上传。恢复端如果后续还要承担备份职责db2 get db cfg for bi里的logretain和userexit必须是 on然后在 NBU 侧手动触发一次 User Backup确认归档作业有实际数据量说明db2uext2和db2.conf在新的主机上一样工作。验证项期望结果失败时先看哪bplist 取镜像能列出源主机镜像和时间戳altnames 放行文件、CLIENT_NAMErestore 执行返回成功且无 SQL 错误库文件名、目标路径权限库可连接connect 成功无 pending是否漏了 rollforward数据核对行数与时间字段符合目标时间点恢复用的时间戳是否取自正确镜像归档继续归档作业有数据量userexit 参数、db2uext2 是否落地有一年我在一套测试环境上省掉了第一步的 bplist直接照文档敲 restore结果taken at后面跟的时间戳是从生产环境的记录里抄来的两个环境的备份时间点差了三天恢复出来的库看起来一切正常业务方验了半天才发现数据少了一截。从那以后我每次做 DB2 异机恢复都强制先跑一遍 bplist把时间戳原样复制到 restore 命令里再往下走一步。希望这套顺序能帮你少走一遍我踩过的路。本文还有配套的精品资源点击获取
实践)
