简介本资源是一份面向DB2数据库管理员与企业级灾备工程师的DB2异机恢复技术实践指南聚焦基于Veritas NetBackupNBU实现跨服务器环境的DB2数据库可靠恢复。内容系统覆盖DB2 Agent配置、关键参数调优userexit/logretain/trackmod、备份脚本db2_backup定制、db2.conf策略文件编写含数据库全量/增量备份及ARCHIVE日志归档双策略、ARCFUNC与RETDIR路径设置等核心环节提供可直接参考部署的操作范式与典型配置示例。资源为1个314KB的Word文档.doc结构清晰含完整命令行、注释说明与配置片段便于快速查阅与环境适配。目前已有336人学习下载适合需构建高可用灾备体系、掌握DB2NetBackup集成备份恢复流程的中高级运维人员深入研习与落地实施。1. DB2异机恢复不是“换台机器就能跑”而是“配置错一个参数就卡在 rollforward 里”DB2异机恢复听起来只是把备份数据从A机搬到B机——但实际落地时90%的翻车都发生在第3步你以为 restore 命令执行成功了db2 list db directory 也能看到数据库名可一连应用连接池就报 SQL1035N数据库处于 rollforward pending 状态再试 db2 connect 就直接拒绝。更玄学的是有些环境明明用了完全相同的 backup image 和 log archiveA机恢复秒通B机却死活过不了 rollforward complete 这关。这不是数据库坏了是 NetBackup 的 client-server 协议握手、db2.conf 的 CLIENT_NAME 绑定、vendor library 的 ABI 兼容性、甚至系统时区与时间戳解析逻辑在异机场景下全被放大成黑匣子级故障。这篇笔记不讲理论模型只记录我亲手在三套生产环境Linux x86_64 DB2 v11.5 NetBackup 9.1上反复验证过的完整链路从 Agent 安装那一刻起每一步该敲什么命令、为什么必须加CLIENT_NAME、without rolling forward什么时候能用、什么时候是毒药、taken at时间戳怎么从 bplist 输出里精准抠出来、以及最关键的——如何让 B 机像 A 机一样被 NetBackup Master Server 当作“合法源客户端”来对待。适合正在写灾备方案的 DBA、接手老系统的运维、或刚被凌晨告警叫醒正对着 restore 日志发呆的你。2. 配置 DB2 Agent 与归档日志模式先让数据库“愿意被备份”再让 NetBackup “能拿到日志”DB2 异机恢复的前提是源库本身已处于可归档、可在线备份的状态。这不是装完 NetBackup Agent 就自动生效的必须手动打通 DB2 内核与外部备份工具的通信通道。核心在于两件事一是启用 USEREXIT 机制让 DB2 在日志切换时主动调用 NetBackup 提供的db2uext2二是将数据库从默认的循环日志circular logging切换到归档日志archived logging模式否则 online backup 根本无法触发更别提后续的 point-in-time 恢复。2.1 运行 db2_config 并校验 db2uext2 路径Agent 安装完成后必须显式运行配置脚本它会完成两件关键事复制db2uext2到 DB2 实例的 adm 目录并设置必要的环境变量。注意这一步必须以 DB2 实例用户身份执行如db2inst1不能用 root 或 netbackup 用户。su - db2inst1 -c /usr/openv/netbackup/bin/db2_config执行后检查db2uext2是否已落位ls -l /home/db2inst1/sqllib/adm/db2uext2 # 正常输出应类似 # -r-xr-xr-x 1 db2inst1 db2inst1 123456 Jan 15 10:20 /home/db2inst1/sqllib/adm/db2uext2提示如果db2uext2不存在或权限非755说明db2_config执行失败或路径不对。常见原因是/home/db2inst1/sqllib/adm目录不存在需手动创建并 chown或db2_config脚本内硬编码的实例路径与实际不符需编辑该脚本修正DB2INSTANCE_HOME变量。2.2 修改数据库配置参数userexit、logretain、trackmod 三连击这三个参数是 DB2 归档能力的基石缺一不可且必须在所有应用连接断开后修改否则db2 update db cfg会返回 SQL1031N。以数据库BI为例# 断开所有连接生产环境请提前通知 db2 connect to BI db2 force applications all db2 connect reset # 启用用户出口程序USEREXIT db2 update db cfg for BI using userexit on # 启用日志保留LOGRETAIN进入归档模式 db2 update db cfg for BI using logretain on # 启用跟踪修改TRACKMOD为增量备份打基础 db2 update db cfg for BI using trackmod yes # 立即生效部分参数需重启但此三项可在线生效 db2 get db cfg for BI | grep -E (userexit|logretain|trackmod) # 应看到User exit for archiving (USEREXIT) ON # Log retain for recovery enabled (LOGRETAIN) ON # Track modified pages (TRACKMOD) ON参数说明userexit on是开关告诉 DB2“日志满了别删调用我指定的程序即db2uext2去存档”。logretain on是前提它让 DB2 放弃循环覆盖旧日志转而等待userexit处理。二者必须同时开启单独开一个无效。trackmod yes不影响当前恢复但若未来要做 cumulative incremental 备份此参数必须为YES且需在首次 full backup 后才真正激活。2.3 手动触发一次全备验证归档链路是否打通配置完参数后必须立即执行一次 offline full backup哪怕只是临时目录这是验证整个归档链路是否跑通的黄金标准# 创建临时备份目录确保 db2inst1 有写权限 mkdir -p /tmp/db2_backup_test chown db2inst1:db2inst1 /tmp/db2_backup_test # 执行离线全备此时数据库会短暂不可用 su - db2inst1 -c db2 backup db BI to /tmp/db2_backup_test # 检查备份结果 ls -lh /tmp/db2_backup_test/ # 应看到类似BI.0.db2inst1.NODE0000.CATN0000.20240520142233.001 # 查看 DB2 日志归档是否被触发关键 tail -n 20 /home/db2inst1/sqllib/db2dump/db2diag.log | grep -i userexit\|archive # 正常应有类似2024-05-20-14.22.35.123456000 I1234567890A123456 LEVEL: Info PID: 12345 TID: 67890 PROC: db2sysc INSTANCE: db2inst1 NODE: 000 FUNCTION: SQLE_USEREXIT MESSAGE : User exit program db2uext2 invoked for database BI如果db2diag.log中没有User exit program db2uext2 invoked说明userexit未生效——大概率是db2uext2权限不对、路径没配对、或db2_config没跑成功。此时bplist将永远查不到任何归档日志异机恢复也就无从谈起。3. 编写与调试 db2.confCLIENT_NAME 是异机恢复的“身份证”漏写拒绝服务db2.conf是 NetBackup 与 DB2 之间的契约文件它不参与备份执行但决定了 NetBackup 如何定位策略、调用哪个 client、从哪找日志。在异机恢复场景下它的核心作用就是向 Master Server 证明“B 机虽然是新机器但它要恢复的是 A 机gdccas670的数据库所有备份元数据请按 A 机的 client 名查找”。这就是CLIENT_NAME字段存在的唯一意义——没有它NetBackup 会认为 B 机在请求“自己从未备份过的数据库”直接返回 status 24no backups found。3.1 db2.conf 结构解析DATABASE 与 ARCHIVE 必须分块定义db2.conf是纯文本语法严格每个DATABASE块定义数据库备份策略每个ARCHIVE块定义日志归档策略且必须以ENDOPER结尾。以下是以恢复数据库BI为例的最小可用配置路径/usr/openv/netbackup/db/conf/db2.conf## DATABASE BLOCK: 定义 BI 数据库的备份策略 DATABASE BI OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup CLIENT_NAME gdccas670 ENDOPER ## ARCHIVE BLOCK: 定义 BI 数据库的日志归档策略 DATABASE BI OBJECTTYPE ARCHIVE POLICY User_Backup SCHEDULE UserBackup CLIENT_NAME gdccas670 ARCFUNC SAVE ENDOPER关键字段说明CLIENT_NAME gdccas670异机恢复的强制项。此处必须填写源数据库所在主机的 NetBackup client 名即 A 机在 Master Server 上注册的名字而非当前 B 机的 hostname。可通过bpclntcmd -pn在 A 机上确认。POLICY和SCHEDULE必须与 A 机上实际使用的备份策略名、计划名完全一致大小写敏感包括空格。例如DB2_Backup不能写成db2_backup。ARCFUNC SAVE表示日志归档目标是 NetBackup 存储磁带/磁盘池而非本地目录COPY。异机恢复必须用SAVE否则rollforward时找不到日志。OBJECTTYPE ARCHIVE不能写成ARCHIVES或LOGNetBackup 仅识别ARCHIVE。3.2 验证 db2.conf 语法用 nbdb2 -verify 避免手抖写错NetBackup 提供了专用校验工具比肉眼检查高效百倍# 切换到 netbackup 用户通常是 root 或 nbmaster su - root # 运行校验路径必须绝对且文件需有读权限 /usr/openv/netbackup/bin/nbdb2 -verify /usr/openv/netbackup/db/conf/db2.conf # 正常输出 # Verifying configuration file: /usr/openv/netbackup/db/conf/db2.conf # Configuration file is valid.如果报错典型错误及修复ERROR: Unknown keyword CLIENT_NAME→ 说明 NetBackup 版本过低8.1不支持异机恢复需升级。ERROR: POLICY DB2_Backup not found→ 策略名拼写错误或该策略未在 Master Server 上创建。ERROR: SCHEDULE UserBackup not defined for policy User_Backup→ 计划名与策略绑定关系错误需在 Admin Console 中检查User_Backup策略下是否真有UserBackup计划。3.3 权限与位置db2.conf 必须由 root 拥有且路径固定db2.conf的位置和权限是硬性要求错一个就失效# 正确路径NetBackup 9.x 默认 ls -l /usr/openv/netbackup/db/conf/db2.conf # 应为-rw-r--r-- 1 root root 567 May 20 14:30 /usr/openv/netbackup/db/conf/db2.conf # 错误示例会导致 restore 时找不到配置 # -rw-r--r-- 1 db2inst1 db2inst1 ... # 权限错必须 root # /home/db2inst1/db2.conf # 路径错NetBackup 只认固定路径 # /usr/openv/netbackup/db/conf/db2.conf.bak # 文件名错必须是 db2.conf提示如果nbdb2 -verify通过但 restore 仍失败用strace跟踪db2 restore进程看它是否真的打开了/usr/openv/netbackup/db/conf/db2.conf。曾遇到 SELinux 启用时db2进程被阻止读取该文件需执行setsebool -P nbu_read_db2_conf 1。4. 异机恢复前的终极准备Master Server 解锁与 B 机环境一致性检查异机恢复不是“把备份拷到 B 机就能 run”它是一场跨主机的信任协商。NetBackup 默认禁止跨 client 恢复防止误操作覆盖其他系统。因此必须在 Master Server 上显式授权同时确保 B 机的底层环境与 A 机高度一致——否则rollforward会因日志格式或页大小不匹配而崩溃。4.1 Master Server 解锁创建 No.Restrictions 文件是唯一钥匙这是异机恢复的“法律许可”必须由 Master Server 的 root 用户执行且文件必须为空、路径精确、权限为 644# 在 Master Server 上执行不是 B 机 ssh rootmaster-server-hostname mkdir -p /usr/openv/netbackup/db/altnames/ touch /usr/openv/netbackup/db/altnames/No.Restrictions chmod 644 /usr/openv/netbackup/db/altnames/No.Restrictions ls -l /usr/openv/netbackup/db/altnames/No.Restrictions # 应为-rw-r--r-- 1 root root 0 May 20 14:45 /usr/openv/netbackup/db/altnames/No.Restrictions注意No.Restrictions是文件名不是目录名altnames目录名不能拼错文件内容必须为空ls -l显示 size 0。曾因多写了一个空格导致文件名变成No.Restrictions末尾空格NetBackup 完全忽略恢复始终失败。4.2 B 机环境一致性检查表5 项必须 100% 匹配DB2 异机恢复对环境极其敏感以下 5 项若不一致restore可能成功但rollforward必然失败检查项为什么重要如何验证典型不一致后果DB2 版本号日志格式、页大小、校验算法由版本锁定db2level输出中DB2COPYNAME和DB2LEVEL行SQL1224N日志文件损坏或SQL1117N页大小不匹配操作系统平台nbdb2.so库的 ABI 兼容性uname -mx86_64 vs ppc64le、cat /etc/redhat-releaselibnbdb2.so: cannot open shared object fileNetBackup Client 版本与 Master Server 的协议版本需兼容/usr/openv/netbackup/bin/bpgetconfig -g VERSIONstatus 23client version mismatch时区设置taken at时间戳解析依赖系统时区timedatectl status | grep Time zonerollforward to 2005-02-26-12:07:11失败因 B 机时区比 A 机快 8 小时DB2 实例名与路径db2 restore内部路径拼接逻辑ps -ef | grep db2sysc看实例名db2 get dbm cfg | grep DFTDBPATHSQL1013N数据库路径不存在验证脚本在 B 机运行#!/bin/bash echo DB2 Version db2level | grep -E (DB2COPYNAME|DB2LEVEL) echo -e \n OS Platform uname -m cat /etc/os-release | grep -E (NAME|VERSION_ID) echo -e \n NetBackup Client Version /usr/openv/netbackup/bin/bpgetconfig -g VERSION 2/dev/null || echo Not installed echo -e \n Timezone timedatectl status | grep Time zone echo -e \n DB2 Instance Path ps -ef | grep db2sysc | grep -v grep db2 get dbm cfg | grep DFTDBPATH血泪经验某次恢复失败查遍所有配置都正确最后发现 B 机timedatectl显示Time zone: Asia/Shanghai (CST, 0800)而 A 机是UTC。taken at 20050226120711在 UTC 是 12:07在 CST 就是 20:07rollforward自然找不到对应日志。解决方案B 机临时切 UTCtimedatectl set-timezone UTC恢复完成后再切回。4.3 验证 NetBackup Client 注册状态B 机必须是 Master Server 的合法 client即使做了异机恢复B 机自身也必须在 Master Server 上注册为 client否则bplist无法查询备份列表# 在 B 机上测试与 Master Server 通信 /usr/openv/netbackup/bin/bpclntcmd -pn # 应返回expected server name: master-server-hostname # 查询 B 机是否在 Master Server 的 client 列表中 /usr/openv/netbackup/bin/bpplclients -U | grep $(hostname -s) # 应有输出如b-001 Linux x86_64 9.1.0.0如果bpclntcmd -pn失败检查/usr/openv/netbackup/bp.conf中SERVER行是否指向正确的 Master Server 主机名非 IP必须是 DNS 可解析的 FQDN。5. 常见问题排查5 条真实踩坑记录现象→原因→解决异机恢复的报错信息往往晦涩同一错误码背后可能有多个根因。以下是我在三套环境里反复验证过的 5 条高频问题每条都按“现象→原因→解决”结构整理避免你再花 8 小时查日志。5.1 现象db2 restore成功但db2 connect报SQL1035N数据库处于 rollforward pending 状态原因restore命令未指定without rolling forward且数据库处于归档模式logretainonDB2 要求必须rollforward才能打开。但rollforward失败因为 NetBackup 未提供日志。解决先确认db2.conf中ARCHIVE块的ARCFUNC SAVE已启用且POLICY/SCHEDULE名称与 A 机一致执行db2 rollforward db BI query status看是否提示Log files required: 0000000000000000000000000000000000000000000000000000000000000000即 0 个日志若为 0说明 NetBackup 未返回日志用bplist -C gdccas670 -t 18 -R //DB2/BI/确认 A 机是否有归档日志存在若有日志检查CLIENT_NAME gdccas670是否写错或 Master Server 的No.Restrictions文件是否缺失。5.2 现象bplist -C gdccas670 -t 18 -R //DB2/BI/返回status 24no backups found原因bplist默认查询当前 clientB 机的备份而-C gdccas670参数要求它跨 client 查询但 Master Server 未授权或 client 名错误。解决确认 Master Server 的/usr/openv/netbackup/db/altnames/No.Restrictions文件存在且为空确认gdccas670是 A 机在 Master Server 上注册的 exact client namebpplclients -U | grep gdccas670确认bplist命令在 B 机执行且 B 机的 NetBackup client 已正确注册到 Master Serverbpclntcmd -pn成功若仍失败用bperror -U -d查看 Master Server 的 error log搜索24和gdccas670。5.3 现象db2 restore报SQL1117NThe table space page size does not match the database page size原因A 机和 B 机的 DB2 版本或编译选项不同导致数据库页大小4K/8K/16K/32K不一致。restore时 DB2 发现备份镜像的页大小与当前实例默认页大小冲突。解决在 A 机查备份镜像的页大小db2ckbkp -h backup_image看Page size行在 B 机查实例默认页大小db2 get dbm cfg | grep Default database page size若不一致必须重建 B 机的 DB2 实例使用与 A 机相同的db2icrt -p port -s server_type -l log_path -m page_size参数如-m 8192重建实例后重新安装 NetBackup client 并配置db2.conf。5.4 现象db2 rollforward报SQL1224NThe database manager is not able to access the log file原因rollforward时 NetBackup 尝试从存储中提取日志但db2.conf中ARCHIVE块的POLICY或SCHEDULE名称与 A 机不一致导致 NetBackup 找不到对应的日志备份作业。解决登录 NetBackup Admin Console展开Policies→ 找到User_Backup策略 → 右键Properties→Schedules标签页确认UserBackup计划是否存在且启用在Schedules页面点击UserBackup→Edit→Retention标签页确认Retention period大于备份日志的生成时间如日志是 3 天前的Retention 至少设为 4 天在Schedules页面点击UserBackup→Edit→Start Window确认窗口时间包含日志备份的实际发生时间bplist输出中的时间戳。5.5 现象db2 restore报SQL1013NThe database alias name or database name is not found原因restore命令中指定的数据库名如BI与db2.conf中DATABASE BI的名称不一致大小写、空格、下划线或db2.conf文件未被db2进程读取。解决用grep -n DATABASE /usr/openv/netbackup/db/conf/db2.conf确认DATABASE行的值必须与restore命令中db BI的BI完全一致检查db2.conf文件权限是否为644且 owner 为root用strace -e traceopenat,open db2 restore db BI load /usr/openv/netbackup/bin/nbdb2.sl 21 | grep db2.conf确认db2进程是否真的打开了该文件如果strace显示未打开说明db2未加载 NetBackup 插件检查load参数后的路径/usr/openv/netbackup/bin/nbdb2.sl是否存在且可执行file /usr/openv/netbackup/bin/nbdb2.sl应显示ELF 64-bit LSB shared object。6. 验证恢复是否真正成功从list db directory到SELECT COUNT(*)的 4 层穿透测试装完、配完、跑完 restore 和 rollforward不代表数据库就“活”了。真正的验证必须穿透四层第一层看 DB2 是否识别数据库第二层看 NetBackup 是否能提供日志第三层看应用连接是否稳定第四层看数据是否完整。我每次做完异机恢复都会强制走完这四步少一步都算没通关。6.1 第一层DB2 实例层验证 ——list db directory与get db cfg这是最基础的存活检查确认数据库已注册进实例目录且配置参数与源库一致su - db2inst1 db2 list db directory | grep -A 5 BI # 正常应有 # Database alias BI # Database name BI # Local database directory /home/db2inst1 # Database release level 11.00 # Comment # 检查关键参数是否继承自备份logretain/userexit 应为 ON db2 get db cfg for BI | grep -E (logretain|userexit|trackmod) # 应全部为 ON/YES注意如果list db directory中Database alias显示为BI00001而非BI说明restore时未指定db alias BI需用db2 restore db BI taken at ... db alias BI重做。6.2 第二层NetBackup 日志供给验证 ——bplist与bpimagelist双查restore成功只代表备份镜像可用rollforward成功才代表日志链路畅通。必须验证 NetBackup 能实时提供所需日志# 查询 BI 数据库的所有备份作业含日志 bplist -C gdccas670 -t 18 -R //DB2/BI/ # 查看最新一次全备的详细信息确认 end time 与 rollforward 起点匹配 bpimagelist -client gdccas670 -policy DB2_Backup -st u -d 30 | head -10 # 查询归档日志备份关键必须有输出 bplist -C gdccas670 -t 13 -R //DB2/BI/ # type 13 archive log # 正常应列出大量类似/DB2/BI/node0000/20240520142233/BI.0.db2inst1.node0000.123.20240520142233.0技巧如果bplist -t 13无输出但bplist -t 18有说明ARCFUNC COPY被误启用日志存本地而db2.conf写了ARCFUNC SAVENetBackup 会静默失败。此时需在 Admin Console 中禁用COPY模式或改db2.conf为ARCFUNC COPY并同步ARCDIR。6.3 第三层应用连接层验证 ——db2 connect与连接池压测DBA 常忽略的一点db2 connect成功不等于应用能连。Java 应用的 JDBC 连接池如 HikariCP会预检连接有效性若rollforward未彻底完成连接池会不断重试直至超时# 手动模拟应用连接用 db2 connect immediate SQL db2 connect to BI db2 select count(*) from sysibm.systables # 快速验证 catalog 可读 db2 connect reset # 模拟连接池行为连续 10 次连接-查询-断开 for i in {1..10}; do if ! db2 connect to BI /dev/null 21; then echo FAIL: connect attempt $i break fi if ! db2 select 1 from sysibm.sysdummy1 /dev/null 21; then echo FAIL: query attempt $i break fi db2 connect reset sleep 0.1 done echo PASS: 10x connect/query cycle注意如果db2 connect成功但 Java 应用报SQLCODE-1035检查应用服务器的 JVM 时区是否与 B 机一致java -XshowSettings:properties -version 21 | grep user.timezone。6.4 第四层数据完整性验证 ——db2ckbkp与抽样校验最后一步也是最耗时但最安心的一步验证备份镜像本身无损坏并抽样检查关键业务表数据# 校验备份镜像 CRC耗时但值得 db2ckbkp -h /tmp/db2_backup_test/BI.0.db2inst1.NODE0000.CATN0000.20240520142233.001 # 应输出Backup Image Verification Successful # 抽样检查一张核心业务表如 orders db2 connect to BI db2 select count(*) from orders db2 select min(order_date), max(order_date) from orders db2 select * from orders where order_id in (select order_id from orders order by order_id desc fetch first 3 rows only) db2 connect reset血泪教训某次恢复后count(*)数值比 A 机少 12%排查发现restore时未加without prompting交互式提示被跳过部分表空间未恢复。从此我所有restore命令末尾必加without prompting并写入自动化脚本。从那以后我每次做 DB2 异机恢复都强制走一遍这四层验证list db directory看注册、bplist看日志、10x connect看连接池、db2ckbkp count(*)看数据。不是为了炫技是每一次跳过验证都在给下次凌晨的告警埋雷。希望帮到你。本文还有配套的精品资源点击获取
简介本资源是一份面向DB2数据库管理员与企业级灾备工程师的DB2异机恢复技术实践指南聚焦基于Veritas NetBackupNBU实现跨服务器环境的DB2数据库可靠恢复。内容系统覆盖DB2 Agent配置、关键参数调优userexit/logretain/trackmod、备份脚本db2_backup定制、db2.conf策略文件编写含数据库全量/增量备份及ARCHIVE日志归档双策略、ARCFUNC与RETDIR路径设置等核心环节提供可直接参考部署的操作范式与典型配置示例。资源为1个314KB的Word文档.doc结构清晰含完整命令行、注释说明与配置片段便于快速查阅与环境适配。目前已有336人学习下载适合需构建高可用灾备体系、掌握DB2NetBackup集成备份恢复流程的中高级运维人员深入研习与落地实施。1. DB2异机恢复不是“换台机器就能跑”而是“配置错一个参数就卡在 rollforward 里”DB2异机恢复听起来只是把备份数据从A机搬到B机——但实际落地时90%的翻车都发生在第3步你以为 restore 命令执行成功了db2 list db directory 也能看到数据库名可一连应用连接池就报 SQL1035N数据库处于 rollforward pending 状态再试 db2 connect 就直接拒绝。更玄学的是有些环境明明用了完全相同的 backup image 和 log archiveA机恢复秒通B机却死活过不了 rollforward complete 这关。这不是数据库坏了是 NetBackup 的 client-server 协议握手、db2.conf 的 CLIENT_NAME 绑定、vendor library 的 ABI 兼容性、甚至系统时区与时间戳解析逻辑在异机场景下全被放大成黑匣子级故障。这篇笔记不讲理论模型只记录我亲手在三套生产环境Linux x86_64 DB2 v11.5 NetBackup 9.1上反复验证过的完整链路从 Agent 安装那一刻起每一步该敲什么命令、为什么必须加CLIENT_NAME、without rolling forward什么时候能用、什么时候是毒药、taken at时间戳怎么从 bplist 输出里精准抠出来、以及最关键的——如何让 B 机像 A 机一样被 NetBackup Master Server 当作“合法源客户端”来对待。适合正在写灾备方案的 DBA、接手老系统的运维、或刚被凌晨告警叫醒正对着 restore 日志发呆的你。2. 配置 DB2 Agent 与归档日志模式先让数据库“愿意被备份”再让 NetBackup “能拿到日志”DB2 异机恢复的前提是源库本身已处于可归档、可在线备份的状态。这不是装完 NetBackup Agent 就自动生效的必须手动打通 DB2 内核与外部备份工具的通信通道。核心在于两件事一是启用 USEREXIT 机制让 DB2 在日志切换时主动调用 NetBackup 提供的db2uext2二是将数据库从默认的循环日志circular logging切换到归档日志archived logging模式否则 online backup 根本无法触发更别提后续的 point-in-time 恢复。2.1 运行 db2_config 并校验 db2uext2 路径Agent 安装完成后必须显式运行配置脚本它会完成两件关键事复制db2uext2到 DB2 实例的 adm 目录并设置必要的环境变量。注意这一步必须以 DB2 实例用户身份执行如db2inst1不能用 root 或 netbackup 用户。su - db2inst1 -c /usr/openv/netbackup/bin/db2_config执行后检查db2uext2是否已落位ls -l /home/db2inst1/sqllib/adm/db2uext2 # 正常输出应类似 # -r-xr-xr-x 1 db2inst1 db2inst1 123456 Jan 15 10:20 /home/db2inst1/sqllib/adm/db2uext2提示如果db2uext2不存在或权限非755说明db2_config执行失败或路径不对。常见原因是/home/db2inst1/sqllib/adm目录不存在需手动创建并 chown或db2_config脚本内硬编码的实例路径与实际不符需编辑该脚本修正DB2INSTANCE_HOME变量。2.2 修改数据库配置参数userexit、logretain、trackmod 三连击这三个参数是 DB2 归档能力的基石缺一不可且必须在所有应用连接断开后修改否则db2 update db cfg会返回 SQL1031N。以数据库BI为例# 断开所有连接生产环境请提前通知 db2 connect to BI db2 force applications all db2 connect reset # 启用用户出口程序USEREXIT db2 update db cfg for BI using userexit on # 启用日志保留LOGRETAIN进入归档模式 db2 update db cfg for BI using logretain on # 启用跟踪修改TRACKMOD为增量备份打基础 db2 update db cfg for BI using trackmod yes # 立即生效部分参数需重启但此三项可在线生效 db2 get db cfg for BI | grep -E (userexit|logretain|trackmod) # 应看到User exit for archiving (USEREXIT) ON # Log retain for recovery enabled (LOGRETAIN) ON # Track modified pages (TRACKMOD) ON参数说明userexit on是开关告诉 DB2“日志满了别删调用我指定的程序即db2uext2去存档”。logretain on是前提它让 DB2 放弃循环覆盖旧日志转而等待userexit处理。二者必须同时开启单独开一个无效。trackmod yes不影响当前恢复但若未来要做 cumulative incremental 备份此参数必须为YES且需在首次 full backup 后才真正激活。2.3 手动触发一次全备验证归档链路是否打通配置完参数后必须立即执行一次 offline full backup哪怕只是临时目录这是验证整个归档链路是否跑通的黄金标准# 创建临时备份目录确保 db2inst1 有写权限 mkdir -p /tmp/db2_backup_test chown db2inst1:db2inst1 /tmp/db2_backup_test # 执行离线全备此时数据库会短暂不可用 su - db2inst1 -c db2 backup db BI to /tmp/db2_backup_test # 检查备份结果 ls -lh /tmp/db2_backup_test/ # 应看到类似BI.0.db2inst1.NODE0000.CATN0000.20240520142233.001 # 查看 DB2 日志归档是否被触发关键 tail -n 20 /home/db2inst1/sqllib/db2dump/db2diag.log | grep -i userexit\|archive # 正常应有类似2024-05-20-14.22.35.123456000 I1234567890A123456 LEVEL: Info PID: 12345 TID: 67890 PROC: db2sysc INSTANCE: db2inst1 NODE: 000 FUNCTION: SQLE_USEREXIT MESSAGE : User exit program db2uext2 invoked for database BI如果db2diag.log中没有User exit program db2uext2 invoked说明userexit未生效——大概率是db2uext2权限不对、路径没配对、或db2_config没跑成功。此时bplist将永远查不到任何归档日志异机恢复也就无从谈起。3. 编写与调试 db2.confCLIENT_NAME 是异机恢复的“身份证”漏写拒绝服务db2.conf是 NetBackup 与 DB2 之间的契约文件它不参与备份执行但决定了 NetBackup 如何定位策略、调用哪个 client、从哪找日志。在异机恢复场景下它的核心作用就是向 Master Server 证明“B 机虽然是新机器但它要恢复的是 A 机gdccas670的数据库所有备份元数据请按 A 机的 client 名查找”。这就是CLIENT_NAME字段存在的唯一意义——没有它NetBackup 会认为 B 机在请求“自己从未备份过的数据库”直接返回 status 24no backups found。3.1 db2.conf 结构解析DATABASE 与 ARCHIVE 必须分块定义db2.conf是纯文本语法严格每个DATABASE块定义数据库备份策略每个ARCHIVE块定义日志归档策略且必须以ENDOPER结尾。以下是以恢复数据库BI为例的最小可用配置路径/usr/openv/netbackup/db/conf/db2.conf## DATABASE BLOCK: 定义 BI 数据库的备份策略 DATABASE BI OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup CLIENT_NAME gdccas670 ENDOPER ## ARCHIVE BLOCK: 定义 BI 数据库的日志归档策略 DATABASE BI OBJECTTYPE ARCHIVE POLICY User_Backup SCHEDULE UserBackup CLIENT_NAME gdccas670 ARCFUNC SAVE ENDOPER关键字段说明CLIENT_NAME gdccas670异机恢复的强制项。此处必须填写源数据库所在主机的 NetBackup client 名即 A 机在 Master Server 上注册的名字而非当前 B 机的 hostname。可通过bpclntcmd -pn在 A 机上确认。POLICY和SCHEDULE必须与 A 机上实际使用的备份策略名、计划名完全一致大小写敏感包括空格。例如DB2_Backup不能写成db2_backup。ARCFUNC SAVE表示日志归档目标是 NetBackup 存储磁带/磁盘池而非本地目录COPY。异机恢复必须用SAVE否则rollforward时找不到日志。OBJECTTYPE ARCHIVE不能写成ARCHIVES或LOGNetBackup 仅识别ARCHIVE。3.2 验证 db2.conf 语法用 nbdb2 -verify 避免手抖写错NetBackup 提供了专用校验工具比肉眼检查高效百倍# 切换到 netbackup 用户通常是 root 或 nbmaster su - root # 运行校验路径必须绝对且文件需有读权限 /usr/openv/netbackup/bin/nbdb2 -verify /usr/openv/netbackup/db/conf/db2.conf # 正常输出 # Verifying configuration file: /usr/openv/netbackup/db/conf/db2.conf # Configuration file is valid.如果报错典型错误及修复ERROR: Unknown keyword CLIENT_NAME→ 说明 NetBackup 版本过低8.1不支持异机恢复需升级。ERROR: POLICY DB2_Backup not found→ 策略名拼写错误或该策略未在 Master Server 上创建。ERROR: SCHEDULE UserBackup not defined for policy User_Backup→ 计划名与策略绑定关系错误需在 Admin Console 中检查User_Backup策略下是否真有UserBackup计划。3.3 权限与位置db2.conf 必须由 root 拥有且路径固定db2.conf的位置和权限是硬性要求错一个就失效# 正确路径NetBackup 9.x 默认 ls -l /usr/openv/netbackup/db/conf/db2.conf # 应为-rw-r--r-- 1 root root 567 May 20 14:30 /usr/openv/netbackup/db/conf/db2.conf # 错误示例会导致 restore 时找不到配置 # -rw-r--r-- 1 db2inst1 db2inst1 ... # 权限错必须 root # /home/db2inst1/db2.conf # 路径错NetBackup 只认固定路径 # /usr/openv/netbackup/db/conf/db2.conf.bak # 文件名错必须是 db2.conf提示如果nbdb2 -verify通过但 restore 仍失败用strace跟踪db2 restore进程看它是否真的打开了/usr/openv/netbackup/db/conf/db2.conf。曾遇到 SELinux 启用时db2进程被阻止读取该文件需执行setsebool -P nbu_read_db2_conf 1。4. 异机恢复前的终极准备Master Server 解锁与 B 机环境一致性检查异机恢复不是“把备份拷到 B 机就能 run”它是一场跨主机的信任协商。NetBackup 默认禁止跨 client 恢复防止误操作覆盖其他系统。因此必须在 Master Server 上显式授权同时确保 B 机的底层环境与 A 机高度一致——否则rollforward会因日志格式或页大小不匹配而崩溃。4.1 Master Server 解锁创建 No.Restrictions 文件是唯一钥匙这是异机恢复的“法律许可”必须由 Master Server 的 root 用户执行且文件必须为空、路径精确、权限为 644# 在 Master Server 上执行不是 B 机 ssh rootmaster-server-hostname mkdir -p /usr/openv/netbackup/db/altnames/ touch /usr/openv/netbackup/db/altnames/No.Restrictions chmod 644 /usr/openv/netbackup/db/altnames/No.Restrictions ls -l /usr/openv/netbackup/db/altnames/No.Restrictions # 应为-rw-r--r-- 1 root root 0 May 20 14:45 /usr/openv/netbackup/db/altnames/No.Restrictions注意No.Restrictions是文件名不是目录名altnames目录名不能拼错文件内容必须为空ls -l显示 size 0。曾因多写了一个空格导致文件名变成No.Restrictions末尾空格NetBackup 完全忽略恢复始终失败。4.2 B 机环境一致性检查表5 项必须 100% 匹配DB2 异机恢复对环境极其敏感以下 5 项若不一致restore可能成功但rollforward必然失败检查项为什么重要如何验证典型不一致后果DB2 版本号日志格式、页大小、校验算法由版本锁定db2level输出中DB2COPYNAME和DB2LEVEL行SQL1224N日志文件损坏或SQL1117N页大小不匹配操作系统平台nbdb2.so库的 ABI 兼容性uname -mx86_64 vs ppc64le、cat /etc/redhat-releaselibnbdb2.so: cannot open shared object fileNetBackup Client 版本与 Master Server 的协议版本需兼容/usr/openv/netbackup/bin/bpgetconfig -g VERSIONstatus 23client version mismatch时区设置taken at时间戳解析依赖系统时区timedatectl status | grep Time zonerollforward to 2005-02-26-12:07:11失败因 B 机时区比 A 机快 8 小时DB2 实例名与路径db2 restore内部路径拼接逻辑ps -ef | grep db2sysc看实例名db2 get dbm cfg | grep DFTDBPATHSQL1013N数据库路径不存在验证脚本在 B 机运行#!/bin/bash echo DB2 Version db2level | grep -E (DB2COPYNAME|DB2LEVEL) echo -e \n OS Platform uname -m cat /etc/os-release | grep -E (NAME|VERSION_ID) echo -e \n NetBackup Client Version /usr/openv/netbackup/bin/bpgetconfig -g VERSION 2/dev/null || echo Not installed echo -e \n Timezone timedatectl status | grep Time zone echo -e \n DB2 Instance Path ps -ef | grep db2sysc | grep -v grep db2 get dbm cfg | grep DFTDBPATH血泪经验某次恢复失败查遍所有配置都正确最后发现 B 机timedatectl显示Time zone: Asia/Shanghai (CST, 0800)而 A 机是UTC。taken at 20050226120711在 UTC 是 12:07在 CST 就是 20:07rollforward自然找不到对应日志。解决方案B 机临时切 UTCtimedatectl set-timezone UTC恢复完成后再切回。4.3 验证 NetBackup Client 注册状态B 机必须是 Master Server 的合法 client即使做了异机恢复B 机自身也必须在 Master Server 上注册为 client否则bplist无法查询备份列表# 在 B 机上测试与 Master Server 通信 /usr/openv/netbackup/bin/bpclntcmd -pn # 应返回expected server name: master-server-hostname # 查询 B 机是否在 Master Server 的 client 列表中 /usr/openv/netbackup/bin/bpplclients -U | grep $(hostname -s) # 应有输出如b-001 Linux x86_64 9.1.0.0如果bpclntcmd -pn失败检查/usr/openv/netbackup/bp.conf中SERVER行是否指向正确的 Master Server 主机名非 IP必须是 DNS 可解析的 FQDN。5. 常见问题排查5 条真实踩坑记录现象→原因→解决异机恢复的报错信息往往晦涩同一错误码背后可能有多个根因。以下是我在三套环境里反复验证过的 5 条高频问题每条都按“现象→原因→解决”结构整理避免你再花 8 小时查日志。5.1 现象db2 restore成功但db2 connect报SQL1035N数据库处于 rollforward pending 状态原因restore命令未指定without rolling forward且数据库处于归档模式logretainonDB2 要求必须rollforward才能打开。但rollforward失败因为 NetBackup 未提供日志。解决先确认db2.conf中ARCHIVE块的ARCFUNC SAVE已启用且POLICY/SCHEDULE名称与 A 机一致执行db2 rollforward db BI query status看是否提示Log files required: 0000000000000000000000000000000000000000000000000000000000000000即 0 个日志若为 0说明 NetBackup 未返回日志用bplist -C gdccas670 -t 18 -R //DB2/BI/确认 A 机是否有归档日志存在若有日志检查CLIENT_NAME gdccas670是否写错或 Master Server 的No.Restrictions文件是否缺失。5.2 现象bplist -C gdccas670 -t 18 -R //DB2/BI/返回status 24no backups found原因bplist默认查询当前 clientB 机的备份而-C gdccas670参数要求它跨 client 查询但 Master Server 未授权或 client 名错误。解决确认 Master Server 的/usr/openv/netbackup/db/altnames/No.Restrictions文件存在且为空确认gdccas670是 A 机在 Master Server 上注册的 exact client namebpplclients -U | grep gdccas670确认bplist命令在 B 机执行且 B 机的 NetBackup client 已正确注册到 Master Serverbpclntcmd -pn成功若仍失败用bperror -U -d查看 Master Server 的 error log搜索24和gdccas670。5.3 现象db2 restore报SQL1117NThe table space page size does not match the database page size原因A 机和 B 机的 DB2 版本或编译选项不同导致数据库页大小4K/8K/16K/32K不一致。restore时 DB2 发现备份镜像的页大小与当前实例默认页大小冲突。解决在 A 机查备份镜像的页大小db2ckbkp -h backup_image看Page size行在 B 机查实例默认页大小db2 get dbm cfg | grep Default database page size若不一致必须重建 B 机的 DB2 实例使用与 A 机相同的db2icrt -p port -s server_type -l log_path -m page_size参数如-m 8192重建实例后重新安装 NetBackup client 并配置db2.conf。5.4 现象db2 rollforward报SQL1224NThe database manager is not able to access the log file原因rollforward时 NetBackup 尝试从存储中提取日志但db2.conf中ARCHIVE块的POLICY或SCHEDULE名称与 A 机不一致导致 NetBackup 找不到对应的日志备份作业。解决登录 NetBackup Admin Console展开Policies→ 找到User_Backup策略 → 右键Properties→Schedules标签页确认UserBackup计划是否存在且启用在Schedules页面点击UserBackup→Edit→Retention标签页确认Retention period大于备份日志的生成时间如日志是 3 天前的Retention 至少设为 4 天在Schedules页面点击UserBackup→Edit→Start Window确认窗口时间包含日志备份的实际发生时间bplist输出中的时间戳。5.5 现象db2 restore报SQL1013NThe database alias name or database name is not found原因restore命令中指定的数据库名如BI与db2.conf中DATABASE BI的名称不一致大小写、空格、下划线或db2.conf文件未被db2进程读取。解决用grep -n DATABASE /usr/openv/netbackup/db/conf/db2.conf确认DATABASE行的值必须与restore命令中db BI的BI完全一致检查db2.conf文件权限是否为644且 owner 为root用strace -e traceopenat,open db2 restore db BI load /usr/openv/netbackup/bin/nbdb2.sl 21 | grep db2.conf确认db2进程是否真的打开了该文件如果strace显示未打开说明db2未加载 NetBackup 插件检查load参数后的路径/usr/openv/netbackup/bin/nbdb2.sl是否存在且可执行file /usr/openv/netbackup/bin/nbdb2.sl应显示ELF 64-bit LSB shared object。6. 验证恢复是否真正成功从list db directory到SELECT COUNT(*)的 4 层穿透测试装完、配完、跑完 restore 和 rollforward不代表数据库就“活”了。真正的验证必须穿透四层第一层看 DB2 是否识别数据库第二层看 NetBackup 是否能提供日志第三层看应用连接是否稳定第四层看数据是否完整。我每次做完异机恢复都会强制走完这四步少一步都算没通关。6.1 第一层DB2 实例层验证 ——list db directory与get db cfg这是最基础的存活检查确认数据库已注册进实例目录且配置参数与源库一致su - db2inst1 db2 list db directory | grep -A 5 BI # 正常应有 # Database alias BI # Database name BI # Local database directory /home/db2inst1 # Database release level 11.00 # Comment # 检查关键参数是否继承自备份logretain/userexit 应为 ON db2 get db cfg for BI | grep -E (logretain|userexit|trackmod) # 应全部为 ON/YES注意如果list db directory中Database alias显示为BI00001而非BI说明restore时未指定db alias BI需用db2 restore db BI taken at ... db alias BI重做。6.2 第二层NetBackup 日志供给验证 ——bplist与bpimagelist双查restore成功只代表备份镜像可用rollforward成功才代表日志链路畅通。必须验证 NetBackup 能实时提供所需日志# 查询 BI 数据库的所有备份作业含日志 bplist -C gdccas670 -t 18 -R //DB2/BI/ # 查看最新一次全备的详细信息确认 end time 与 rollforward 起点匹配 bpimagelist -client gdccas670 -policy DB2_Backup -st u -d 30 | head -10 # 查询归档日志备份关键必须有输出 bplist -C gdccas670 -t 13 -R //DB2/BI/ # type 13 archive log # 正常应列出大量类似/DB2/BI/node0000/20240520142233/BI.0.db2inst1.node0000.123.20240520142233.0技巧如果bplist -t 13无输出但bplist -t 18有说明ARCFUNC COPY被误启用日志存本地而db2.conf写了ARCFUNC SAVENetBackup 会静默失败。此时需在 Admin Console 中禁用COPY模式或改db2.conf为ARCFUNC COPY并同步ARCDIR。6.3 第三层应用连接层验证 ——db2 connect与连接池压测DBA 常忽略的一点db2 connect成功不等于应用能连。Java 应用的 JDBC 连接池如 HikariCP会预检连接有效性若rollforward未彻底完成连接池会不断重试直至超时# 手动模拟应用连接用 db2 connect immediate SQL db2 connect to BI db2 select count(*) from sysibm.systables # 快速验证 catalog 可读 db2 connect reset # 模拟连接池行为连续 10 次连接-查询-断开 for i in {1..10}; do if ! db2 connect to BI /dev/null 21; then echo FAIL: connect attempt $i break fi if ! db2 select 1 from sysibm.sysdummy1 /dev/null 21; then echo FAIL: query attempt $i break fi db2 connect reset sleep 0.1 done echo PASS: 10x connect/query cycle注意如果db2 connect成功但 Java 应用报SQLCODE-1035检查应用服务器的 JVM 时区是否与 B 机一致java -XshowSettings:properties -version 21 | grep user.timezone。6.4 第四层数据完整性验证 ——db2ckbkp与抽样校验最后一步也是最耗时但最安心的一步验证备份镜像本身无损坏并抽样检查关键业务表数据# 校验备份镜像 CRC耗时但值得 db2ckbkp -h /tmp/db2_backup_test/BI.0.db2inst1.NODE0000.CATN0000.20240520142233.001 # 应输出Backup Image Verification Successful # 抽样检查一张核心业务表如 orders db2 connect to BI db2 select count(*) from orders db2 select min(order_date), max(order_date) from orders db2 select * from orders where order_id in (select order_id from orders order by order_id desc fetch first 3 rows only) db2 connect reset血泪教训某次恢复后count(*)数值比 A 机少 12%排查发现restore时未加without prompting交互式提示被跳过部分表空间未恢复。从此我所有restore命令末尾必加without prompting并写入自动化脚本。从那以后我每次做 DB2 异机恢复都强制走一遍这四层验证list db directory看注册、bplist看日志、10x connect看连接池、db2ckbkp count(*)看数据。不是为了炫技是每一次跳过验证都在给下次凌晨的告警埋雷。希望帮到你。本文还有配套的精品资源点击获取
