Surveillance Bridgeを設定済みのシステムにおいてVMSのGUIにてアーカイブを削除した場合、Surveillance Bridge内に設定情報が残る場合があります。通常、この情報が残っていても支障をきたすことがないのですが、極稀にDisaster Recoveryのリカバ動作がうまくいかない場合があります。
このような現象を引き起こさないようにするためにVMSのGUIにてArchiveを削除した後に以下に説明をする処理をしていただくことを推奨します。
この記事の中では作業の内容に必要な情報を提供するために①VMSのGUI、②Tiger Surveillance社提供のCLIツール「tiercli」、③Windowsのレジストリキーについて並べて説明をしていきます。以下この①②③を総称して3つのツールと呼びます。
説明する環境
以下の環境で今回の説明の挙動、表示を取得しました。
- Windows Server 2019 Standard
- Milestone Systems XProtect Corporate 2024R1
- Surveillance Bridge Version 2.3.0.172
使用する3つのツールについて
Surveillance Bridge（以下SBとします）の通常の設定はVMSのGUIによって行えます。
Tiger Surveillance社が提供するコマンドラインツール「tiercli」はSBの設定の表示、変更ができます。（tiercliの詳細の使い方はブログ記事「tiercliを使ってみる」を参照してください。）今回はVMSのGUIで表示されない、内部の状態の観察とWindowsレジストリキーの設定変更後の設定読込のために「tiercli」を使用します。
WindowsレジストリキーVMSのGUIでRecording Serverで削除し、存在しなくなったストレージの情報を削除するために使用します。編集をするのは以下の2か所です。
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Tiger Technology\tiger-bridge\tiersvc\settings\sources
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Tiger Technology\tiger-bridge\tiersvc\settings\destinations
最初にStorageを一つだけ実装した場合の3つのツールの表示を以下に示します。
VMS GUI
tiercliで設定を表示する際には「tiercli config show」を使用します。下図は「tiercli config show」を実行した結果です。上記のVMS GUIと同一でEドライブのStorageAがSourceでFドライブのTargetAがTargetになっているのがわかります。
下図はWindowsレジストリキーの画像です。
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Tiger Technology\tiger-bridge\tiersvc\settings\sourcesが選択されています。destinationsもsorcesの配下に一つずつのオブジェクトがあることがわかります。destinationsの配下には”1″がsourcesの配下には”B0AEA769853B844CA6ECB38C2DAFD1D7″あります。
後で詳しく説明しますが、現在はdestinationsとsourcesの配下にそれぞれ１つずつキーがあることを認識しておいてください。
2つのStorageがある場合
VMS GUIの表示です。StorageBとTargetBが2つ目のStorageとして表示されています。
この時の「tiercli」の表示が以下です。StorageAとStorageBの２つのsourceあることがわかります。
同様にこの時のWindowsレジストリキーの画面を見ると下図のようになります。前項のStorageが一つの時はdestinationsの下のキーは”1″だけでしたが2つ目のStorageに対応する”2″が追加されています。sourcesの下も”0783E961D5E2404FAF501C45D8663E25″が追加されています、これも２つめのStorageに対応しています。
上図の状態ではSourceとDestinationの関係がわかりません。この関係を知るためにSource側のキーの一つを展開します。
キー”B0AEA769853B844CA6ECB38C2DAFD1D7″を展開し、その下の”1″を選択します。その左側の内容を見るとその中にdest_id(選択している場所)があり、そのデータは”1″になっています。この”1″はdestinationsは以下のキー”1″に対応しています。
もう一つのキー”0783E961D5E2404FAF501C45D8663E25″を展開して同様にdest_idを見るとそのデータは”2″になっています。この”2″はdestinationsは以下のキー”2″に対応しています。
また、同じ画面でdas_dirのデータを見るとそれぞれF:¥TargetA（上図）とF:¥TargetB（下図）であることがわかります。このことからもdestinations\1がStorageA、destinations\2がStorageBに対応していることがわかると思います。
Storage削除後の処理
上記の確認の後、VMSのGUIでRecording ServerのStorageBを削除します。
当然の結果ですが、Management ClientのDisaster Recoveryの表示は以下のように１つのStorage（StorageAのみ）になっています。
この状態で「tiercli」とWindowsレジストリキーの状態を観察すると以下のようにStorageBに対応する設定は残ったままです。
残ったStorageBの設定はWindowsレジストリキーの編集で削除します。
前項で説明していますが、destinationsとsources配下のStorageBに相当するキーをマウスの右ボタンで削除を選んで削除をします。
重要：Windowsレジストリの編集は間違えると動作に影響する場合もあるので、レジストリエディタのエクスポート機能を利用してバックアップを取っておくことをお勧めします。Windowsレジストリキーの編集方法、バックアップ、リストア方法はMicrosoftを含む多くのサイトで説明しているのでそちらを参照してください。その他テスト環境を作ってそこで十分練習してから本番に臨むのも良いと思います。
Storage Bに相当する設定はsources配下ではキー”0783E961D5E2404FAF501C45D8663E25″で、destinations配下では”2″です。下図はキー”0783E961D5E2404FAF501C45D8663E25″を削除しようとしている画面キャプチャです。
sources配下のキー”0783E961D5E2404FAF501C45D8663E25″とdestinations配下の”2″を消した後に「tiercli」で「tiercli config reload」を実行して削除作業は終了です。
下図は2つのキー削除後に「tiercli config reload」を行い、「tierclie config reload」を実行した結果です。StorageBに関する設定が消えていることがわかります。
