NetWorker:对 NetWorker 中的磁带库加载问题进行故障处理
摘要: 本文旨在帮助支持者和管理员解决库或应用程序级别的库加载问题。确定问题是逻辑问题还是物理问题,以及问题是机器人、驱动器还是介质磁带盒问题。
本文适用于
本文不适用于
本文并非针对某种特定的产品。
本文并非包含所有产品版本。
症状
- 在磁带库中加载盒式磁带时出现零星或持续错误
- 无法从库介质执行备份或恢复
- 库可检测、确认功能正常且就绪
- 无法执行负载或标记操作
- 胶带被标记为“未标记”
- 系统或应用程序日志中可能出现 ASC/ASCQ/SCSI SENSE 错误或消息
- 执行特定或随机库操作时出现零星或一致错误
原因
如果库配置以前正常工作,并且突然遇到问题,请考虑可能妨碍检测和配置的更改:
- 机器人、交换机或适配器固件、驱动程序或配置更改
- 添加、更换或卸下驱动器、盒式磁带或其他磁带库组件
- 更改 NetWorker 软件版本、操作系统修补程序
- 任何硬件事件,例如数据路径中的任何组件断电或重新启动
- NetWorker 配置和库之间的差异(例如,磁带盒移动到 NetWorker 控制之外)
如果库从未正常工作过,请在 NetWorker 硬件兼容性指南 中确认硬件受支持(需要登录戴尔支持帐户)。请记住,库可以部分正常工作;仅发现并不能保证可用性或可支持性。
解决方案
为了解决库加载问题,在考虑了上次已知的更改之后,通过将进程下放到其基元成分并单独测试它们来排除故障。
收集所需的数据 NSRGet 当使用 -o:d 开关。NetWorker:如何使用 NSRGet NetWorker 数据收集工具(英文版)
不属于 的项目仅限于那些如果手动尝试可能会被视为危险的操作。
警告:其中一些命令可能会导致 SCSI 重置,进而导致磁带设备倒带。如果主机可访问任何活动磁带,请勿使用。
Library Load:通信
- 同样,请确保库响应迅速且准备就绪,然后再继续。否则:
Library Load:物理操作
- 检查以确保库操作在基本级别上实际可行。确保在磁带库未处于活动状态时完成测试,并将盒式磁带替换到其原始位置。
首先确定盒式磁带位移:
sjirdtag <changer address>
然后在各元素之间移动盒式磁带,然后再将盒式磁带移回:
sjimm <changer address> <drive|slot|inlt|mt> <element_number> <drive|slot|inlt|mt> <element_number>
- 在某些情况下,可能会出现错误;例如,未在磁带库级别启用自动弹出功能的磁带库在尝试从磁带机移动到任何其他元素时出错(必须通过
mt -f <device_handle> offline命令)。 - 如果在尝试机器人操作时偶尔或持续返回错误,SCSI ASC/ASQ代码错误,请考虑上报给库供应商进行审查。
Library Load:逻辑运算
一旦我们确定物理操作没有错误(至少从表面上看是这样),我们就可以尝试在 NetWorker 中跟踪问题。
- 确定磁带库的布局并确保其准备就绪,将 NSR 自动存储塔状态信息与机器人的磁带盒信息进行比较:
nsrjb [<-j library_name>] -C sjirdtag <changer address>
- 尝试以高详细级别将受影响的磁带加载到受影响的驱动器中:
nsrjb [<-j library_name>] -lvvvvv -f <device_handle> -S <slot_number>
如果库重复加载而没有出现问题,则加载问题可能是由特定情景因素导致的,而不是持久故障。应尽一切努力隔离导致负载故障的条件,并应遵循调试条件(见下文)。
- 如果常规加载操作失败,特别是当卷标记为“未标记”时,则标签读取在加载尝试期间失败(导致 装载 失败)。尝试以高详细级别将同一磁带重新加载到同一驱动器中,而不安装:
nsrjb [<-j library_name>] -lnvvvvv -f <device_handle> -S <slot_number>
- 执行独立标签验证,以测试标签读取失败是暂时的还是一致的:
nsrmm -pvvvvv -f <device_handle>
- 如果标签读取成功,则问题可能会解决为在物理加载磁带设备后准备好之前进行的标签读取尝试。在这种情况下,您可以尝试在系统环境或启动脚本中设置变量:
MAX_LOAD_RETRIES=10
如果在设置变量后,在复合加载/装载(标签读取)操作期间加载操作仍然失败,请转至调试部分。
Library Load:调试
如果所有其他方法均失败,请在咨询主题专家 (SME) 之前收集相应的数据以帮助调试问题:
- 在 NetWorker 中重现问题之前,请在 NSR 自动存储塔资源中将 调试跟踪级别 更改为 5
- 也要使用
dbgcommand为了提高运行调试级别nsrd和nsrmmgd处理至 5dbgcommand -n PROCESS_NAME Debug=5- 要禁用:
dbgcommand -n PROCESS_NAME Debug=0 - NetWorker:调试信息级别
- 考虑
truss/tusc/strace开始,pstack开始,gcore/gencore在适当的nsrlcpd在问题事件发生之前和期间 - 在系统环境 (Windows) 或启动脚本 (UNIX) 中设置调试变量,以获得更丰富的调试数据:
SJI_DEBUG=9 LUS_DEBUG=9 CDI_DEBUG=9 SCSI_DEBUG=9 JBDEBUG=9
警告: 除非在启动后快速重现问题,否则调试日志记录可能会过多。服务关闭,以便从运行中删除环境变量。
如果上述建议均无济于事,请根据解决 NetWorker 中的磁带库检测问题和解决 NetWorker 中的磁带库访问问题,在从调试收集的证据表明存在任何内部异常的情况下,酌情从库供应商处获得支持;否则,请确保在 NetWorker 支持中升级调试输出,以调查代码缺陷的可能性。
其他信息
本文是使用 NetWorker 对磁带库进行故障处理系列文章之一。
受影响的产品
NetWorker产品
NetWorker Series文章属性
文章编号: 000079463
文章类型: Solution
上次修改时间: 30 3月 2026
版本: 4
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。