简介：这份文档面向使用 NetBackup 实现 DB2 数据库异机恢复的运维与 DBA 人员，聚焦备份代理配置、参数调整与恢复策略落地，适合具备一定 DB2 与 NBU 基础、需要搭建异机恢复环境的中高级技术人员参考。资源包内共 1 个 doc 文件，压缩包约 314KB，内容围绕 DB2 Agent 配置、db2.conf 与 db2_backup 脚本展开，涵盖 userexit、logretain、trackmod 等关键参数设置，以及归档日志备份的 ARCFUNC、RETDIR 配置方法。文档还给出备份策略与计划命名示例，如 DATABASE、OBJECTTYPE、POLICY、SCHEDULE 等字段的填写方式，便于读者对照搭建完整备份链路。目前已有 335 人学习下载，可作为异机恢复场景下的配置速查与脚本参考，帮助快速定位参数遗漏与策略配置问题。
1. 异机恢复不是把备份拷过去那么简单
生产库所在的那台机器磁盘告警，运维群里一句“先别动，等确认”，结果确认完机器已经起不来了。这时候你手里只有 NetBackup 里一份昨天的 DB2 全备，目标机器是另一台刚装好同版本 DB2 的空机——这就是 DB2 异机恢复最典型的场景。它要解决的不是“备份能不能读出来”，而是“换一台机器、换一个实例名、甚至换一个目录，怎么让数据库完整站起来”。适合已经用 NBU 做 DB2 备份、需要做容灾演练或真实故障切换的 DBA，也适合第一次接手异机恢复、被CLIENT_NAME和No.Restrictions卡住的工程师。下面按“配置—备份—恢复—排错”的顺序拆一遍，参数和命令都能直接抄。
2. DB2 Agent 配置与归档日志模式：异机恢复的前置条件
异机恢复能不能成，八成取决于备份端当初有没有配对。很多人恢复时报no backup images found，回头查才发现备份时根本没开归档日志，或者db2.conf里没写CLIENT_NAME。这一章把备份端该做的配置一次讲透，因为恢复端的所有命令都建立在这些配置之上。
2.1 Agent 安装后的 db2_config 与用户出口程序
DB2 的 Agent 装完之后，第一件事不是急着建策略，而是跑db2_config。这个脚本干的事很具体：把 NBU 提供的用户出口程序db2uext2复制到 DB2 实例的sqllib/adm目录下。DB2 在归档日志时就是靠这个出口程序把日志交给 NBU 的，少了它，日志归档直接失败，后面恢复时rollforward会卡在找不到日志。
# 以 root 或具备权限的账号执行，脚本会交互式询问 DB2 实例信息 /usr/openv/netbackup/bin/db2_config # 执行完成后确认出口程序已就位 ls -l <db2instance>/sqllib/adm/db2uext2逻辑说明：db2_config是 NBU 自带的配置工具，不是 DB2 命令。它会把db2uext2放到实例的adm目录，DB2 通过userexit参数调用它。参数说明：<db2instance>换成实际实例的家目录，比如/db2inst1。如果这步漏了，后面db2 update db cfg里userexit on设了也没用，日志归档会报出口程序不存在。
2.2 三个必须打开的 DB2 配置参数
DB2 默认是循环日志模式，这种模式下日志会被覆盖，根本没法做在线备份，更别提异机恢复到某个时间点。要转成归档日志模式，必须改三个参数。注意：改这些参数前，所有应用必须断开与数据库的连接，否则命令会挂起或报错。
# 切换到 DB2 实例用户 su - db2inst1 # 启用用户出口程序，让 DB2 把归档日志交给 NBU 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 backup database sample to /tmp逻辑说明：userexit on和logretain on一起把数据库从循环日志切到归档日志模式，这是在线备份和异机恢复的基础。trackmod yes是增量备份的开关，异机恢复如果只恢复到全备，这个参数不影响，但生产上通常配合增量策略。参数说明：sample换成实际数据库名；to /tmp是本地临时路径，正式备份走 NBU 策略时不写这个路径。最后那次全备份不能省，DB2 在参数变更后要求有一次全备才允许连接，这是很多人改完参数发现连不上库的原因。
2.3 db2.conf 与备份脚本的关键变量
NBU 的 DB2 备份靠两个文件驱动：db2.conf定义策略映射，db2_backup是实际执行的脚本。db2.conf里最容易漏的是CLIENT_NAME，异机恢复时没有它，NBU 不知道去哪个客户端的备份里找数据。
# db2.conf 片段：数据库备份部分 DATABASE DWDB OBJECTTYPE DATABASE POLICY s80a_DB2_everyday_to_tape SCHEDULE Default-Application-Backup CLIENT_NAME gdccas670 # 异机恢复必须指定源客户端名 ENDOPER # db2.conf 片段：归档日志备份部分 DATABASE DWDB OBJECTTYPE ARCHIVE POLICY DB2_log SCHEDULE user_backup CLIENT_NAME gdccas670 # 同样要指定源客户端 ARCFUNC SAVE ENDOPER逻辑说明：OBJECTTYPE DATABASE段管数据库备份，OBJECTTYPE ARCHIVE段管归档日志备份，两者策略类型不同——数据库备份用 DB2 类型策略，日志备份用 Standard 类型策略。参数说明：POLICY和SCHEDULE必须与 NBU 控制台上建好的策略名、计划名完全一致，大小写敏感；CLIENT_NAME是异机恢复的核心，指向备份数据所属的源客户端；ARCFUNC SAVE表示日志归档到 NBU 存储，如果改成COPY则归档到本地目录，异机恢复时用SAVE更稳。
备份脚本db2_backup里要改的变量不多，但每个都关键：
#!/bin/sh # 指定 NBU 的 DB2 库文件，Linux 32 位用 nbdb2.so，64 位用 nbdb2.so64 MY_LIB=/usr/openv/netbackup/bin/nbdb2.so64 # 指定要备份的数据库 MY_DB2=DWDB # 指定执行备份的 DB2 用户 MY_USER=db2inst1 # 根据 NBU 传入的调度类型决定全备还是增量 if [ "$DB2_FULL" = "1" ] ; then MY_SCHED="" elif [ "$DB2_CINC" = "1" ] ; then MY_SCHED="INCREMENTAL" elif [ "$DB2_INCR" = "1" ] ; then MY_SCHED="INCREMENTAL DELTA" else MY_SCHED="" fi # 拼出备份命令，LOAD 后面跟库文件路径 CMD_LINE="db2 BACKUP DATABASE $MY_DB2 ONLINE $MY_SCHED LOAD $MY_LIB" echo "Executing: $CMD_LINE" su - $MY_USER -c "$CMD_LINE" exit $?逻辑说明：脚本由 NBU 的bphdb进程调用，环境变量DB2_FULL、DB2_CINC、DB2_INCR由 NBU 根据调度类型注入，脚本据此决定备份模式。参数说明：MY_LIB必须匹配操作系统位数，选错会报库加载失败；MY_DB2和MY_USER按实际环境改；ONLINE表示在线备份，需要归档日志模式已开启。多个数据库要备份时，就复制CMD_LINE那几行，改成不同的库名和用户，依次执行。
3. 异机恢复的完整操作链：从 No.Restrictions 到 rollforward
备份端配好了，恢复端才是真正见真章的地方。异机恢复和同机恢复最大的区别在于权限和客户端指向：NBU 默认只允许恢复到备份的源客户端，换机器必须显式放开；db2.conf里必须写CLIENT_NAME告诉 NBU 去源客户端找数据。这一章按顺序走一遍。
3.1 在 Master Server 上放开异机恢复限制
NBU 出于安全考虑，默认禁止把备份恢复到非源客户端。异机恢复第一步就是在 Master Server 上创建一个空文件，这个文件的存在本身就是授权。
# 在 Master Server 上以 root 执行 touch /usr/openv/netbackup/db/altnames/No.Restrictions # 确认文件存在且为空 ls -l /usr/openv/netbackup/db/altnames/No.Restrictions逻辑说明：altnames目录下的文件是 NBU 的异机恢复授权机制，No.Restrictions表示不限制目标客户端。参数说明：这个文件必须建在 Master Server 上，不是目标恢复机器；文件内容为空即可，不需要写任何东西。如果企业安全策略不允许全放开，也可以建以客户端名命名的文件来精确授权，但实操中No.Restrictions最省事。
3.2 恢复端的 db2.conf 配置
恢复端的db2.conf和备份端结构一样，但CLIENT_NAME在这里的作用是“去哪个客户端找备份”，必须指向源客户端。同时策略名和调度名要和备份时一致。
# 恢复端 db2.conf DATABASE BI OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup CLIENT_NAME gdccas670 # 源客户端名，异机恢复的关键 ENDOPER DATABASE BI OBJECTTYPE ARCHIVE POLICY User_Backup SCHEDULE UserBackup CLIENT_NAME gdccas670 # 日志备份同样指向源客户端 ARCFUNC SAVE ENDOPER逻辑说明：恢复端不需要重新建策略，直接复用备份端的策略定义，NBU 会根据CLIENT_NAME去源客户端的备份记录里检索镜像。参数说明：DATABASE写要恢复成的数据库名，可以和源库不同名；POLICY和SCHEDULE必须与备份端完全一致；CLIENT_NAME写源客户端的主机名，不是恢复端自己的名字。
3.3 OFFLINE 备份的异机恢复命令
如果备份是 OFFLINE 模式（备份时数据库未启动），恢复相对简单，因为不需要前滚日志。核心命令是db2 restore ... load ...，通过load指定 NBU 的库文件，让 DB2 从 NBU 读取备份镜像。
su - db2inst1 # 恢复到最新备份，目标库不存在时加 to 参数指定新路径 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.so64 \ to /db2data/bi \ without rolling forward without prompting逻辑说明：load后面跟 NBU 的 DB2 库文件路径，DB2 通过它调用 NBU 的接口读取备份。without rolling forward表示不做前滚，OFFLINE 备份不需要日志。without prompting避免交互式确认，适合脚本化。参数说明：db bi中bi是目标数据库名；to /db2data/bi在目标库不存在或要换目录时使用，路径要提前建好并属于实例用户；库文件路径按实际位数选nbdb2.so或nbdb2.so64。
如果要恢复到某个特定备份版本，先用bplist列出可用镜像，找到精确时间戳，再用taken at指定。
# 列出源客户端上 DB2 类型的备份镜像，-t 18 是 DB2 策略类型编号 bplist -C gdccas670 -t 18 -R / # 输出中会看到类似 /DB2/BI/node0000/20050226120711/ 的路径 # 其中 20050226120711 就是备份时间戳 # 按时间戳恢复 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.so64 \ taken at 20050226120711 \ to /db2data/bi \ without rolling forward without prompting逻辑说明：bplist是 NBU 的镜像查询命令，-C指定源客户端，-t 18是 DB2 策略类型，-R /递归列出。输出路径里的时间戳就是taken at要用的值。参数说明：时间戳格式为YYYYMMDDHHMMSS，必须从bplist输出里精确复制，不能凭记忆写。
3.4 ONLINE 备份的异机恢复与 rollforward
ONLINE 备份恢复后数据库处于前滚挂起状态，必须执行rollforward才能打开。这是异机恢复里最容易出问题的一步，日志找不到、时间点写错都会卡住。
su - db2inst1 # 第一步：恢复数据库备份 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.so64 \ to /db2data/bi # 第二步：前滚到日志末尾并完成 db2 rollforward db bi to end of logs and complete逻辑说明：ONLINE 备份的restore命令不能加without rolling forward，否则数据库无法进入前滚状态。恢复完成后必须rollforward，DB2 会通过userexit调用 NBU 出口程序去取归档日志。参数说明：to end of logs and complete表示前滚到所有可用日志的末尾并结束前滚，数据库变为可用状态。
如果要恢复到指定时间点，把to end of logs换成具体时间：
# 恢复到 2005-02-26 12:07:11 db2 rollforward db bi to 2005-02-26-12:07:11 using local time and complete逻辑说明：using local time表示按操作系统本地时间解释时间点。参数说明：部分 DB2 版本没有using local time选项，如果操作系统时间与标准时间有偏差，指定的时间要减去这个偏差值，否则会前滚过头或不够。这是血泪经验，时间点恢复前先确认系统时间同步状态。
4. 异机恢复避坑：五条翻车记录
异机恢复的坑大多不在命令本身，而在环境差异和配置遗漏。下面五条是实操中反复出现的，每条按现象、原因、解决写清楚。
4.1 报 no backup images found
现象：db2 restore执行后立刻报找不到备份镜像，但备份明明成功过。
原因：db2.conf里没写CLIENT_NAME，NBU 默认去恢复端本机找备份，而备份在源客户端上。
解决：在恢复端db2.conf的 DATABASE 和 ARCHIVE 两段都加上CLIENT_NAME <源客户端名>，然后重新执行恢复命令。
4.2 报 cannot connect to database
现象：改完userexit、logretain参数后，应用连不上数据库。
原因：DB2 在参数变更后要求有一次全备份，否则数据库处于备份挂起状态，拒绝连接。
解决：立即执行一次全备份db2 backup database <库名> to /tmp，备份完成后数据库恢复正常连接。
4.3 rollforward 卡住报日志不存在
现象：rollforward执行到一半报某个日志文件找不到，前滚无法完成。
原因：归档日志备份策略没配好，或者db2.conf里 ARCHIVE 段的CLIENT_NAME漏了，NBU 取不到日志。
解决：检查 ARCHIVE 段配置，确认POLICY是 Standard 类型、SCHEDULE是 User Backup 类型、CLIENT_NAME已指定；用bplist -C <源客户端> -t 0 -R /确认日志备份镜像存在。
4.4 异机恢复被拒绝
现象：恢复命令报权限错误，提示不允许恢复到该客户端。
原因：Master Server 上没有创建No.Restrictions文件，NBU 默认禁止异机恢复。
解决：在 Master Server 上以 root 执行touch /usr/openv/netbackup/db/altnames/No.Restrictions，然后重试。
4.5 库文件加载失败
现象：db2 restore报无法加载nbdb2.so或nbdb2.so64。
原因：库文件位数与操作系统或 DB2 实例不匹配，或者路径写错。
解决：确认操作系统位数，32 位用nbdb2.so，64 位用nbdb2.so64；确认路径/usr/openv/netbackup/bin/下文件存在；AIX 或 HPUX 上扩展名是.sl和.sl64，不要照搬 Linux 的.so。
5. 验证恢复结果与一个提速技巧
恢复命令跑完不代表结束，数据库能不能打开、数据对不对才是终点。我一般按三步验证：先db2 connect to bi确认能连上，再db2 list tablespaces show detail看表空间状态是否正常，最后抽查几张核心表的数据量。ONLINE 恢复的库如果rollforward没执行完，连接会直接报错，所以能连上基本说明前滚完成了。
有个提速技巧值得单独说：异机恢复时如果目标机器和源机器同版本同平台，可以先把 NBU 的 DB2 库文件路径加到LD_LIBRARY_PATH里，避免每次写全路径。但更关键的是db2.conf里ARCFUNC的选择——SAVE走 NBU 存储，COPY走本地目录。异机恢复场景下我强烈建议用SAVE，因为COPY模式下日志在源机器本地磁盘，源机器挂了日志就没了，异机恢复直接断链。这个参数在备份策略设计阶段就要定好，事后改不回来。
# 验证恢复结果的三条命令 db2 connect to bi db2 list tablespaces show detail db2 "select count(*) from <核心表名>"逻辑说明：connect验证数据库可用性，list tablespaces检查表空间是否处于正常状态（异常会显示0x4000之类的状态码），select count抽查数据完整性。参数说明：<核心表名>换成业务上最关键的表，数据量对不上说明恢复不完整或时间点不对。
还有一个容易忽略的点：恢复完成后，目标库的userexit、logretain、trackmod参数会继承备份时的设置。如果目标机器要作为新的生产库，这些参数不用改；如果只是临时恢复做数据抽取，记得恢复完把userexit关掉，否则日志会继续往 NBU 归档，白白占存储。
从那以后我每次做异机恢复，都强制先跑一遍bplist确认镜像可见，再检查No.Restrictions和CLIENT_NAME两个点，最后才敲restore。这三步花不了两分钟，但能省掉大半的翻车时间。希望帮到你。
本文还有配套的精品资源，点击获取
