NetWorkerでのテープ ライブラリーへのアクセスに関する問題のトラブルシューティング

概要: この記事は、検出されたロボットがコマンドを受け付けない原因を、サポートとNetWorker管理者が特定するのに役立ちます。

この記事は次に適用されます： この記事は次には適用されません： この記事は、特定の製品に関連付けられていません。 すべての製品パージョンがこの記事に記載されているわけではありません。
他のリソースを確認する

現象

 

  • NetWorkerストレージ ノードまたはサーバーで検出されたテープ ライブラリーのインストールにアクセスできません
  • バックアップ ハードウェアが使用できないため、データをバックアップできない
  • ロボットへのアクセスエラー:
    • 0x29
    • Device busy
    • The requested resource is busy
    • Str=<There is an input or output error.>
    • No such device
    • No such file or directory
    • Inappropriate ioctl for device

原因

ライブラリが以前は動作していたのに、突然動作しなくなった場合は、考えられる原因として最新の既知の変更を考慮してください。

  • 再起動、再検出、デバイス名変更後のライブラリアドレスの変更が未処理
  • 電力サージ、停電、またはその他の環境イベントによる損傷の可能性
  • 障害イベントまたは転送ハードウェアの再構成
  • 輸送またはロボットに関するソフトウェアまたはドライバーのインストール、変更、または削除

ライブラリーが機能していない場合は、『NetWorkerハードウェア互換性ガイド』でハードウェアがサポートされていることを確認します(Dellサポート アカウントへのサインインが必要)。ライブラリが部分的に機能する可能性があることに注意してください。検出だけでは、操作性やサポート性は保証されません。

解決方法

ライブラリ アクセスの失敗をトラブルシューティングするには、最近の変更を確認してください。次に、基本的な比較テストとサードパーティの比較テストを使用して、ホストまたはプロセスがロボットからの応答をトリガーできるかどうかを確認します

入手可能な証拠に基づいて、特定の機能をテストすることが望ましい場合があります。ホスト A がロボットにクエリを実行でき、ホスト B がクエリを実行できない場合、ロボットは応答します。ホスト A のドライバーがロボットをロックしている可能性があります。すべてのホストのゾーニングを解除した後もホストBでエラーが発生する場合は、ホストBにドライバー、構成、またはソフトウェアの問題がある可能性があります

問題が発生する前にホストがロボットにアクセスしていた場合、レビュー項目が変更されている可能性が高くなります。イベント後の障害または既知の構成変更を調査します。

ライブラリーが検出されたら、次のコマンドを使用して、EthernetやWeb UIではなく、ストレージ トランスポートを介した基本的なSCSI操作をテストします。特にストレージに関しては、オペレーティング システムのパッチが最新であることを常に確認してください。

メモ: 上記を含む包括的な初期データセットを収集する最も簡単な方法は、 nsrget -o:d 影響を受けるサーバーとノード上。
警告：「 -o:d テープが書き込みビジー状態になっているテープのあるホスト上。これは、NetWorker Management Console (NMC)のモニタリング->Devicesで確認できます。 

次の記事では、NSRGETの取得と使用に関する情報を提供します。NetWorker：「NSRGet NetWorkerデータ コレクション ツールの使用方法（英語）」


図書館へのアクセス: オペレーティングシステム:

  • Windowsの場合：Windows では、テープ ライブラリにクエリを実行するネイティブな方法はありません。 mtx はフリーウェアユーティリティで、必要に応じてテストできます。コマンドの発行時に、SCSIアドレスではなくチェンジャー デバイス ハンドルを使用します(テストに影響する可能性があります)。
loaderinfo -f \\.\changer#
mtx -f \\.\changer# inquiry
 
  • Linuxの場合Windowsと同様に、クエリするネイティブコマンドはありませんが、 mtx ポート。デバイス ドライバー ハンドルが必要です(これもNetWorkerがアクセスする方法とは異なります)。
loaderinfo -f /dev/sg#
mtx -f /dev/sg# inquiry
 
  • Solarisの場合Solarisには、 sgen ネイティブ テープ ライブラリーをサポートするドライバーはあるが、サポートしていない mtx port また、他のネイティブライブラリコマンドも存在しません。代わりに、NetWorkerコマンドに関するセクションを参照してライブラリーへのアクセスをテストします(後述)。
     
  • AIXの場合AIXは、ネイティブ・テープ・ライブラリーをサポートしていません(lus が代わりに使用される)、 mtx ポートが存在します。代わりに、NetWorkerコマンドに関するセクションを参照してライブラリーへのアクセスをテストします(後述)。
  • HP-UX: mc は、メディア チェンジャー操作用のネイティブHP-UXコマンドです。
mc -p $(ioscan  FnkC autoch | grep /dev/rac) -r MIDS -q
 
  • NetWorker：これらのコマンドは比較的アトミックなレベルで機能し、NetWorkerサポートによって作成、コンパイル、テストされますが、機能するために実行中のNetWorkerインスタンスやNetWorkerの構成は必要ありません。一般に、信頼性が高く、低レベルで、ソフトウェアに依存しないテストユーティリティであると考えられています。ほとんどのユーティリティのデバッグを増やすには、次の環境変数を追加します。

SJI_DEBUG=9
LUS_DEBUG=9 (lusdebug ffff on AIX)
CDI_DEBUG=9
SCSI_DEBUG=9
JBDEBUG=9

以下では、'<changer address>オペレーティングシステムによって異なります。

Windowsの場合： Initiator.Target.LUN (によって明らかにされたように inquire command)または \\.\changer# ドライバハンドル
Linux: Intiator.Target.LUN (によって明らかにされたように inquire command)または /dev/sg# ドライバハンドル
Solaris: /dev/scsi/changer/c#t#d# ドライバー ハンドル
AIX: Initiator.Target.LUN (によって明らかにされたように inquire command)
HP-UX: Initiator.Target.LUN (によって明らかにされたように inquire command)または /dev/rac/c#t#d# ドライバーハンドル

sjirjc <changer address>
ドライブの数、サポートされている機能などのデータをロボットに要求します。

sjisn <changer address>
ドライブ要素とシリアル番号の情報をロボットに要求します。

sjirdtag <changer address>
テープ カートリッジに場所データをエレメント化するように要求します

cdi_inq -f <changer driver handle> -v
重要な製品データをリクエストします(ドライバーハンドルの使用が必要)
 
ielem -a <changer address>
要素を再初期化しようとすると、中断が発生する可能性があります。
 

図書館へのアクセス: ライブラリーのリセット:

ライブラリは、ブートサイクルの問題を発生させる期間的で一時的な問題に遭遇する可能性があります。内部の問題を軽減するために、いくつかの対策を講じることができます。

nsrjb -HEvvvvv
問題のあるライブラリにリセット コマンドを発行し、要素の再初期化を強制します。

nsrjb -IIvvvvv
ライブラリによって報告されたバーコードとメディア データベース内の対応する値に基づいて、NetWorker nsrジュークボックス オブジェクトの更新と更新を強制します。

nsrjb -HH
ジュークボックスがすべてのボリュームをアンロードし、ソフト リセットを試行するように強制します。
 
メモ: 上記のコマンドは、ワークフローの後の段階、特にライブラリユニットがコマンドを受け入れる「準備完了」になった後にのみ機能します。そのため、このセクションでは、ライブラリが「準備完了」状態にある「アクセス」の問題を修復する方法の手順のみを提供します。 ielem -a は、 nsrjb -E NetWorkerで機能する nsrジュークボックス は必要ありません。
 

転送 - 構成

  • SANの場合: ロボットと目的のNetWorkerロボット制御ホストの両方がスイッチに正しくログインしていることを確認し、ロボットのゾーニングを確認して、エンドツーエンドの接続が可能であることを確認します。
  • ロボットは、複数のホストからアクセスまたは制御されることを意図したものではありません。必要がない限り(たとえば、分割されたロボット)、目的のNetWorkerロボット コントローラー ホストのみがロボットを認識するようにゾーニングされていることを確認します。
  • SASエキスパンダーをテストして、ロボット接続が確立されていることを確認することが可能です。SCSIのような純粋なポイントツーポイントテクノロジーでは、関連するホストからの接続をテストする必要があります。

トランスポート - ハードウェア

  • ホスト レベルまたは転送ハードウェア レベルで問題が検出された場合は、スイッチまたはエキスパンダーをテストするか、ケーブルを「既知の良好な」例と交換してケーブル接続の問題を除外することを検討してください。
  • トランスポート ハードウェアのファームウェアと、ロボット自体のファームウェアの最新性を確認します。
  • SCSIの場合は、ターミネーターが正しく配置および装着され、ケーブル長の制限が守られ、適切な電圧が使用されていることを確認します。

ホスト トランスポート - 構成

  • 該当するホストに、転送ドライバー用の最新のドライバーとファームウェアがあることを確認します - 次を使用します。 EMCReports (同梱 nsrget -o:e)を提供する必要があります。
  • 必要なホスト バス アダプター(HBA)ドライバーの構成がオペレーティング システムに対して適切に行われることを確認します。

ホスト ソフトウェア - リソース ロック

  • ロボットを表示するようにゾーニングされているホスト(理想的には指定されたNetWorkerホストのみ)について、ロボットにアクセスしようとする他のバックアップ ソフトウェア、監視ソフトウェア、スタンドアロン ユーティリティなど、ロボットにアクセスしようとする可能性のあるソフトウェアをチェックします。
  • Solaris 10では、nsrlcpd NetWorkerプロセスが接続されている場合、ロボットにアクセスできません。したがって、NetWorkerのライブラリが無効になるまではアクセスできない(または検出できない)ように見える場合があります( nsrlcpd 切り離して死ぬ)。
  • NetWorker以外のプロセスがロボットまたはドライブをロックまたはアクセスした疑いがある場合 - トラブルシューティングと識別の詳細については、「 NetWorkerでの上書きされたラベルとSCSIリセットのトラブルシューティング」を参照してください。

オペレーティング システムがライブラリーを検出しても、ライブラリーがコマンドに応答しない場合、ライブラリーはある程度機能しています。別のプロセスまたはホストによってロックされているか、転送の問題の影響を受けているか、コンポーネントレベルの誤動作が発生している可能性があります

ロボットを制御しようとしているNetWorkerストレージ ノード以外に、ロボットにアクセスしていると判断できるプロセスまたはホストがない場合は、「 NetWorkerでのテープ ライブラリー ハードウェアの問題のトラブルシューティング 」を参照して、ロボット自体に問題があるかどうかを判断してください。

その他の情報

アプリケーションとしてのNetWorkerの範囲外であることが示されているロボット工学の問題(標準のオペレーション システムの方法ではアクセスできない)は、NetWorkerのサポートの範囲外であることを確認してください
Networker：NetWorkerでのテープ ライブラリーの問題のトラブルシューティング

サポートは上記の基準を使用してガイダンスを提供できますが、OS、HBA、またはロボット ベンダーのリソースがありません。この制限により、トラブルシューティングが長引いて失敗する可能性があります。

対象製品

NetWorker
文書のプロパティ
文書番号: 000116098
文書の種類: Solution
最終更新: 23 1月 2026
バージョン:  4
質問に対する他のDellユーザーからの回答を見つける
サポート サービス
お使いのデバイスがサポート サービスの対象かどうかを確認してください。