カテゴリー: NetBackup

投稿日:

NetBackupクライアントの接続エラーに関して調査

Veritas NetBackupにおいて、NetBackupクライアントとの接続に問題があった場合の調査手法についてメモ書き

1.1 マスタサーバ/メディアサーバ上での名前解決確認

マスタサーバ/メディアサーバ上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、自身の名前解決状況を確認する。

# bpclntcmd -hn マスタサーバ/メディアサーバ名
# bpclntcmd -hn ドメイン名付きのマスタサーバ/メディアサーバ名
# bpclntcmd -ip IPアドレス

ここで予期しないIPアドレスが出てきてしまうのであれば、ホスト名/IPアドレス/DNS設定を見直すこと。

続いて問題が発生しているクライアントについての名前解決状況を確認する。

# bpclntcmd -hn クライアントホスト名
# bpclntcmd -hn ドメイン名付きのクライアントホスト名
# bpclntcmd -ip クライアントのIPアドレス

クライアントホスト名からIPアドレスが取得できないようであれば、DNS設定を見直し、DNS関連の設定変更ができない場合は　hostsファイル(/etc/hosts, C:\Windows\System32\drivers\etc\hosts)にクライアントホスト名のエントリを追加すること。

追加後は、再度bpclntcmdを実行して、状況が変化したことを確認する。

1.2. クライアント上での名前解決確認

クライアント上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、自身の名前解決状況を確認する。 

# bpclntcmd -hn クライアントホスト名
# bpclntcmd -hn ドメイン名付きのクライアントホスト名
# bpclntcmd -ip クライアントのIPアドレス

通常はクライアント自身については正常に情報が取得できるはずです。

続いてマスタサーバ/メディアサーバについての名前解決状況を確認

# bpclntcmd -hn マスタサーバ/メディアサーバ名
# bpclntcmd -hn ドメイン名付きのマスタサーバ/メディアサーバ名
# bpclntcmd -ip IPアドレス

マスタサーバ上で実行した結果と異なる場合は、名前解決情報のキャッシュが残存している可能性があるため、「bpclntcmd -clear_host_cache」を実行してキャッシュ削除した上で、再度、名前解決状況を確認する。

マスタサーバ/メディアサーバ名からIPアドレスが取得できないようであれば、DNS設定を見直し、DNS関連の設定変更ができない場合は　hostsファイル(/etc/hosts, C:\Windows\System32\drivers\etc\hosts)にマスタサーバ/メディアサーバ 名のエントリを追加すること。

1.3. クライアント上でマスタサーバが認識している情報の確認

クライアント上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、NetBackupが認識しているホスト名情報を確認する。

# bpclntcmd -pn -verbose

2.1. 接続テストを実施

マスタサーバ上で、/usr/openv/netbackup/bin/admincmd/bptestbpcd もしくは C:\Program Files\Veritas\NetBacku\bin\admin\bptestbpcd を実行して、 マスターサーバからクライアントへの接続テストを実施します。

# bptestbpcd -client クライアントホスト名 -verbose -debug

(Veritas KB: How to test client connections using the bptestbpcd command)

2.2 接続テスト2

マスタサーバ上で /usr/openv/netbackup/bin/bptestnetconn もしくは C:\Program Files\Veritas\NetBacku\bin\bptestnetconn.exe を実行して、接続を確認

# bptestnetconn -asp -H クライアントホスト名

(Veritas KB: Best Practices for bptestnetconn including arguments and outputs by NetBackup version )
(Veritas KB: Using bptestnetconn to test connectivity between NetBackup hosts )

おまけ: クライアントの情報が取得できるか確認

マスタサーバ上で、/usr/openv/netbackup/bin/admincmd か C:\Program Files\Veritas\NetBacku\bin\admin にある bpgetconfig を実行して、マスタサーバからクライアント上のNetBackup Agentのインストール情報を確認します。

# bpgetconfig -g クライアントホスト名 -L

出力内に、Agentのインストール先やバージョンが表示されれば接続できています。

(Veritas KB: Command line option to get client NetBackup version, OS, and hardware type)

おまけ2: 複数NICがある場合の設定に関する資料

・How to follow best practices when using Preferred Network entries
　調査時に使うbplocaladdrsコマンド, bptestnetconnコマンド, bptestbpcdコマンドの出力サンプルあり

・Best Practices when assigning an IP address to the appliance management interface
　bp.confにPREFERRED_NETWORK=～というエントリを追加する、という話

・Required Interface or Preferred Network settings seem to cause connections between non-routed networks on weakhost platforms
　bp.confにPREFERRED_NETWORKかREQUIRED_INTERFACE設定をする
　(PREFERRED_NETWORKはNBU7.xで追加された設定項目)

・How to force backups over multiple specific networks interfaces instead of all those available.

NetBackup 8.xでの証明書関連エラー対応

クライアントインストール時にサーバとの通信がうまくいかなかったけど、無視してインストールを完了した場合、サーバの証明書が、クライアント側に保存されておらず、バックアップを行うとエラーになる。

1: (7660) ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません 

2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Connecting host:  NBUサーバ
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] ConnectionId: {149DAA97-CA51-4AC8-8E38-F4F253D9B113}:OUTBOUND
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] pid: 2556
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Received status: 7660 with message 証明書のマッピングファイルを読み込めません。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) ホスト ( NBUクライアント) 上のピアプロキシで使用可能な証明書が見つかりませんでした。 証明書が正常に配備されていない可能性があります。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] 処理中 (CertProtocol) にエラーが発生しました (CERT_PROTOCOL_SELECT_COMMON_CA_ROOT)。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956)  NBUクライアント の bpcd が状態 7660 で終了しました: ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Connecting host:  NBUサーバ
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] ConnectionId: {84C7C072-EC87-4247-AE80-9066320C5EA5}:OUTBOUND
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] pid: 2556
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Received status: 7660 with message 証明書のマッピングファイルを読み込めません。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) ホスト ( NBUクライアント) 上のピアプロキシで使用可能な証明書が見つかりませんでした。 証明書が正常に配備されていない可能性があります。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] 処理中 (CertProtocol) にエラーが発生しました (CERT_PROTOCOL_SELECT_COMMON_CA_ROOT)。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956)  NBUクライアント の BPCD が状態 61 で終了したため、メールを送信できません: VNETD プロキシでエラーが発生しました
2022/10/24 10:28:10 - 情報 bpbkar32 (pid=0) done. status: 7660: ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません
2022/10/24 10:28:10 - 推定で 0 KB 必要です
2022/10/24 10:28:10 - 情報 nbjm (pid=4240) started backup (backupid= NBUクライアント_1666574889) job for client  NBUクライアント, policy  NBUクライアント, schedule Full on storage unit diskstorage
2022/10/24 10:28:10 - 開始されたプロセス bpbrm (pid=1956)
2022/10/24 10:28:10 - 書き込みの終了
ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません  (7660)

このエラーに関するKB 「How to resolve communication problems due to certificate errors after upgrading to 8.1 from a previously re-installed 8.0 host」「How to manually obtain a host ID Certificate.」「How to re-issue a token on a NetBackup 8.1.x client that has been reinstalled」

上記からNetBackupクライアントから証明書取得のコマンドを実行してみる

# /usr/openv/netbackup/bin/nbcertcmd  -getCertificate -host  NBUクライアント -server NBUサーバ
nbcertcmd: The -getCertificate operation failed for server NBUサーバ
EXIT STATUS 8500: Connection with the web service was not established.
#

これはNetBackupサーバ側でポートが正しく空いていないためだった(Status Code:8500 Error when trying to install agent on new server)

今回はWindows Server上だったので、Windows FIrewallに対して、ポート1556とポート13724を開けた。(NetBackup master server portsをみるともポート 13782 もあった方がよさそう)

再実行すると下記となる

# /usr/openv/netbackup/bin/nbcertcmd  -getCertificate -host  NBUクライアント -server NBUサーバ
nbcertcmd: The -getCertificate operation failed for server NBUサーバ.
EXIT STATUS 8508: List of trusted Certificate Authorities could not be fetched.
#

これは証明書管理にホストが登録されていないために発生しています

新規トークンを発行します

ここで表示されるトークン値を使います

# /usr/openv/netbackup/bin/nbcertcmd -getCertificate -token QWRNKOHALAKDPAGF
nbcertcmd: The -getCertificate operation failed for server NBUサーバ.
EXIT STATUS 8508: List of trusted Certificate Authorities could not be fetched.
#

なんだろと調査をいろいろしてみるとnbcertcmd -displayCACertDetailの実行結果で問題が・・・

# /usr/openv/netbackup/bin/nbcertcmd -displayCACertDetail -server NBUサーバ

CA Certificate received successfully from server NBUサーバ.

         Subject Name : /CN=nbatd/OU=root@NBUサーバ/O=vx
           Start Date : 10月 20 04:36:48 2022 GMT
          Expiry Date : 10月 15 05:51:48 2042 GMT
     SHA1 Fingerprint : E4:3C:2E:12:4C:66:DF:62:28:98:C1:D3:EB:5A:E0:44:4F:52:64:62
 CA Certificate State : Not Trusted

# /usr/openv/netbackup/bin/nbcertcmd -displayCACertDetail -server NBUサーバ.adosakana.local
The target server NBUサーバ.adosakana.local could not be authenticated.
The server name does not match any of the host names listed in the server's certificate.
Names listed in the server's certificate are:
DNS:NBUサーバ
Failed to display CA certificate details

nbcertcmd: The -displayCACertDetail operation failed.
EXIT STATUS 8509: The specified server name was not found in the web service certificate
#

NetBackupサーバ上の証明書がドメイン無しで発行されているのにたいして、NetBackupクライアント側からはドメイン有りで接続しようとしているのでエラーとなっていた模様。

NetBackupサーバ側の証明書変更手法が分からないのでNetBackupクライアント側のbp.confのSERVER記述をドメイン無しに書き換えて再実行

# /usr/openv/netbackup/bin/nbcertcmd -getCertificate -token QWRNKOHALAKDPAGF -force
nbcertcmd: The -getCertificate operation failed for server NBUサーバ.
EXIT STATUS 8508: List of trusted Certificate Authorities could not be fetched.
#

これだけではなかった模様

「nbcertcmd -getCACertificate」を実行して取り込みした上で「nbcertcmd -getCertificate -token」で成功

# /usr/openv/netbackup/bin/nbcertcmd -getCACertificate
Authenticity of root certificate cannot be established.
The SHA1 fingerprint of root certificate is E4:3C:2E:12:4C:66:DF:62:28:98:C1:D3:EB:5A:E0:44:4F:52:64:62.
Are you sure you want to continue using this certificate ? (y/n): y
The validation of root certificate fingerprint is successful.
CA certificate stored successfully from server NBUサーバ.
# /usr/openv/netbackup/bin/nbcertcmd -getCertificate -token
QWRNKOHALAKDPAGF -force
Host certificate and certificate revocation list received successfully from server NBUサーバ
#

GUI上にも登録できた

投稿日:

QUADSTOR VLTを使ってみた

2024/11/12追記

2024年10月上旬頃よりquadstorにあったDownloadページがなくなった。

その前ぐらいから、quadstor vtlで新規にVTLを作成する場合に使用していたテープライブラリ定義が含まれなくなっていた。変更記録に特になにも書いてないから、ミスなのかな？とか思ってたが、ずっとその状態。

フリーで提供するのを止めた、ということなんだろうか・・・

以前「オープンソース版もあるVTLソフトウェアQUADSTOR」という記事を作成したが、使ってはいなかった。

よく見てみたら、ローカルのテープ装置/テープライブラリとしてエミュレートしてくれる機能もあったので、NetBackup Linuxでテープライブラリを使う案件が来たついでに、練習のためQUADSTORを使ってみた。

QUADSTORの注意点

  • CGIを使うWebインタフェースのプログラム(標準はポート80使用)
  • Webインタフェースに認証機能がないので要注意（アクセスすれば誰でも消せます)
  • SELinux環境下で使う場合、後述のSELinuxコマンドを実行すること
  • 仮想テープのデータを保存する領域はRAWデバイスディスクが必要(OSからマウントされない)
  • QUADSTORの起動に時間がかかる（うちの環境では10分かかった)

セットアップ実施

セットアップは簡単で、「Installation/Upgrading on RHEL/CentOS 6/7, SLES 12 SP2 and Debian 7/8」に書いてあるものをそのまま実行した形である。

# yum install httpd gcc perl kernel-devel sg3_utils
# rpm -ivh quadstor-vtl-ext-3.0.31.1-rhel.x86_64.rpm

プログラムの自動起動で以下を実行

# systemctl enable httpd.service
# systemctl enable quadstorvtl.service

SELinux環境で動作するように下記の設定を実行

# setsebool -P httpd_enable_cgi 1
# semanage permissive -a httpd_t

なお「semanage」は標準ではインストールされていないので「yum install policycoreutils-python」を実行して、追加インストールする必要がある。

Webインタフェースにアクセスする為に、firewallに穴を開けます。

# firewall-cmd --permanent --zone=public --add-service=http

iSCSIデバイスとして動作するので、iSCSIで使用するポートについても設定します。

# firewall-cmd --permanent --zone=public --add-service=iscsi-target

また、Webインタフェースには認証機能がなく、誰でも使用できる状態であるため「Accessing the Web Management Interface」の「SECURING ACCESS TO THE WEB INTERFACE」に記載されているように.htpasswdを使ってアクセス制限をかけましょう。

QUADstorとhttpdを起動します。

# systemctl start quadstorvtl
# systemctl start httpd

起動後、Webインタフェースにアクセスすると、以下の様な感じの画面がでてきます。

「Server Status: Server initialized and running」となっていればQUADstorの起動が完了しています。

まず「Physical Storage」タブにアクセスすると、いまマウントされているなローカルディスクが表示されます。

[Add]をクリックし、下記画面からQUADstor管理下に設定します。

指定したディスクの初期化が始まります。

なお、初期化中にさらなる追加を行おうとすると「ERROR: Reply from server is “Cannot add a disk when another is being configured “」とエラーになります。

初期化が終わると、下記の様になります。(なお、表示は自動更新されるますので、ブラウザの手動更新は不要です)

もう片側のディスクも同様に登録し、完了するのを待ちます。

次に「Virtual Libraries」から「Add VTL」よりテープチェンジャーを作成します。

[Add VTL]をクリックし、作成するテープチェンジャの設定を指定します。

登録したテープチェンジャーは下記の様に見えます。

作成した状態では中にテープメディアが入っていない状態です。

テープメディアは「VCartridge Information」にある[Add VCartridge]から行います。

テープメディアの種類はLTOドライブの選択に従って自動的に行われています。

指定するのは、作成する本数(Number of VCartridges)と、メディアにつけるバーコードラベルの書式指定です。

バーコード書式は英数6文字で、例えばLTO1カートリッジを10本、ラベル:BK0000と指定した場合「BK0000L1」～「BK0009L1」のテープメディアが登録されることになります。

iSCSIのテープ装置としては作成されましたので、Linuxサーバから接続してみます。

CentOS7だったら、まずは「yum install iscsi-initiator-utils」で接続に必要なソフトウェアをインストールします。

続いて、iSCSI接続を永続化するため「systemctl enable iscsid」を実行します。

「iscsiadm -m discovery -t sendtargets -p ＜IPアドレス＞」を実行し、検出したあと、「iscsiadm -m node –login -p ＜IPアドレス＞」でログインします。

# iscsiadm -m discovery -t sendtargets -p ＜IPアドレス＞
# iscsiadm -m node --login -p ＜IPアドレス＞

接続するとLinux上からは下記の様に見えるようになります。

# cat /proc/scsi/scsi
＜略＞
Host: scsi34 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: ULT3580-TD1      Rev: D711
  Type:   Sequential-Access                ANSI  SCSI revision: 06
Host: scsi33 Channel: 00 Id: 00 Lun: 00
  Vendor: ADIC     Model: Scalar 24        Rev: 6.24
  Type:   Medium Changer                   ANSI  SCSI revision: 03
#

NetBackupのコマンドで確認してみると、下記の様にみえました。

# /usr/openv/volmgr/bin/tpautoconf -t
TPAC60 IBM     ULT3580-TD1     D711 2688700001 -1 -1 -1 -1 /dev/nst0 - -
# /usr/openv/volmgr/bin/tpautoconf -r
TPAC60 ADIC    Scalar 24       6.24 26887167A2DC4D54B8910000 -1 -1 -1 -1 /dev/sg4 - -
# /usr/openv/volmgr/bin/scan
************************************************************
*********************** SDT_TAPE    ************************
*********************** SDT_CHANGER ************************
************************************************************
------------------------------------------------------------
Device Name  : "/dev/sg4"
Passthru Name: "/dev/sg4"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "ADIC    Scalar 24       6.24"
Vendor ID  : "ADIC    "
Product ID : "Scalar 24       "
Product Rev: "6.24"
Serial Number: "26887167A2DC4D54B8910000"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "ADIC    26887167A2DC4D54B8910000"
Device Type    : SDT_CHANGER
NetBackup Robot Type: 8
Removable      : Yes
Device Supports: SCSI-3
Number of Drives : 1
Number of Slots  : 20
Number of Media Access Ports: 1
Drive 1 Serial Number      : "2688700001"
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/nst0"
Passthru Name: "/dev/sg3"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "IBM     ULT3580-TD1     D711"
Vendor ID  : "IBM     "
Product ID : "ULT3580-TD1     "
Product Rev: "D711"
Serial Number: "2688700001"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "IBM     ULT3580-TD1     2688700001"
Device Type    : SDT_TAPE
NetBackup Drive Type: 3
Removable      : Yes
Device Supports: SCSI-6
Flags : 0x0
Reason: 0x0
#

ドキュメントを確認すると、「Data deduplication best practices」というのがあり、重複排除が行われた状態でRAWストレージに格納されている模様。

2019/11/01追記

QUADstorをアップデートする場合の注意点。

「rpm -Uvh quadstor*.rpm」といったアップデートはできない。

一度、アンインストールした上で、再インストールする必要がある。

ここまでは「Installation or Upgrading the VTL software」にも書かれているのだが、実際にやろうとするとスクリプトの実行に失敗する場合がある。

アンインストール時、quadstorによりinitrd imageに組み込まれたモジュールを削除するために、quadstorの停止とモジュールのアンロードが実施されるのだが、モジュールの使用状況によってはアンロードが失敗する場合がある。

その場合は、一度OSを再起動して、モジュールがロードされていない状態にしないとアンインストールができなかった。

CentOS7の場合、以下の手順で行った。

(1) 「systemctl mask quadstorvtl」で再起動時にQUADstorが起動しない様に設定(maskしなくでも大丈夫な場合もある)
(2) OS再起動
(3) 「rpm -ev quadstor-vtl-ext-3.0.36-rhel.x86_64」といった感じでパッケージ削除
(4) 「rpm -ivh quadstor-vtl-ext-3.0.37-rhel.x86_64.rpm」といった感じでパッケージインストール
(5) 「 systemctl unmask quadstorvtl」 「systemctl enable quadstorvtl」で有効化
(6) OS再起動

2021/10/21追記

QUADStorVTLではなくて普通のiSCSIストレージに接続するために、Oracle Linux 8環境で「iscsiadm -m discovery -t sendtarget -p IPアドレス」を実行したら何も見つからなかった。

RHEL6ドキュメントを見直してみると「-t sendtarget」ではなく「-t st」だったのでこちらでやってみたら通った。というメモ書き

[root@oraclelinux ~]# iscsiadm -m discovery -t sendtarget -p 172.17.73.21 -o new
iscsiadm: Discovery record [172.17.73.21,3260] not found!
[root@oraclelinux ~]# iscsiadm -m discovery -t sendtarget -p 172.17.73.21 -d 5
iscsiadm: Max file limits 1024 262144
iscsiadm: Could not open /var/lib/iscsi/send_targets/172.17.73.21,3260: No such file or directory
iscsiadm: Discovery record [172.17.73.21,3260] not found!
[root@oraclelinux ~]# iscsiadm -m discovery -t st -p 172.17.73.21 -o new
172.17.73.21:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
192.168.1.200:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
192.168.11.3:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
192.168.12.1:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
172.17.73.21:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
192.168.1.200:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
192.168.11.3:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
192.168.12.1:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
[root@oraclelinux ~]#
投稿日:

NetBackupのマスターサーバを新しくする場合の資料

NetBackupのサーバを新しく置き換える場合の資料に関して

基本：「How to migrate the NetBackup catalog information from one platform to another (UNIX to Windows or vice versa), rename a Master Server, cluster an existing Master Server, or merge multiple NetBackup domains.」
ここに資料がまとまっている。
・Windows環境を新しくする場合「Using catalog backup and recovery to transfer NetBackup catalogs between Windows master servers as part of a hardware refresh」
・Unix/Linux環境を新しくする場合「Using catalog backup and recovery to transfer NetBackup catalogs between UNIX or Linux master servers as part of a hardware refresh」
・Windows環境<=>Unix/Linux環境の置き換えは、コンサルタントサービス契約が必要
なお、結構な金額と１ヶ月以上の作業工期がかかるそうです

環境を新しくする際、メディアサーバも変わることが多い。
その場合、無くなるメディアサーバは、マスタサーバが古い状態の時に、オフライン扱いにしておかないと、メディア管理上めんどうなことになる。
→「What is the process for decommissioning a NetBackup 6.5 or 7.x media server?」
(NBU8.x環境では不要？)

NetBackup 8.1.2で、HP-UXとAIXがNetBackupのマスタサーバ/メディアサーバになれなくなる
このため、サポートが継続されるLinuxかSolaris環境へ移行するためのドキュメントが公開されている。
現在サポートされているNetBackup 7.7～8.1.1までのバージョンを対象としているが、それ以前でもだいたい同じとなる。
・マスタサーバ向け「NetBackup Master Server Migration Guide」
・メディアサーバ向け「NetBackup Media Server Migration Guide」

投稿日:

NetBackupのトラブル調査とログ取り

しばらくやってなかったら忘却してしまったのでメモ書き

・NetBackupサポートユーティリティ(nbsu)を使った一括収集

インストールパス/NetBackup/bin/support 以下で以下を実行する 

nbsu -t -c -g OS -s OS_ODBC -s OS_currentcontrolset_reg -s OS_currentversion_reg -g NET -s NET_network_reg -s NET_services -g DEV -s DEV_scsi_reg -g MM -g NBU -s NBU_vrts_reg -s NBU_nbdb_info -s NBU_bptestnetconn

実行後、support/output/nbsu/ に結果が出力される。
なお、クライアント台数および保存期間が長いような環境では、上記コマンドをそのまま実行すると終了までかなり時間がかかることがある。

また、NetBackup 8.1.1では上記オプションを使うのはold_nbsuとなり、新しい「nbsu」はオプションいらなくなった模様
参考資料:Veritas NetBackup™ トラブルシューティングガイド「NetBackup サポートユーティリティ (nbsu) について」

・nbcplogs によるログ収集

インストールパス/NetBackup/bin/support 以下で以下を実行する 

nbcplogs -d 期間 出力先ディレクトリ

例: nbcplogs -d 7d /tmp/nblogs
/tmp/nblogs ディレクトリに、過去7Days分のログを出力する
なお、出力に時間がかかる場合がある

インストールパス/NetBackup/bin/admincmd 以下にある管理ツール群

・普通にエラーログなどを取得 

bperror -L -hoursago 672 -columns 200

・NetBackupの全体設定確認 

　bpconfig -U
　bpgetconfig

・バックアップ設定(ポリシー)確認 

bppllist -L -allpolicies

・バックアップデバイス確認 

bpstulist -U
nbstlutil list -l

・バックアップメディア一覧と有効期限の確認 

bpmedialist -U

・バックアップされたイメージ一覧 

bpimagelist -idonly -d 01/01/1970 00:00:00

・ライセンスの確認 

get_license_key

・Storage Life Cycle Policy(SLP)設定 

nbstl -L -all_versions

他に関連するNetBackupに関する資料。

NetBackupのGUI(jnbSA)上で行う操作をコマンドで置き換えるとしたらどのようになるのか？→「NetBackupの操作をコマンドで行う」

テープチェンジャのインベントリ関連操作をコマンドで行うにはどうするのか？→「NetBackupでインベントリ操作をコマンドで実行する方法」

他のNetBackupで使っていたテープメディアを読み出すには？→「NetBackupで他のNetBackupサーバから持ってきたテープメディア内のデータをリストアする」

投稿日:

日本語のWindows環境でNetBackupのJREをアップデートしようとすると失敗する

Veritas NetBackupではGUIインタフェースにJavaを使用しており、インストールディレクトリにJREも含まれている。
NetBackup 7.7以降では、このJREをアップデートするためのコマンド nbcomponentupdate が用意され、JREのアップデートを個別で行うことができるようになった。
「NetBackup 8.1.1 Command Reference Guide – nbcomponentupdate」
「Updating JRE for NetBackup and OpsCenter」

しかし、日本語のWindows環境では２つの原因により素直に実行できない。

・空き容量チェックをdirのコマンドに表示される「XXX Byte free」という文字列で行っている。
日本語環境では「XXX バイトの空き容量」となるため、空き容量検出に失敗する
・nbcomponentupdate内でNetBackupサービスの停止を行っているが、やはり英語文字列を見ている。
日本語Locate Packを適用したNetBackupではコードページを変えても常に日本語文字列で出力するため
サービスの停止確認に失敗する

これを回避するためには、以下の手順で実行する必要がある。

1. コマンドプロンプトを開く

2. Javaのバージョンを確認する

C:\Windows\system32>"\Program Files\Veritas\NetBackup\jre\bin\java.exe" -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b11\3, mixed mode)

C:\Windows\system32>

3. bpdownを実行し、NetBackupを停止

C:\Windows\system32>"\Program Files\Veritas\NetBackup\bin\bpdown.exe" /f /v
NetBackup 8.0 -- 停止ユーティリティ

サービスの停止中
> NetBackup Bare Metal Restore Master Server
> NetBackup Bare Metal Restore Master Server -- 停止状態
> NetBackup Web Management Console
> NetBackup Web Management Console -- 停止状態
> NetBackup Indexing Manager
> NetBackup Indexing Manager -- 停止状態
> NetBackup Service Monitor
> NetBackup Service Monitor -- 停止状態
> NetBackup Agent Request Server
> NetBackup Agent Request Server -- 停止状態
> NetBackup Storage Lifecycle Manager
> NetBackup Storage Lifecycle Manager -- 停止状態
> NetBackup Key Management Service
> NetBackup Key Management Service -- 停止状態
> NetBackup Vault Manager
> NetBackup Vault Manager -- 停止状態
> NetBackup Service Layer
> NetBackup Service Layer -- 停止状態
> NetBackup Policy Execution Manager
> NetBackup Policy Execution Manager -- 停止状態
> NetBackup Job Manager
> NetBackup Job Manager -- 停止状態
> NetBackup Request Daemon
> NetBackup Request Daemon -- 停止状態
> NetBackup Compatibility Service
> NetBackup Compatibility Service -- 停止状態
> NetBackup Database Manager
> NetBackup Database Manager -- 停止状態
> NetBackup Audit Manager
> NetBackup Audit Manager -- 停止状態
> NetBackup Authorization
> NetBackup Authorization -- 無効状態
> NetBackup Authentication
> NetBackup Authentication -- 停止状態
> NetBackup CloudStore Service Container
> NetBackup CloudStore Service Container -- 停止状態
> NetBackup Deduplication Engine
> NetBackup Deduplication Engine -- 無効状態
> NetBackup Deduplication Manager
> NetBackup Deduplication Manager -- 無効状態
> NetBackup Remote Manager and Monitor Service
> NetBackup Remote Manager and Monitor Service -- 停止状態
> NetBackup Device Manager
> NetBackup Device Manager -- 停止状態
> NetBackup Volume Manager
> NetBackup Volume Manager -- 停止状態
> NetBackup Resource Broker
> NetBackup Resource Broker -- 停止状態
> NetBackup Enterprise Media Manager
> NetBackup Enterprise Media Manager -- 停止状態
> NetBackup Relational Database Manager
> NetBackup Relational Database Manager -- 停止状態
> NetBackup Event Manager
> NetBackup Event Manager -- 停止状態
> NetBackup Deduplication Multi-Threaded Agent
> NetBackup Deduplication Multi-Threaded Agent -- 停止状態
> NetBackup Discovery Framework
> NetBackup Discovery Framework -- 停止状態
> NetBackup SAN Client Fibre Transport Service
> NetBackup SAN Client Fibre Transport Service -- 無効状態
> NetBackup Client Service
> NetBackup Client Service -- 停止状態
> NetBackup Legacy Client Service
> NetBackup Legacy Client Service -- 停止状態
> NetBackup Legacy Network Service
> NetBackup Legacy Network Service -- 停止状態

ロボット制御デーモンの停止中

停止が正常に完了しました。
C:\Windows\system32>

4. コードページ 437(英語)に変更するため「chcp 437」を実行

C:\Windows\system32>chcp 437
Active code page: 437

C:\Windows\system32>

5. nbcomponentupdateコマンドでJREをアップデート

今回は、c:\Program Files\Java\jre1.8.0_171 にインストールされているJRE 1.8.0 Build 171を指定した。

C:\Windows\system32>"\Program Files\Veritas\NetBackup\bin\goodies\nbcomponentupdate.exe" -Product NetBackup -component jre -path "c:\Program Files\Java\jre1.8.0_171"
Command line: C:\Program Files\Veritas\NetBackup\bin\goodies\nbcomponentupdate.exe -Product NetBackup -component jre -path c:\Program Files\Java\jre1.8.0_171

Java Runtime Envrionment(JRE) version installed with product 'Veritas NetBackup'                                 : 1.8.0_101 (64bit)
Java Runtime Envrionment(JRE) version found at path 'c:\Program Files\Java\jre1.8.0_171'                         : 1.8.0_171 (64bit)

This utility will update the Java Runtime Envrionment(JRE) binaries present at 'C:\Program Files\Veritas\NetBackup\jre' path

This utility may start and stop all (or some) services depending upon the present state of services.

Do you want to continue (Y[es]/N[o]): y

Performing upgrade steps ...

[1/4] Pre-installation step is in progress
[1/4] Pre-installation step is completed successfully

[2/4] Installation step is in progress
[2/4] Installation step is completed successfully

[3/4] Post-installation step is in progress
[3/4] Post-installation step is completed successfully

[4/4] Commit and Cleanup step is in progress
[4/4] Commit and Cleanup step is completed successfully

After upgrading, Java Runtime Envrionment(JRE) version installed with product 'Veritas NetBackup'                                 : 1.8.0_171 (64bit)

Successfully upgraded Java Runtime Envrionment(JRE) for Veritas NetBackup.
The log file generated for this operation is C:\Users\ADMINI~1\AppData\Local\Temp\2\logs\nbcomponentupdate\nbcomponentupdate_20-06-2018_17.17.37.log

C:\Windows\system32>

なお、NetBackupサービスはバージョンによっては自動的に起動されたりするようだ。

自働起動しなかった場合は「bpup」を実行して起動する

6. Javaのバージョンを確認する

C:\Windows\system32>"\Program Files\Veritas\NetBackup\jre\bin\java.exe" -version
java version "1.8.0_171"
Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)

C:\Windows\system32>

7. 更新完了

2021/04/26追記

Oracle JRE 1.8.0u291にアップデートをかけてみたところ、NetBackup Web Management Consoleが起動できなくなるという問題が発生しました。

このため「nbcomponentupdate.exe -Product NetBackup -component jre -revert」を実行し、以前のバージョンに戻してみたところ正常に動作しました。

NetBackup 8.1.1のデフォルトは1.8.0 u151で、手持ちの古いバージョンのうちOracle JRE 1.8.0u172とOracle JRE 1.8.0u241はnbcomponentupdateでアップデートして動作しました。

AZULのZulu Open JRE 1.8.0 はデフォルトインストール先が C:\Program Files\Zulu\zulu-8-jre\ で、バージョンが入ってないからダメだそうで・・・

AdoptOpen JDK 1.8.0 のデフォルトインストール先は C:\Program Files\AdoptOpenJDK\jre-8.0.292.10-hotspot\ で、こちらもやはり使用できませんでした。

ちなみにインストール先を「C:\Program Files\Zulu\jre1.8.0_292」とか「C:\Program Files\Java\jre1.8.0_292」に変更してみましたが同じエラー

java -versionの結果を比較すると「java version」ではなく「openjdk version」に切り替わっているので失敗していた模様

というわけで、NetBackup 8.1.1/8.1.2などではOracle以外のJavaに切り替えることはできない模様です。