NetAppのperfstatデータ収集ツールで取得したファイルを分解する

現用のNetAppの状況確認をするために「perfstatデータ収集ツール」というのが配布されている。
注:ONTAP 9.5以降はperfstatは非対応とのこと

rsh/sshで対象のNetAppにログインして、いろんなコマンドを実行して、1つのテキストファイルとして出力をする。

この「1つのテキストファイル」というのがくせ者で、200MBぐらいのファイルができたりする。

これだとエディタで取り扱いづらいので細かく分割することにした。

中をみてみると「=-=-=-=-=-= CONFIG IPアドレス PRESTATS =-=-=-=-=-= aggr status -v」という感じで「 =-=-=-=-=-= 」区切りでファイルが出力されている。

それを元にファイルを分割したのが下記スクリプト。

$inputfile="x:\tmp\source\perfstat7_20191122_1400.txt"
$outdir="x:\tmp\output"

$filename=""

Get-Content $inputfile -Encoding UTF8 | ForEach-Object {
    $line=$_
    if( $line.Contains("=-=-=-=-=-=") ){
        $filename=$line
        $filename=$filename.Replace("=-=-=-=-=-= ","")
        $filename=$filename.Replace("/","-")
        $filename=$filename.Replace(":","")
        $filename=$outdir+"\"+$filename+".txt"
        New-Item $filename
    }
    if($filename -ne ""){
        $line | Add-Content $filename
    }
}

今回は1回しか実行しないので速度を気にする必要がないので簡単さを優先している。

もし、出力速度を気にするのであれば1行毎にAdd-Contentするのは非常に効率が悪いので工夫が必要となる。

参考例:「PowerShellで巨大なファイルをGet-Contentし、Export-Csvするのを省メモリで行う


2019/11/25 追記

上記のスクリプトだと遅すぎで、約200MBのファイル処理に5時間かかりました。

やはり改行のみ行が数万行ある、というのが悪かったようです。

また、同じヘッダ行が何回か登場するようで単純に「New-Item」としているとファイル名が重複しているというエラーがでてしまっていました。

さすがに5時間はないなーということで、高速化処理をしたのが下記となります。

実行にかかる時間は2分と大幅短縮となりました。

$inputfile="x:\tmp\source\perfstat7_20191122_1400.txt"
$outdir="x:\tmp\output2"

$filename=""

$results=@()
$linecount=0

Get-Content $inputfile -Encoding UTF8 | ForEach-Object {
    $line=$_
    if( $line.Contains("=-=-=-=-=-=") ){
        if($filename -ne ""){
            $results | Add-Content $filename
            $results=@()
            $linecount=0
        }
        $filename=$line
        $filename=$filename.Replace("=-=-=-=-=-= ","")
        $filename=$filename.Replace("/","-")
        $filename=$filename.Replace(":","")
        $filename=$outdir+"\"+$filename+".txt"
        if ( !(Test-Path $filename) ){
            New-Item $filename
        }
    }

    if($filename -ne ""){
        $results += $line
        $linecount++
        if(($linecount % 1000) -eq 0 ){
            $results | Add-Content $filename
            $results=@()
        }
    }
}

samba 4.10.x環境で出てたsamba_dnsupdateのエラー対処

samba 4.10.7へアップデートしたあと、「systemctl status samba-ad-dc.service」で出力されるログを見てみたら、微妙な感じのエラーがあった。

 8月 29 08:54:02 adserver samba[107156]: [2019/08/29 08:54:02.287210,  0] ../../lib/util/util_runcmd.c:327(samba_runcmd_io_handler)
 8月 29 08:54:02 adserver samba[107156]:   /usr/local/samba/sbin/samba_dnsupdate: ImportError: No module named dns.resolver
 8月 29 08:54:02 adserver samba[107156]: [2019/08/29 08:54:02.295161,  0] ../../source4/dsdb/dns/dns_update.c:331(dnsupdate_nameupdate_done)
 8月 29 08:54:02 adserver samba[107156]:   dnsupdate_nameupdate_done: Failed DNS update with exit code 1
 8月 29 08:54:03 adserver winbindd[107159]: [2019/08/29 08:54:03.430795,  0] ../../source3/winbindd/winbindd_cache.c:3166(initialize_winbindd_cache)
 8月 29 08:54:03 adserver winbindd[107159]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
 8月 29 08:54:03 adserver smbd[107151]: [2019/08/29 08:54:03.438943,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
 8月 29 08:54:03 adserver smbd[107151]:   daemon_ready: daemon 'smbd' finished starting up and ready to serve connections
 8月 29 08:54:03 adserver winbindd[107159]: [2019/08/29 08:54:03.454411,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
 8月 29 08:54:03 adserver winbindd[107159]:   daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections

「samba_dnsupdate: ImportError: No module named dns.resolver」の対応

現状の確認方法

[root@adserver ~]# samba_dnsupdate --verbose
Traceback (most recent call last):
  File "/usr/local/samba/sbin/samba_dnsupdate", line 57, in <module>
    import dns.resolver
ImportError: No module named dns.resolver
[root@adserver ~]#

原因はpythonのDNS toolkitがインストールされていないこと。

CentOS7環境で対処するには「yum search dnspython」を実行してモジュール名を確認

[root@adserver ~]# yum search dnspython
読み込んだプラグイン:fastestmirror
Determining fastest mirrors
 * base: ftp.riken.jp
 * epel: ftp.riken.jp
 * extras: ftp.riken.jp
 * updates: ftp.riken.jp
=============================== 一致: dnspython ================================
python-dns.noarch : DNS toolkit for Python
python36-dns.noarch : DNS toolkit for Python 3
[root@adserver ~]#

今回使っている環境はpython 2環境なので、「yum install python-dns」でインストール。

[root@adserver ~]# yum install python-dns.noarch
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
epel/x86_64/metalink                                     | 7.3 kB     00:00
 * base: ftp.riken.jp
 * epel: ftp.riken.jp
 * extras: ftp.riken.jp
 * updates: ftp.riken.jp
base                                                     | 3.6 kB     00:00
epel                                                     | 5.4 kB     00:00
extras                                                   | 3.4 kB     00:00
packages-microsoft-com-prod                              | 2.9 kB     00:00
updates                                                  | 3.4 kB     00:00
(1/3): epel/x86_64/updateinfo                              | 998 kB   00:02
(2/3): packages-microsoft-com-prod/primary_db              | 200 kB   00:00
(3/3): epel/x86_64/primary_db                              | 6.8 MB   00:03
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ python-dns.noarch 0:1.12.0-4.20150617git465785f.el7 を インスト ール
--> 依存性解決を終了しました。

依存性を解決しました

================================================================================
 Package        アーキテクチャー
                           バージョン                            リポジトリー
                                                                           容量
================================================================================
インストール中:
 python-dns     noarch     1.12.0-4.20150617git465785f.el7       base     233 k

トランザクションの要約
================================================================================
インストール  1 パッケージ

総ダウンロード容量: 233 k
インストール容量: 1.0 M
Is this ok [y/d/N]: y
Downloading packages:
python-dns-1.12.0-4.20150617git465785f.el7.noarch.rpm      | 233 kB   00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  インストール中          : python-dns-1.12.0-4.20150617git465785f.el7.no   1/1
  検証中                  : python-dns-1.12.0-4.20150617git465785f.el7.no   1/1

インストール:
  python-dns.noarch 0:1.12.0-4.20150617git465785f.el7

完了しました!
[root@adserver ~]#

動作確認・・・

[root@adserver ~]# samba_dnsupdate --verbose
IPs: ['172.17.44.49']
Looking for DNS entry A adserver.adosakana.local 172.17.44.49 as adserver.adosakana.local.
Looking for DNS entry NS adosakana.local adserver.adosakana.local as adosakana.local
<略>
Checking 0 100 389 adserver.adosakana.local. against SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.adosakana.local adserver.adosakana.local 389
No DNS updates needed
[root@adserver ~]#

それ以外のログについて

samba_dnsupdateに関するエラーについて対処した後、sambaを再起動してログを見てみると、下記の様な感じになっていた。

 8月 29 09:06:46 adserver samba[107294]: [2019/08/29 09:06:46.991243,  0] ../../source4/smbd/server.c:773(binary_smbd_main)
 8月 29 09:06:46 adserver samba[107294]:   binary_smbd_main: samba: using 'standard' process model
 8月 29 09:06:47 adserver samba[107294]: [2019/08/29 09:06:47.021548,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
 8月 29 09:06:47 adserver samba[107294]:   daemon_ready: daemon 'samba' finished starting up and ready to serve connections
 8月 29 09:06:49 adserver winbindd[107312]: [2019/08/29 09:06:49.157089,  0] ../../source3/winbindd/winbindd_cache.c:3166(initialize_winbindd_cache)
 8月 29 09:06:49 adserver winbindd[107312]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
 8月 29 09:06:49 adserver winbindd[107312]: [2019/08/29 09:06:49.266323,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
 8月 29 09:06:49 adserver winbindd[107312]:   daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections
 8月 29 09:06:50 adserver smbd[107311]: [2019/08/29 09:06:50.436561,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
 8月 29 09:06:50 adserver smbd[107311]:   daemon_ready: daemon 'smbd' finished starting up and ready to serve connections

RHEL7だと上記出力を赤文字で出力してるけど、内容を見る限りではinformation的なものであるので、特に対処する必要はなさそうである。

NetBackupの操作をコマンドで行う

NetBackupのJava GUI(jnbSA)上で行う操作をCLIコマンドで行うためのメモ書き。

トラブル調査用コマンドについては→「NetBackupのトラブル調査とログ取り

アクティビティモニター

アクティビティモニターの一覧表示:bpdbjobs

アクティビティモニターの一覧は「bpdbjobs」をオプション無しで実行すると得られる。

フルパスは「/usr/openv/netbackup/bin/admincmd/bpdbjobs」

アクティビティモニターで各ジョブの詳細ログ確認:bpdbjobs -report -jobid 番号 -all_columns

各ジョブの詳細ログを確認する場合は「bpdbjobs -report -jobid 番号 -all_columns」となるのだが、これだと「,」区切りで1行に全てを出力してしまう。

人の目だと見にくいので「bpdbjobs -report -jobid 番号 -all_columns | sed s/,/,\n/ig」と実行すると、改行が入り多少見やすくなる。

テープドライブの操作

デバイスモニターの一覧表示:tpconfig -l か tpconfig -d

デバイスモニターで確認出来る各テープドライブのステータスは「tpconfig -l」か「tpconfig -d」で確認出来る。

「tpconfig -d」だとテープドライブのみの確認で、「tpconfig -l」だとロボット番号を含めて確認しやすい形となるので「tpconfig -l」の方を実行することをお勧めする。

フルパスは「/usr/openv/volmgr/bin/tpconfig」

ドライブステータスの変更:vmoprcmd -up ドライブ番号

状態が「DOWN(停止)」となっているテープドライブを「UP(有効)」にするには「vmoprcmd -up ドライブ番号」を実行する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/tpconfig -l
デバイスロボットドライブ       ロボット                    Drive                Device     Second
形式     番号 インデックス  形式 ドライブ番号 状態  Comment    Name                 Path       Device Path
ロボット      0    -    TLD    -       -  -          -                    /dev/sg3
  ドライブ    -    0 hcart2    1  停止  -          IBM.ULT3580-TD5.000  /dev/nst1
ロボット      1    -    TLD    -       -  -          -                    /dev/sg2
  ドライブ    -    1    dlt    1  停止  -          QUANTUM.SDLT600.000  /dev/nst0
[root@nbuserver ~]# /usr/openv/volmgr/bin/vmoprcmd -up 0
[root@nbuserver ~]# /usr/openv/volmgr/bin/vmoprcmd -up 1
[root@nbuserver ~]# /usr/openv/volmgr/bin/tpconfig -l
デバイスロボットドライブ       ロボット                    Drive                Device     Second
形式     番号 インデックス  形式 ドライブ番号 状態  Comment    Name                 Path       Device Path
ロボット      0    -    TLD    -       -  -          -                    /dev/sg3
  ドライブ    -    0 hcart2    1  有効  -          IBM.ULT3580-TD5.000  /dev/nst1
ロボット      1    -    TLD    -       -  -          -                    /dev/sg2
  ドライブ    -    1    dlt    1  有効  -          QUANTUM.SDLT600.000  /dev/nst0
[root@nbuserver ~]#

フルパスは「/usr/openv/volmgr/bin/vmoprcmd」

ロボットのインベントリ実行:vmupdate -rt tld -rn ロボット番号

ロボットに対してインベントリを実行するには「vmupdate -rt tld -rn ロボット番号」を実行します。

ロボット番号については「tpconfig -l」で確認します。

「-recommend」オプションをつけて実行すると「インベントリ操作-内容とボリュームの構成の比較」となります。

-recommendなしが「 インベントリ操作 -ボリューム構成の更新」になります。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0 -recommend
推奨された変更のリストを生成しています...

次のように、ボリュームの構成を更新します。
=====================================================
ボリュームの構成は、ロボット内と同じ最新の状態です。
[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0
推奨された変更のリストを生成しています...

次のように、ボリュームの構成を更新します。
=====================================================
ボリュームの構成は、ロボット内と同じ最新の状態です。
[root@nbuserver ~]#

ロボットの中のテープ一覧を表示:vmquery -b -rn ロボット番号

ロボット上で認識されているテープメディアを確認するには「vmquery -b -rn ロボット番号」を実行します。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -rn 0
メディメディロボッ  ロボッロボット 側面/ 光         # マウント/  最終
アID   ア形式 ト形式  ト#    スロット 断面  パートナークリーニングマウント時間
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          23     2019/06/03 16:59
O501L5  HCART2 TLD      0       2     -       -           5     2019/06/03 17:10
O502L5  HCART2 TLD      0       3     -       -           6     2019/06/03 15:26
O503L5  HCART2 TLD      0       4     -       -           1     2019/05/21 17:51
O504L5  HCART2 TLD      0       5     -       -          13     2019/06/03 11:24
[root@nbuserver ~]#

テープのQuick Erase:bplabel

NetBackupで記録したテープメディア内の登録を削除する場合「bplabel」コマンドを実行します。

ただ、有効期限が切れていないメディアに対しては実行できません。

その場合は「bpexpdate -d 0 -m メディアID」コマンドを実行して有効期限を切ってから、bplabelを実行する形となります。

[root@nbuserver logs]# /usr/openv/netbackup/bin/admincmd/bplabel -m O501L5 -d hcart2 -erase
メディアが割り当てられていますが、ラベルが付けられません
[root@nbuserver logs]# /usr/openv/netbackup/bin/admincmd/bpexpdate -d 0 -m O501L5
メディア O501L5 が 2019/06/04 17:47:09 で期限切れになります
このメディアのデータは本当に業務に必要ではありませんか
、 O501L5 を本当に削除しますか y/n(n)? y
[root@nbuserver logs]# /usr/openv/netbackup/bin/admincmd/bplabel -m O501L5 -d hcart2 -erase
メディアはすでに NetBackup 形式です。メディア ID = O501L5。消去 を実行しますか? y/n (n) y
消去が完了しました。
[root@nbuserver logs]#

なお、「-erase」がQuick Eraseで「-erase -l」がLong Eraseとなります。

リストア操作を手動で実施する場合

その1:使用可能なバックアップの捜索

「bpimmedia -client クライアント名」もしくは「bpimmedia -client クライアント名 -U」で指定したクライアントに関するバックアップIDを一覧化する。

-Uオプションの方が人が見やすい形となるが、sort/grepで抜き出す場合は-Uなしで実行した方が良い。

その2:リストアしたいバックアップデータを含む「バックアップ時刻」を確認

「bpimagelist -backupid バックアップID -U」を実行し、該当するバックアップIDの「バックアップ時刻」を取得。

この「バックアップ時刻」の文字列をこの後で使う。

その3:該当するバックアップに含まれるファイルを確認

UNIX系(Standard形式)クライアントの場合は「-t 0」なので「bplist -C クライアント名 -t 0 -s バックアップ時刻 -l -R /」

Windows(MS-Windows形式)クライアントの場合は「-t 13」なので 「bplist -C クライアント名 -t 13 -s バックアップ時刻 -l -R /」

なお、選択したバックアップ時刻が最新のバックアップでない場合は「-e バックアップ時刻」を追加し、データを限定する。

[root@nbuserver ~]#  /usr/openv/netbackup/bin/bplist -C nbuwindows -t 13 -s 2019/04/24 09:11 -l /C/Users/Administrator/Documents/test.txt
-rwx------ root;Admi root;None          32  4月 10日 19:47 /C/Users/Administrator/Documents/test.txt
[root@nbuserver ~]#

その4:リストアしたいファイルを選択

リストアしたいファイルの選択は、テキストファイル内にフルパスを記載することで行う。

先ほどのbplistの出力結果に記載されているパスを使用する。

Windowsの場合、「\」は使用できず「/」で代替するため「C:\Users\」が「/C/Users/」という風になる。

[root@nbuserver ~]# cat /tmp/list.txt
/C/Users/Administrator/Documents/test.txt
[root@nbuserver ~]#

その5:リストア先を変更する場合は、変更する規則を記載

リストア先のディレクトリを変更したい場合、変更する規則をテキストファイル内に記載します。

たとえば「C:\Users\Administrator\Documents\」を「C:\tmp\」に変えたい場合は下記の様に記載します。

[root@nbuserver ~]# cat /tmp/change.txt
change /C/Users/Administrator/Documents/ to /C/tmp/
[root@nbuserver ~]#

「change 元パス to 変更後パス」という書式で、複数の変更がある場合は、それぞれ列挙します。

その6:リストアを実行

bprestoreコマンドでリストアを実行します。

バックアップを取得したクライアントとは別のクライアントにリストアしたい場合は「-D 宛先クライアント」を指定します。

Windows(MS-Windows形式)の場合、「/usr/openv/netbackup/bin/bprestore -C クライアント名 -t 13 -s <バックアップ時刻> -D 宛先クライアント -R 変更規則ファイル -f リストア対象ファイル 」といったように実行します。

NetBackupで他のNetBackupサーバから持ってきたテープメディア内のデータをリストアする

NetBackupサーバでバックアップに使用していたテープメディアを他のNetBackup環境に持ってきて、その中のデータをリストアしようとした場合に必要となるコマンドライン操作(CLI操作)について。

なお、インベントリとリストア以外のGUI操作はあるのかどうか知らない。

その1 現状のメディア認識状況などの確認

いまのメディア認識状態を確認するために現在のメディア認識状況確認「/usr/openv/volmgr/bin/vmquery -b -a」を実行してメディアがどういう認識状態か確認

[root@nbuserver ~]#  /usr/openv/volmgr/bin/vmquery -b -a
メディメディロボッ  ロボッロボット 側面/ 光         # マウント/  最終
アID   ア形式 ト形式  ト#    スロット 断面  パートナークリーニングマウント時間
-------------------------------------------------------------------------------
O500L5  HCART2 NONE     -      -     -       -          15     2019/04/19 00:00
O501L5  HCART2 NONE     -      -     -       -           2     2019/05/21 17:47
O502L5  HCART2 NONE     -      -     -       -           1     2019/05/21 17:48
O503L5  HCART2 NONE     -      -     -       -           1     2019/05/21 17:51
O504L5  HCART2 NONE     -      -     -       -          11     2019/05/21 17:54
[root@nbuserver ~]#

また、今回持ってくるテープは「O500L5」なのだが、その中に登録されている情報があるのかを「/usr/openv/netbackup/bin/admincmd/bpimmedia -mediaid O500L5 -U」を実行して確認する。

[root@nbuserver ~]# /usr/openv/netbackup/bin/admincmd/bpimmedia -mediaid O500L5 -U
エンティティが見つかりませんでした
[root@nbuserver ~]#

上記の様に「エンティティが見つかりませんでした」と出力される場合は、そのメディアの既存の登録がない状態。

その2 インベントリ実施

「/usr/openv/volmgr/bin/vmupdate -rt ロボットタイプ -rn ロボット番号」(/usr/openv/volmgr/bin/vmupdate -rt tld -rn 0)を実行して、インベントリ更新を行う。

実行後、vmqueryコマンドで該当するテープメディアについてロボット番号とスロット番号が認識されたことを確認する。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmupdate -rt tld -rn 0
推奨された変更のリストを生成しています...

次のように、ボリュームの構成を更新します。
=====================================================
メディア ID O500L5 (バーコード LTO500L5) を、スタンドアロンからスロット 1 に論理的に移動します。
メディア ID O501L5 (バーコード LTO501L5) を、スタンドアロンからスロット 2 に論理的に移動します。
メディア ID O502L5 (バーコード LTO502L5) を、スタンドアロンからスロット 3 に論理的に移動します。
メディア ID O503L5 (バーコード LTO503L5) を、スタンドアロンからスロット 4 に論理的に移動します。
メディア ID O504L5 (バーコード LTO504L5) を、スタンドアロンからスロット 5 に論理的に移動します。
ボリュームの構成を更新しています...

次のとおり論理的にメディアを移動することによって、ロボットライブラリに追加、
またはロボットライブラリ内で移動された既存のメディアを処理しています...
        メディア ID     スロット
        ==========      =======
         O500L5            1
         O501L5            2
         O502L5            3
         O503L5            4
         O504L5            5


ボリュームの構成が正常に更新されました。

[root@nbuserver ~]# /usr/openv/volmgr/bin/vmquery -b -a
メディメディロボッ  ロボッロボット 側面/ 光         # マウント/  最終
アID   ア形式 ト形式  ト#    スロット 断面  パートナークリーニングマウント時間
-------------------------------------------------------------------------------
O500L5  HCART2 TLD      0       1     -       -          15     2019/04/19 00:00
O501L5  HCART2 TLD      0       2     -       -           2     2019/05/21 17:47
O502L5  HCART2 TLD      0       3     -       -           1     2019/05/21 17:48
O503L5  HCART2 TLD      0       4     -       -           1     2019/05/21 17:51
O504L5  HCART2 TLD      0       5     -       -          11     2019/05/21 17:54
[root@nbuserver ~]#

その3 該当するメディアのメディアDB作成

該当するメディアについて、メディアDBを作成します。

「/usr/openv/netbackup/bin/admincmd/bpimport -create_db_info -id O500L5 -v」と実行します。

[root@nbuserver ~]# /usr/openv/netbackup/bin/admincmd/bpimport -create_db_info -id O500L5 -v
インポートフェーズ 1 を開始しました: 2019/05/21 18:43:30
INF - メディア ID O500L5 のデータベース情報を作成してください。
INF - メディア ID O500L5 のフェーズ 1 インポートを実行する bptm プロセスを正常に開始しました。
[root@nbuserver ~]#

その4 メディアの読み込みを実施

指定したメディアをテープドライブで読み込み、中身をスキャンします。

コマンドはその3から-create_db_infoを抜いた「/usr/openv/netbackup/bin/admincmd/bpimport -id O500L5 -v」となります。

[root@nbuserver ~]# /usr/openv/netbackup/bin/admincmd/bpimport -id O500L5 -v
インポートフェーズ 2 を開始しました: 2019/05/21 18:43:58
INF - ポリシー localbackup、スケジュール Full (oldserver_1554890341)、メディア ID O500L5、作成日時 2019/04/10 18:59:01 をインポートしています。
INF - INDEX ファイル情報のみを読み込んでインポートしています。
INF - クライアント oldserver、バックアップ ID oldserver_1554890341 のイメージを検証しています。

INF - ポリシー localbackup、スケジュール Full (oldserver_1554890341) のインポートは正常に完了しました。

INF - ポリシー localbackup、スケジュール Full (oldserver_1554890468)、メディア ID O500L5、作成日時 2019/04/10 19:01:08 をインポートしています。
INF - ポリシー localbackup、スケジュール Full (oldserver_1554890468) のインポートは正常に完了しました。

<略>


INF - ポリシー localbackup、スケジュール Full (oldserver_1558430463)、メディア ID O500L5、作成日時 2019/05/21 18:21:03 をインポートしています。
INF - ポリシー localbackup、スケジュール Full (oldserver_1558430463) のインポートは正常に完了しました。

INF - 20 イメージ (20 イメージ中) をインポートしました。インポートは成功しました。

[root@nbuserver ~]#

その5 スキャンした内容が登録されていることを確認

先ほどは「エンティティが見つかりませんでした」となった「/usr/openv/netbackup/bin/admincmd/bpimmedia -mediaid O500L5 -U」を再度実行します。

以下の様にbpimportで表示されたバックアップIDが出力されます。

[root@nbuserver ~]#  /usr/openv/netbackup/bin/admincmd/bpimmedia -mediaid O500L5 -U
--------------------------------------------------------------------------------
バックアップ ID: oldserver_1558430463
 ポリシー:        localbackup
 スケジュール形式: FULL
 保持レベル      1
 ファイルの数:  4788
 圧縮:              N
 暗号化:           N
 イメージ形式:  インポート済
 ー・チー﨣芦ミール・ 1
 有効期限:        2019年06月04日 18時44分39秒
 保留中のイメージ: 0

  コピー数:       1
  フラグメント数: 1
  フラグメントサイズ (KB): 263680
  メディア形式: リムーバブル
  コ・クO             hcart2
  ファイル数:    22
  オフセット:    5382
  ホスト:          nbuserver
  書き込みに使用されたデバイス: -1
  MPX:                N
  有効期限:       2019年06月04日 18時44分39秒
  保持レベル:                                 1
  メディア ID:    O500L5
  保留中のコピー: 0
--------------------------------------------------------------------------------

<略>

--------------------------------------------------------------------------------
バックアップ ID: oldserver_1558430463
 ポリシー:        localbackup
 スケジュール形式: FULL
 保持レベル      1
 ファイルの数:  4788
 圧縮:              N
 暗号化:           N
 イメージ形式:  インポート済
 ー・チー﨣芦ミール・ 1
 有効期限:        2019年06月04日 18時44分39秒
 保留中のイメージ: 0

  コピー数:       1
  フラグメント数: 1
  フラグメントサイズ (KB): 263680
  メディア形式: リムーバブル
  コ・クO             hcart2
  ファイル数:    22
  オフセット:    5382
  ホスト:          nbuserver
  書き込みに使用されたデバイス: -1
  MPX:                N
  有効期限:       2019年06月04日 18時44分39秒
  保持レベル:                                 1
  メディア ID:    O500L5
  保留中のコピー: 0
[root@nbuserver ~]#


その6 リストアする

NetBackupの通常のリストア手法でリストアします。

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再頒布可能パッケージがインストールされていない場合に、リモートインストールが失敗することもある模様。

11.20など古い環境では再頒布可能パッケージのインストール検出がうまく動いてないことが原因のようなのだが、エラーメッセージ上は「WMIの設定」としか言ってこないので状況がわからないようになっていた。

再頒布可能パッケージをあらかじめインストールしておくか、クライアント側でcommvault setup.exeを実行するしかないようだ。


2021/09/03追記

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