Veritas NetBackup™ トラブルシューティングガイド

手順 1

デバッグログディレクトリを作成します。

通信の再試行時、デバッグログには、問題の分析に有効なデバッグの詳細情報が表示されます。

クライアントとメディアサーバーの通信ではなくクライアントとマスターサーバーの通信の問題をデバッグするには、bprdログディレクトリを使います。

手順 2

新しい構成または変更を行った構成をテストします。

手順 3

名前解決を検証します。

名前解決を検証するには、マスターサーバーとメディアサーバーで次のコマンドを実行します。

# bpclntcmd -hn client name

結果が予想外の場合、nsswitch.conf ファイル、hosts ファイル、ipnodes ファイル、resolv.conf ファイルの名前解決サービスの構成を見直します。

また、クライアントで次を実行し、バックアップを実行するマスターサーバーとメディアサーバーの名前の正引き参照と逆引き参照を調べます。

# bpclntcmd -hn server name

# bpclntcmd -ip IP address of server

手順 4

ネットワークの接続を検証します。

サーバーからクライアントに対して ping を実行することによって、クライアントとサーバーの間でのネットワークの接続を検証します。

# ping clientname

ここで、clientname は NetBackup のポリシー構成で構成されているクライアントの名前です。

たとえば、ant という名前のポリシークライアントに ping を実行すると想定します。

# ping ant 
    ant.nul.nul.com: 64 byte packets
    64 bytes from 199.199.199.24: icmp_seq=0. time=1. ms
    ----ant.nul.nul.com PING Statistics----
    2 packets transmitted, 2 packets received, 0% packet 
    loss round-trip (ms)  min/avg/max = 1/1/1

ping の成功により、サーバーとクライアントの間の接続が検証されます。ping が失敗し、ICMP がホストの間でブロックされない場合は、続行する前に NetBackup に関係のないネットワークの問題を解決してください。

ping コマンドの形式によっては、クライアント上の bpcd ポートに ping を実行できます。次にコマンドの例を示します。

# ping ant 1556 

1556 (PBX)、13724 (vnetd) の順 (NetBackup がデフォルトで試行する順序と同じ) で ping を実行します。これにより、閉じているポートがわかるため、効率的にポートを開いて接続を試みることができます。

手順 5

クライアントが正しいポートで bpcd への接続を待機していることを確認します。

クライアントで、次のいずれかのコマンド (プラットフォームおよびオペレーティングシステムによって異なる) を実行します。

netstat -a | grep bpcd
netstat -a | grep 13782
rpcinfo -p | grep 13782

1556 (PBX) と 13724 (vnetd) で繰り返します。ポートに問題がない場合、想定される出力は次のとおりです。

# netstat -a | egrep '1556|PBX|13724|vnetd|13782|bpcd' | grep LISTEN
 *.1556          *.*      0      0 49152      0 LISTEN
 *.13724         *.*      0      0 49152      0 LISTEN
 *.13782         *.*      0      0 49152      0 LISTEN

LISTEN は、クライアントがポートで接続を待機していることを示します。

NetBackup プロセスを正しく実行している場合に想定される出力を以下に示します。

# ps -ef | egrep 'pbx_exchange|vnetd|bpcd' | grep -v grep
root   306 1 0 Jul 18 ? 13:52 /opt/VRTSpbx/bin/pbx_exchange
root 10274 1 0 Sep 13 ?  0:11 /usr/openv/netbackup/bin/vnetd -standalone
root 10277 1 0 Sep 13 ?  0:45 /usr/openv/netbackup/bin/bpcd -standalone

マスターサーバーとメディアサーバーで手順を繰り返し、クライアントに通信をテストします。

手順 6

telnet によってクライアントに接続します。

クライアントで、telnet を使用して 1556 (PBX) と 13724 (vnetd) に接続します。両方のポートを調べて、少なくともどちらかで接続が確立されていることを確認します。telnet 接続が成功した場合は、手順 8 の実行が終了するまで接続を保持します。手順を実行したら、Ctrl+C を押して接続を切断します。

telnet clientname 1556
telnet clientname 13724

ここで、clientname は NetBackup のポリシー構成で構成されているクライアントの名前です。

次に例を示します。

# telnet ant vnetd
Trying 199.999.999.24 ...
Connected to ant.nul.nul.com.
Escape character is '^]'.

この例では、telnet によってクライアント ant への接続を確立できます。

マスターサーバーとメディアサーバーで手順を繰り返し、クライアントに通信をテストします。

手順 7

サーバーホストのアウトバウンドソケットを識別します。

マスターサーバーとメディアサーバーで: 手順 6 の telnet コマンドに使われたアウトバウンドソケットを識別するには、次のコマンドを使います。 サーバーがポリシークライアントを解決する適切な IP アドレスを指定します。送信元 IP (10.82.105.11)、送信元ポート (45856)、送信先ポート (1556) に注意してください。

# netstat -na | grep '<client_IP_address>' | egrep '1556|13724' 
10.82.105.11.45856 10.82.104.99.1556 49152 0 49152 0 ESTABLISHED

telnet がまだ接続されていて、ソケットが表示されていない場合は、ポート番号のフィルタを削除し、サイトがサービス名をマップしたポート番号を確認します。 手順 5 のポート番号でプロセスが待機していることを確認します。

$ netstat -na | grep '<client_IP_address>' 
10.82.105.11.45856 10.82.104.99.1234 49152 0 49152 0 ESTABLISHED

ソケットが ESTABLISHED 状態ではなく SYN_SENT 状態である場合、サーバーホストは接続を確立しようとします。ただし、ファイアウォールにより、アウトバウンド TCP SYN のクライアントホストへの到達、または返す方向の TCP SYN+ACK のサーバーホストへの到達はブロックされます。

手順 8

telnet 接続がこのクライアントホストに到達することを確認します。

マスターサーバーとメディアサーバーで、telnet 接続がこのクライアントホストに到達することを確認するには、次のコマンドを実行します。

$ netstat -na | grep '<source_port>'
10.82.104.99.1556  10.82.105.11.45856  49152 0 49152 0 ESTABLISHED

手順 9

クライアントとマスターサーバーの間の通信を検証します。

bpclntcmd ユーティリティを使用して、クライアントからマスターサーバーへの通信を検証します。-pn および -sv を指定して NetBackup クライアント上で実行した場合、(クライアント上の bp.conf ファイルで構成されている) NetBackup マスターサーバーへの問い合わせが開始されます。 その後、マスターサーバーから問い合わせ元のクライアントに情報が戻されます。bpclntcmd についての詳細情報を参照できます。

bpclntcmd ユーティリティについてを参照してください。

PBX、vnetd および bprd のデバッグログに、他のエラーの性質に関する詳細が示されます。