Commvault バックアップのWindowsクライアントをPUSHインストールする時のWindows Firewall 設定


Commvaultバックアップは、CommServeからPUSH操作によりWindowsクライアントへのCommvault エージェントのインストールを実施することができる。

その場合に必要なWindows Firewallの除外設定についてのメモ

公式のドキュメント「Prerequisites for Installations Using the CommCell Console」に記載されているが、実際のWindows Firewallテンプレートの記述とあわせていないのでわかりにくい。

試した限りでは「受信の規則」にある下記の3つの既存設定を「規則の有効化」するでいけた

・Windows Management Instrumentaion (DCOM受信)

・ Windows Management Instrumentaion (WMI受信)

・ファイルとプリンターの共有 (SMB 受信)

なお、ping応答もできるようにしたい場合は追加で「ファイルとプリンターの共有 (エコー要求 – ICMPv4 受信)」も有効化する(CommvaultのPUSHインストールにとっては不要)

インストールできるかの確認には、CommServeから「wmic /node:ホスト名 process get」と実行して対象ホストのプロセス一覧が取得出来れば、WMI動作としては問題ない感じです。

なお、CommVaultエージェントインストールにより、「CommVault_Process_1_????」といったルールが大量に登録される。

これは C:\Program Files\CommVault\Simpana\Base\AddFWExclusions.bat にて設定されたルールとなる。

— 2019/08/26追記 —

なんかこの設定だけだとうまくいかない

Visual C++ 2015-2019再頒布可能パッケージがインストールされていない場合に、リモートインストールが失敗することもある模様。


2021/09/03追記

Windows Server 2022でリモートインストールを試したところ、今回も同様に「Windows Management Instrumentaion (DCOM受信)」「Windows Management Instrumentaion (WMI受信)」「ファイルとプリンターの共有 (SMB 受信)」の3つの有効化でリモートインストールが可能になりました。

NetBackupでインベントリ操作をコマンドで実行する方法


NetBackupのテープ関連操作は基本GUIから行うことで解説されている場合が多い。

CLIから行う場合の手順について確認した。

NetBackupで管理しているテープチェンジャーの確認「tpconfig -l」

NetBackupでテープチェンジャーに対する操作を行う場合、テープチェンジャーが持つ操作装置(ロボット)の番号を指定して行う。
このため、管理下にあるロボットの番号をtpconfig -lコマンドで確認する必要がある。
なお、このコマンドでは同時にそのロボット内にあるドライブについても確認出来る。

[root@nbuserver ~]# /usr/openv/volmgr/bin/tpconfig -l
Device Robot Drive       Robot                    Drive                Device     Second
Type     Num Index  Type DrNum Status  Comment    Name                 Path       Device Path
robot      0    -    TLD    -       -  -          -                    /dev/sg2
  drive    -    1 hcart2    1      UP  -          IBM.ULT3580-TD5.000  /dev/nst1
robot      1    -    TLD    -       -  -          -                    /dev/sg4
  drive    -    0    dlt    1  DISABL  -          QUANTUM.SDLT600.000  /dev/nst0
[root@nbuserver ~]#

上記結果サンプルはrobot:1として認識されているSDLT600ドライブがあるロボットはNetBackup側で設定を行っていないためStatusが「DISABLE」となっている。

NetBackupで管理しているテープドライブの確認「tpconfig -d」

テープ装置単独で確認したい場合は「tpconfig -d」を実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/tpconfig -d
Id  DriveName           Type   Residence
      Drive Path                                                       Status
****************************************************************************
0   QUANTUM.SDLT600.000  dlt    TLD(1)  DRIVE=1
      /dev/nst0                                                        DISABLED
1   IBM.ULT3580-TD5.000  hcart2 TLD(0)  DRIVE=1
      /dev/nst1                                                        UP

Currently defined robotics are:
  TLD(0)     robotic path = /dev/sg2
  TLD(1)     robotic path = /dev/sg4

EMM Server = nbuserver

[root@nbuserver ~]#

上記結果サンプルはSDLT600ドライブについてはNetBackup側で設定を行っていないためStatusが「DISABLE」となっている。

テープ装置のインベントリ実行確認「vmupdate -rt tld -rn ロボット番号 -recommend」

GUI操作でいうところの[Inventory Robot]-[Preview volume configuration changes]に相当するものは「vmupdate -rt tld -rn ロボット番号 -recommend」となる。
ロボットのタイプが「TLD」以外の場合は適切に変更すること。

変更がある場合は以下の様に表示される。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0 -recommend
Generating list of recommended changes ...

Proposed Change(s) to Update the Volume Configuration
=====================================================
Logically move media ID O502L5 (barcode LTO502L5) from standalone to slot 3.
[root@nbuserver ~]#

変更がない場合は以下のようになる。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0 -recommend
Generating list of recommended changes ...

Proposed Change(s) to Update the Volume Configuration
=====================================================
Volume configuration is up-to-date with robot contents.
[root@nbuserver ~]#

テープ装置のインベントリ実行「vmupdate -rt tld -rn ロボット番号」

GUI操作でいうところの[Inventory Robot]-[Update volume configuration]に相当するものは「vmupdate -rt tld -rn ロボット番号」となる。
ロボットのタイプが「TLD」以外の場合は適切に変更すること。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0
Generating list of recommended changes ...

Proposed Change(s) to Update the Volume Configuration
=====================================================
Logically move media ID O502L5 (barcode LTO502L5) from standalone to slot 3.
Updating volume configuration ...

Processing existing media added to or moved within the robotic library by
logically moving media as follows...
        Media ID        Slot
        ========        ====
         O502L5            3


Volume configuration successfully updated.

[root@nbuserver ~]#

NetBackupに登録されているテープメディア一覧確認「vmquery -b -a」

NetBackupの管理下にあるテープメディアを確認するには「vmquery -b -a」となる。
テープ装置外にあるメディアについては「robot type:NONE」となる。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -a
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/05/09 18:00
O501L5  HCART2 TLD      0       2     -       -           8     2019/05/10 00:00
O502L5  HCART2 NONE     -      -     -       -           0     0000/00/00 00:00
O503L5  HCART2 TLD      0       4     -       -           0     0000/00/00 00:00
O504L5  HCART2 TLD      0       5     -       -           8     2019/05/10 00:00
[root@nbuserver ~]#

ロボット内のテープメディア一覧確認「vmquery -b -rn ロボット番号」

指定したロボット内にあるメディアを確認するには「vmquery -b -rn ロボット番号」で確認する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -rn 0
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/05/09 18:00
O501L5  HCART2 TLD      0       2     -       -           8     2019/05/10 00:00
O503L5  HCART2 TLD      0       4     -       -           0     0000/00/00 00:00
O504L5  HCART2 TLD      0       5     -       -           8     2019/05/10 00:00
[root@nbuserver ~]#

テープ装置外で保管されているテープメディア一覧「vmquery -b -rt NONE」

テープ装置外で保管されているテープメディアだけを確認するには「vmquery -b -rt NONE」を実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -rt NONE
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O502L5  HCART2 NONE     -      -     -       -           0     0000/00/00 00:00
[root@nbuserver ~]#

現在存在しないテープ装置内にテープメディアが残存してしまっている場合の処理

現在存在しないテープ装置内にテープメディアが残存してしまっている場合、データベース上の登録をvmchangeコマンドで修正する必要がある。

テープメディアの置き場所を「-new_rt」オプションで「NONE」にすることで、テープ装置外であるという認識になる。
なお、Media Typeも指定する必要があるためvmqueryコマンドで現状のMedia Typeを確認すること。

Media IDが「O502L5」のステータスを変更する場合は、以下の様に実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmchange -m O502L5 -new_rt NONE -mt HCART2
[root@nbuserver ~]#

設定変更後は「vmquery -b -a」もしくは「vmquery -b -rt NONE」を実行し、robot typeが「NONE」に変わったことを確認する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery  -b -a
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/05/09 18:00
O501L5  HCART2 TLD      0       2     -       -           8     2019/05/10 00:00
O502L5  HCART2 NONE     -      -     -       -           0     0000/00/00 00:00
O503L5  HCART2 TLD      0       4     -       -           0     0000/00/00 00:00
O504L5  HCART2 TLD      0       5     -       -           8     2019/05/10 00:00
[root@nbuserver ~]#

NetBackupマスタサーバのホスト名を変える手順(非公式


NetBackupマスタサーバのホスト名は通常変更できない。

しかし、探すと、NetBackup 6.0時代の非公式手順なるものが発見出来る。


Change Name of Master Serve」消えそうなので下記に内容を転記しておく。

Renaming a Master Server under NetBackup 6.0 requires making some updates to the EMM database and
EMM configration files as well as the changes to configuration files and registry entries required for earlier
versions of NetBackup. The steps involved are:

1. Shut down NetBackup on the Master Server.
2. Change the various entries for the Master Server and EMM server in bp.conf and vm.conf (or the
registry on a Windows server).
3. Change the value of VXDBMS_NB_SERVER in the vxdbms.conf file (located in
/usr/openv/db/data on UNIX and <install path>\VERITAS\NetBackupDB\data on Windows) to
reflect the name of the new Master Server.
4. Change the corresponding value found the server.conf file (located in /usr/openv/var/global on
UNIX and <install path>\VERITAS\NetBackupDB\conf on Windows)
5. Rename the server and restart it.
6. Re-start NetBackup
7. Run nbemmcmd –renamehost –machinename <old master> -newmachinename <new master> –
machinetype master
8. Re-start NetBackup again
9. Run the command nbemmcmd –listhosts –verbose on the Master Server to confirm that the
entries for ‘server’ and ‘master’ reflect the new Master Server name.
10. Run nbemmcmd –setemmserver –emmserver <old master> -newemmserver <new master> on
each media server
11. Update the entries for the master server in bp.conf and vm.conf (or the registry on a Windows
server) on each media server
12. Update the entries for the master server in bp.conf (or the registry on a Windows server) on each
client server
Note: The process described here cannot be used to change a non-clustered Master Server to a
clustered Master Server. This change involves a separate procedure covered in the document
NBU_non-cluster-to-cluster guide which can be found in the data protection operational documents
area of the CoE web site.
Note: Due to limitations in the nbemmcmd –rename command this process cannot be used to
rename clusters on versions below 6.0 MP6, if the Master Server is clustered we recommend moving
to another cluster rather than renaming the existing cluster.


で、この手順は「NetBackup 6.0MP6」では動いたものの、現代はどうなのか試してみた。

結果・・・

・NetBackup 7.xは上記+1ファイル修正で変更可能だった
・NetBackup 8.0,8.1はSSL証明書に記載されたホスト名の変更手順がわからないので不可
・NetBackup 7.xでもRBACを利用しているとSSL証明書が含まれるため失敗した

という結果でした。

とりあえず、「NetBackup 7.6まで実験済みのマスタサーバホスト名変更手順」は以下です。
ちなみにホスト名変更後、NetBackup 8.1にアップデートを行っています。

2019/08/26追記 「/usr/openv/db/data/.odbc.ini.az」の書き換えを追加

(1) NetBackupサービスを停止する。

# /usr/openv/netbackup/bin/bp.kill_all -v -f
# /usr/openv/netbackup/bin/bpps -x

(2) /usr/openv/netbackup/bp.conf の書き換え

ホスト名記述を変更

(3) /usr/openv/volmgr/vm.conf の書き換え

ホスト名記述を変更

(4) /usr/openv/db/data/vxdbms.conf の書き換え

「NB_ホスト名」の記述を「NB_新ホスト名」に変更

(5) /usr/openv/var/global/server.conf の書き換え

「NB_ホスト名」の記述を「NB_新ホスト名」に変更

(6) /usr/openv/db/bin/servername の書き換え

「NB_ホスト名」の記述を「NB_新ホスト名」に変更

(追加) /usr/openv/db/data/.odbc.ini.az の書き換え

「ENG=~」となっている記述を書き換える

(7) /etc/hosts の編集

新しいホスト名と古いホスト名で同じサーバをさすよう修正

(8) OSホスト名変更

OSの変更手法を使ってホスト名変更

(9) NetBackup自動起動を停止

RHEL6だったら以下でオフ

# chkconfig netbackup off

(10) OS再起動

# reboot

(11) NetBackupが起動していないことを確認

# /usr/openv/netbackup/bin/bpps -x

(12) NetBackup起動

# /usr/openv/netbackup/bin/bp.start_all
# /usr/openv/netbackup/bin/bpps -x

(13) 現状のNetBackup EMMの登録確認

# /usr/openv/netbackup/bin/admincmd/nbemmcmd -listhosts -verbose

(14) EMMの登録修正と確認

# /usr/openv/netbackup/bin/admincmd/nbemmcmd -renamehost -machinename 古いホスト名 -newmachinename 新しいホスト名 -machinetype master
# /usr/openv/netbackup/bin/admincmd/nbemmcmd -listhosts -verbose

(15) NetBackupの再起動

# /usr/openv/netbackup/bin/bp.kill_all
# /usr/openv/netbackup/bin/bpps -x
# /usr/openv/netbackup/bin/bp.start_all
# /usr/openv/netbackup/bin/bpps -x

(16) NetBackupの自動起動設定を復旧させる

RHEL6だったら以下を実行

# chkconfig netbackup on

これは、NetBackupインストーラにより設定が変更されているが、その変更がchkconfig側に反映されていないため実行する必要がある。

最小インストールのRHEL7環境で文字化けせずにNetBackup管理画面を表示するために必要なパッケージ


最小インストールのRHEL7環境で文字化けせずにNetBackup管理画面を表示するために必要なパッケージを確認した。

なお、表示させるのはLinuxサーバローカルのディスプレイではなく、同一ネットワーク上にあるWindows10にインストールされた「VcXSrv

# yum install libXext libXrender libXtst xorg-x11-fonts-Type1 vlgothic-fonts vlgothic-p-fonts

なお、「vlgothic-p-fonts」は入れなくても表示はされるが、文字がゴツゴツした感じとなる。

・vlgothic-fonts vlgothic-p-fontsの両方をインストールした場合


vlgothic-fonts vlgothic-p-fontsの両方をインストールした場合

・vlgothic-fontsのみインストールした場合


vlgothic-fontsのみインストールした場合

NetBackup GUIはJavaを使って表示している。

フォントに関する指定はJREのlibにfontconfig~.srcというファイルで保存されている。

# ls /usr/openv/java/jre/lib/fontconfig*.src
/usr/openv/java/jre/lib/fontconfig.RedHat.5.properties.src
/usr/openv/java/jre/lib/fontconfig.RedHat.6.properties.src
/usr/openv/java/jre/lib/fontconfig.SuSE.10.properties.src
/usr/openv/java/jre/lib/fontconfig.SuSE.11.properties.src
/usr/openv/java/jre/lib/fontconfig.Turbo.properties.src
/usr/openv/java/jre/lib/fontconfig.properties.src
#

「fontconfig.RedHat.6.properties.src」の中を見てみると、関係しそうな記述として以下を発見

# Font File Names
filename.-misc-kochi_gothic-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf
filename.-misc-kochi_mincho-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/ipa-mincho/ipam.ttf
filename.-misc-zysong18030-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/cjkuni-uming/uming.ttc


# AWT X11 font paths
awtfontpath.chinese-tw-iso10646=/usr/share/fonts/cjkuni-uming
awtfontpath.chinese-cn-iso10646=/usr/share/fonts/cjkuni-uming
awtfontpath.japanese-iso10646=/usr/share/fonts/vlgothic
awtfontpath.korean-iso10646=/usr/share/fonts/un-core

どうやら明朝体は「ipa-mincho-fonts.noarch 」 に含まれる /usr/share/fonts/ipa-mincho/ipam.ttf、ゴシック体は「vlgothic-fonts」 に含まれる /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf を使っているようだ。


2022/07/10追記

最小インストールのOracle Linux 8でブラウザを動かす場合FirefoxとChromeのどっちが容量少ないか」 で検証した結果を踏まえると、RHEL8の標準状態で使えるフォントは「google-noto-cjk-fonts-common google-noto-sans-cjk-ttc-fonts google-noto-serif-cjk-ttc-fonts」になるんじゃないかと思われる。

もしくはEPELレポジトリを追加して、「vlgothic-fonts vlgothic-p-fonts」

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上にも登録できた