NetBackup™ Snapshot Manager インストールおよびアップグレードガイド

NetBackup Snapshot Manager エージェントホストが突然再起動された場合、このエージェントが NetBackup Snapshot Manager サーバーへの接続に失敗する。

この問題は、NetBackup Snapshot Manager エージェントがインストールされているホストが突然停止した場合に発生することがあります。ホストが正常に再起動した後でも、エージェントは NetBackup Snapshot Manager サーバーとの接続の確立に失敗し、オフライン状態になります。

エージェントログファイルには、次のエラーが記録されます。

Flexsnap-agent-onhost[4972] mainthread flexsnap.connectors.rabbitmq: error - channel 1 closed unexpectedly: (405) resource_locked - cannot obtain exclusive access to locked queue ' flexsnap-agent.a1f2ac945cd844e393c9876f347bd817' in vhost '/'

この問題は、エージェントホストが突然シャットダウンされた場合でも、エージェントと NetBackup Snapshot Manager サーバー間の RabbitMQ 接続が終了していないために発生します。エージェントホストでハートビートポーリングが失われるまで、NetBackup Snapshot Manager サーバーはそのエージェントを利用できないことを検出できません。RabbitMQ 接続は、次のハートビートサイクルまで開いたままになります。次のハートビートポーリングがトリガされる前にエージェントホストが再ブートすると、エージェントは NetBackup Snapshot Manager サーバーとの新しい接続の確立を試行します。ただし、以前の RabbitMQ 接続がすでに存在するため、新しい接続の試行はリソースのロックエラーで失敗します。

この接続エラーが発生すると、エージェントはオフラインになり、ホストで実行されたすべてのスナップショット操作およびリストア操作が失敗します。

回避方法:

エージェントホストで Veritas NetBackup Snapshot Manager Agent サービスを再起動します。

Windows ホストでの NetBackup Snapshot Manager エージェント登録がタイムアウトまたは失敗することがある。

Windows でアプリケーションを保護するには、Windows ホストに NetBackup Snapshot Manager エージェントをインストールして登録する必要があります。エージェントの登録には、通常よりも時間がかかることがあります。また、タイムアウトまたは失敗することがあります。

回避方法:

この問題を回避するには、次の手順を試行します。

詳しくは、次を参照してください。

Windows ベースのエージェントの登録を参照してください。

NetBackup Snapshot Manager の再起動を参照してください。

DR パッケージが消失した場合、またはパスフレーズが失われた場合のディザスタリカバリ。

この問題は、DR パッケージが失われた場合、またはパスフレーズが失われた場合に発生する可能性があります。

カタログバックアップの場合、次の 2 つのバックアップパッケージが作成されます。

DR パッケージには NetBackup UUID 証明書が含まれ、カタログデータベースにも UUID があります。DR パッケージを使用してディザスタリカバリを実行し、その後にカタログリカバリを実行すると、UUID 証明書と UUID の両方がリストアされます。これにより、UUID が変更されないため、NetBackup は NetBackup Snapshot Manager と通信できるようになります。

ただし、DR パッケージまたはパスフレーズが失われた場合は、DR 操作を完了できません。NetBackup の再インストール後に、DR パッケージなしでのみカタログをリカバリできます。この場合、NetBackup Snapshot Manager で認識されない新しい UUID が NetBackup に対して作成されます。NetBackup と NetBackup Snapshot Manager との 1 対 1 のマッピングは失われます。

回避方法:

この問題を解決するには、NetBackup プライマリが作成された後で新しい NBU UUID とバージョン番号を更新する必要があります。

NBU UUID とバージョン番号を取得した後、NetBackup Snapshot Manager ホストで次のコマンドを実行してマッピングを更新します。

/cloudpoint/scripts/cp_update_nbuuid.sh -i <NBU UUID> -v <Version Number>

マスターサーバーで ECA_CRL_CHECK が無効な場合、スナップショットジョブは成功するが、バックアップジョブがエラー「NetBackup Snapshot Manager の証明書が無効か存在しません。(The NetBackup Snapshot Managers certificate is not valid or doesn't exist.) (9866)」で失敗する。

ECA_CRL_CHECK がマスターサーバーで構成され、無効になっている場合は、NetBackup Snapshot Manager の bp.conf セットアップでも同じ値を使用して構成する必要があります。

たとえば、NetBackup で外部証明書が構成されており、証明書が失効している場合に、スナップショットからバックアップを実行するシナリオがあるとします。この場合、マスターで ECA_CRL_CHECK が DISABLE に設定されているときは、NetBackup Snapshot Manager 設定の bp.conf でも同じ値を設定します。そうしないと、スナップショット操作は成功しても、バックアップ操作は証明書エラーで失敗します。

Azure Stack のセキュリティの構成 を参照してください。

Windows クラウドインスタンスに対するエージェントレスを使用した接続の確立が NetBackup Snapshot Manager で失敗する

エラー 1: <Instance_name>: network connection timed out.

ケース 1: NetBackup Snapshot Manager サーバーのログメッセージ:

WARNING - Cannot connect to the remote host. SMB Connection timeout
 <IP address> <user>

…

flexsnap.OperationFailed: Could not connect to the remote server 
<IP address>

回避方法:

この問題を回避するには、次の手順を試行します。

ケース 2: NetBackup Snapshot Manager ログメッセージ:

WARNING - Cannot connect to the remote host. WMI Connection 
timeout <IP address> <user>

…

flexsnap.OperationFailed: Could not connect to the remote 
server <IP address>

回避方法:

この問題を回避するには、次の手順を試行します。

ケース 3: NetBackup Snapshot Manager ログメッセージ:

Exception while opening SMB connection, [Errno Connection error 
(<IP address>:445)] [Errno 113] No route to host.

回避方法: クラウドインスタンスが起動して実行中であるか、不整合な状態になっていないことを確認します。

ケース 4: NetBackup Snapshot Manager ログメッセージ:

Error when closing dcom connection: 'Thread-xxxx'"

ここで、xxxx はスレッド番号です。

回避方法:

この問題を回避するには、次の手順を試行します。

エラー 2: <Instance_name>: Could not connect to the virtual machine.

NetBackup Snapshot Manager ログメッセージ:

Error: Cannot connect to the remote host. <IP address> Access denied. 

回避方法:

この問題を回避するには、次の手順を試行します。

ファイアウォールが無効な場合、RHEL システムで NetBackup Snapshot Manager のクラウド操作が失敗する

NetBackup Snapshot Manager サービスの実行中に RHEL システムでファイアウォールが無効になっている場合、RHEL システムでサポートされるすべてのクラウドプラグインで NetBackup Snapshot Manager 操作が失敗します。これはネットワーク構成の問題で、NetBackup Snapshot Manager がクラウドプロバイダの REST API エンドポイントにアクセスできないようにします。

回避方法:

スナップショットジョブとインデックス付けジョブからのバックアップがエラーで失敗する

Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) SSL
Connection failed with string, broker:<hostname>
Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) Failed SSL
handshake, broker:<hostname>
Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Invalid
operation for asset: <asset_id>
Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Acknowledgement
not received for datamover <datamover_id>

および/または

Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client
<asset_id>: FTL - Cannot retrieve the exported snapshot details
for the disk with UUID:<disk_asset_id>
Jun 10, 2021 3:06:13 PM - Info bptm (pid=32582) waited for full
buffer 1 times, delayed 220 times
Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client
<asset_id>: FTL - cleanup() failed, status 6

これは、ポート 5671 および 443 での NetBackup Snapshot Manager へのインバウンドアクセスが OS ファイアウォールレベル (firewalld) でブロックされた場合に発生する可能性があります。それにより、(スナップショットおよびインデックス付けジョブからのバックアップに使用される) datamover コンテナから、NetBackup Snapshot Manager への通信が遮断されます。その結果、datamover コンテナはバックアップまたはインデックス付けを開始できません。

回避方法:

OS ファイアウォールのルールを変更して、ポート 5671 および 443 からのインバウンド接続を許可します。

VM のエージェントレス接続が失敗し、エラーメッセージが表示される。

ユーザーが、ポータルを介して VM の認証形式を SSH キーベースからパスワードベースに変更すると、VM のエージェントレス接続が失敗し、次のエラーメッセージが表示されます。

User does not have the required privileges to establish an 
agentless connection

このエラーメッセージが示すように、この問題は sudoers ファイルでユーザーの権限が正しく定義されていない場合に発生します。

回避方法:

パスワードレスの sudo 操作を実行するために必要な権限を指定することで、ユーザーの sudoers ファイルの問題を解決します。

プライベートサブネット (インターネットなし) に NetBackup Snapshot Manager を配備すると、NetBackup Snapshot Manager 機能が失敗する

この問題は、ファイアウォールが有効になっているプライベートネットワークまたは無効なパブリック IP に NetBackup Snapshot Manager が配備されている場合に発生します。顧客の情報セキュリティチームでは、仮想マシンへのフルインターネットアクセスが許可されない場合があります。

回避方法:

次のコマンドを使用して、ファイアウォールのコマンドラインからポートを有効にします。

firewall-cmd --add-port=22/tcp

firewall-cmd --add-port=5671/tcp

firewall-cmd --add-port=443/tcp

バックアップコピーからの資産のリストアが失敗する

一部のシナリオでは、Docker コンテナで接続が断続的にリセットされる場合があります。このため、サーバーは、アドバタイズされたクライアントウィンドウよりも多い tcp ペイロードを送信します。Docker コンテナは、新しい TCP 接続ハンドシェークからの SYN+ACK パケットをドロップする場合があります。これらのパケットを許可するには、nf_conntrack_tcp_be_liberal オプションを使用します。

nf_conntrack_tcp_be_liberal = 1 の場合、次のパケットが許可されます。

nf_conntrack_tcp_be_liberal = 0 の場合、これらも無効として拒否されます。

回避方法:

バックアップコピーからのリストアの問題を解決するには、nf_conntrack_tcp_be_liberal = 1 オプションを使用して、datamover コンテナを実行中のノードでこの値を設定します。

nf_conntrack_tcp_be_liberal の値を設定するには、次のコマンドを使用します。

sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1

Kubernetes 拡張機能の一部のポッドが完了状態に進んだ

回避方法:

Kubernetes 拡張機能を無効にします。

次のコマンドを使用してリスナーポッドを削除します。

#kubectl delete pod flexnsap-listener-xxxxx -n <namespace>

Kubernetes 拡張機能を有効にします。

ユーザーがクラウド保護計画をカスタマイズできない

回避方法:

目的の構成を使用して新しい保護計画を作成し、資産に割り当てます。

Podman コンテナが起動しない、または再ブート後もコンテナが起動しない

RHEL 8.x プラットフォームでコンテナを再起動またはマシンを再ブートすると、コンテナに次のエラーメッセージが表示されます。

# podman restart flexsnap-coordinator 47ca97002e53de808cb8d0526ae033d4b317d5386ce085a8bce4cd434264afdf:
 "2022-02-05T04:53:42.265084989+00:00 Feb 05 04:53:42 flexsnap-coordinator flexsnap-coordinator[7] 
agent_container_health_check flexsnap.container_manager: INFO - Response: b'{""cause"":""that name is already in use"",""message"":
""error creating container storage: the container name \\""flexsnap-agent.15bd0aea11164f7ba29e944115001d69\\"" is already in use by 
\\""30f031d586b1ab524511601aad521014380752fb127a9440de86a81b327b6777\\"". You have to remove that container to be able to reuse that
 name.: that name is already in use"",""response"":500}\n'"

回避方法:

/var/lib/cni/networks/flexsnap-network/ のファイルシステムの場所に、起動できなかったコンテナへの IP アドレスエントリマッピングを含むファイルがあるかどうかを確認します。

[ec2-user@ip-172-31-44-163 ~]$ ls -latr /var/lib/cni/networks/flexsnap-network/ total 16 -rwxr-x---. 1 root root 0 Jan 22 12:30 lock drwxr-xr-x. 4 root root 44 Jan 22 12:30 .. -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.150 -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.151 -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.152 -rw-r--r--. 1 root root 11 Feb 7 11:09 last_reserved_ip.0 drwxr-xr-x. 2 root root 101 Feb 7 11:13 . [ec2-user@ip-172-31-44-163 ~]$

このディレクトリから、重複する IP アドレスファイルを削除し、次のように停止操作と起動操作を実行します。

コンテナを停止します: #podman stop <container_name>

コンテナを起動します: #podman start <container_name>

サービスの起動と停止を行っても、NetBackup Snapshot Manager、RabbitMQ、MongoDB のコンテナが起動状態のままになる

flexsnap-mongodb コンテナと flexsnap rabbitmq コンテナが健全な状態にならないことが確認されました。flexsnap-mongodb コンテナの状態を次に示します。

[ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .Config.Healthcheck}}'
flexsnap-mongodb {"Test":["CMD-SHELL","echo 'db.runCommand({ping: 1}).ok' 
| mongo --ssl --sslCAFile /cloudpoint/keys/cacert.pem 
--sslPEMKeyFile /cloudpoint/keys/mongodb.pem flexsnap-mongodb:27017/zenbrain --quiet"],
"Interval":60,"Timeout":30000000000,"Retries":3} [ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='
{{json .State.Healthcheck}}' flexsnap-mongodb {"Status":"starting","FailingStreak":0,"Log":null} [ec2-user@ip-172-31-23-60 log]$

回避方法:

次の #podman CLI コマンドを実行します。

[ec2-user@ip-172-31-23-60 log]$ sudo podman healthcheck run flexsnap-mongodb

[ec2-user@ip-172-31-23-60 log]$ sudo podman ps -a

CONTAINER ID   IMAGE                        COMMAND                         CREATED      STATUS                  PORTS                           NAMES

fe8cf001032b  localhost/veritas/   flexsnap-fluentd:10.0.0.0.9817         2 days ago    Up 45 hours ago      0.0.0.0:24224->24224/tcp        flexsnap-fluentd

2c00500c1ac6  localhost/veritas/   flexsnap-mongodb:10.0.0.0.9817         2 days ago    Up 45 hours ago (healthy)                            flexsnap-mongodb

7ab3e248024a  localhost/veritas/   flexsnap-rabbitmq:10.0.0.0.9817        2 days ago    Up 45 hours ago (starting)                           flexsnap-rabbitmq

[ec2-user@ip-172-31-23-60 log]$ sudo podman healthcheck run flexsnap-rabbitmq

[ec2-user@ip-172-31-23-60 log]$ sudo podman ps -a

CONTAINER ID   IMAGE                        COMMAND                        CREATED       STATUS                      PORTS                         NAMES

fe8cf001032b  localhost/veritas/    flexsnap-fluentd:10.0.0.0.9817        2 days ago    Up 45 hours ago          0.0.0.0:24224->24224/tcp     flexsnap-fluentd

2c00500c1ac6  localhost/veritas/    flexsnap-mongodb:10.0.0.0.9817        2 days ago    Up 45 hours ago (healthy)                             flexsnap-mongodb

7ab3e248024a  localhost/veritas/    flexsnap-rabbitmq:10.0.0.0.9817       2 days ago    Up 45 hours ago (healthy)                             flexsnap-rabbitmq

 [ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .State.Healthcheck}}' flexsnap-mongodb

{"Status":"healthy","FailingStreak":0,"Log":[{"Start":"2022-02-14T07:32:13.051150432Z","End":"2022-02-14T07:32:13.444636429Z","ExitCode":0,"Output":""}]}

[ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .State.Healthcheck}}' flexsnap-rabbitmq

{"Status":"healthy","FailingStreak":0,"Log":[{"Start":"2022-02-14T07:32:46.537804403Z","End":"2022-02-14T07:32:47.293695744Z","ExitCode":0,"Output":""}]}

[ec2-user@ip-172-31-23-60 log]$

NetBackup Snapshot Manager を NetBackup に登録するときに証明書の生成が失敗する

NetBackup Snapshot Manager リリース 9.1.2 以降、NetBackup 証明書の生成は、NetBackup Snapshot Manager の登録 API への登録と同期的に行われます。そのため、証明書の生成に失敗すると、NetBackup に NetBackup Snapshot Manager を登録するとき、つまり Web UI から NetBackup Snapshot Manager エントリの追加や編集を行うときにエラーが発生します。これらの証明書は、スナップショットからのバックアップ、バックアップからのリストア、インデックス付け (VxMS ベース) などの操作のために起動される datamover に使用されます。そのため、証明書の生成に失敗すると、これらのジョブは実行できません。したがって、クラウド VM の NetBackup Snapshot Manager はラボ VM の NetBackup に接続できないため登録に失敗し、NetBackup Snapshot Manager を NetBackup に追加できません。

回避方法:

このようなシナリオで NetBackup Snapshot Manager を追加するには、/cloudpoint/flexsnap.conf ファイルに次のエントリを追加して、NetBackup Snapshot Manager での証明書の生成をスキップする必要があります。

[client_registration] skip_certificate_generation = yes

デフォルトの 6 時間のタイムアウトでは、大きいデータベース (サイズが 300 GB を超える) をリストアできない

回避方法:

より大きいデータベースをリストアできるように、構成可能なタイムアウトパラメータ値を設定できます。タイムアウト値は、flexsnap-coordinator コンテナの /etc/flexsnap.conf ファイルで指定できます。コーディネータコンテナの再起動は必要ありません。タイムアウト値は、次のデータベースリストアジョブで読み取られます。

ユーザーは、タイムアウト値を次のように秒単位で指定する必要があります。

docker exec -it flexsnap-coordinator bash root@flexsnap-coordinator:/# cat /etc/flexsnap.conf [global] target = flexsnap-rabbitmq grt_timeout = 39600

バックアップからリストアされた VM に 50 個のタグがアタッチされていると、リストアされたホストへのエージェントレス接続と個別リストアが失敗する

回避方法:

(AWS の場合) バックアップからリストアされた Windows VM に 50 個のタグがあり、プラットフォームタグがない場合、ユーザーは不要なタグを削除して Platform: windows タグを追加できます。

いくつかの GKE バージョンでは、失敗したポッドの問題が名前空間で発生する

名前空間では、次のようにいくつかの失敗したポッドが NodeAffinity というエラー状態で表示されます。

$ kubectl get pods -n <cp_extension_namespace>

NAME                                        READY     STATUS       RESTARTS     AGE
flexsnap-datamover-
2fc2967943ba4ded8ef653318107f49c-664tm        0/1     Terminating    0          4d14h
flexsnap-fluentd-collector-c88f8449c-5jkqh    0/1     NodeAffinity   0          3d15h
flexsnap-fluentd-collector-c88f8449c-ph8mx    0/1     NodeAffinity   0          39h
flexsnap-fluentd-collector-c88f8449c-rqw7w    1/1     Running        0          10h
flexsnap-fluentd-collector-c88f8449c-sswzr    0/1     NodeAffinity   0          5d18h
flexsnap-fluentd-ftlnv                        1/1     Running        3 (10h ago)10h
flexsnap-listener-84c66dd4b8-6l4zj            1/1     Running        0          10h
flexsnap-listener-84c66dd4b8-ls4nb            0/1     NodeAffinity   0          17h
flexsnap-listener-84c66dd4b8-x84q8            0/1     NodeAffinity   0          3d15h
flexsnap-listener-84c66dd4b8-z7d5m            0/1     NodeAffinity   0          5d18h
flexsnap-operator-6b7dd6c56c-cf4pc            1/1     Running        0          10h
flexsnap-operator-6b7dd6c56c-qjsbs            0/1     NodeAffinity   0          5d18h
flexsnap-operator-6b7dd6c56c-xcsgj            0/1     NodeAffinity   0          3d15h
flexsnap-operator-6b7dd6c56c-z86tc            0/1     NodeAffinity   0          39h

ただし、これらのエラーは、NetBackup Snapshot Manager Kubernetes 拡張機能の機能には影響しません。

回避方法:

次のコマンドを使用して、失敗したポッドを手動でクリーンアップします。

kubectl get pods -n <cp_extension_namespace> | grep NodeAffinity | awk '{print $1}' | xargs kubectl delete pod -n <cp_extension_namespace>

NetBackup Snapshot Manager 登録が以前に失敗している場合、プラグイン情報が重複する

これは、MarketPlace 配備メカニズムを使用して NetBackup Snapshot Manager が配備されている場合にのみ発生します。この問題は、登録前にプラグイン情報が追加されている場合に発生します。この問題により、CloudPoint_plugin.conf ファイルに、重複するプラグイン情報が作成されます。

回避方法:

重複したプラグイン情報を CloudPoint_plugin.conf ファイルから手動で削除します。

たとえば、CloudPoint_plugin.conf ファイルに GCP プラグイン構成の重複エントリ (太字) がある、次のような例を考えてみます。

{
    "CPServer1": [
      {
        "Plugin_ID": "test",
        "Plugin_Type": "aws",
        "Config_ID": "aws.8dda1bf5-5ead-4d05-912a-71bdc13f55c4",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  },
  {
    "CPServer2": [
      {
        "Plugin_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Type": "gcp",
        "Config_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
      {
        "Plugin_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Type": "gcp",
        "Config_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  }

NetBackup Snapshot Manager のクローンが NetBackup に追加されるとプラグイン情報が重複する

これは、NetBackup Snapshot Manager を RHEL 8.6 VM に移行するときに、NetBackup Snapshot Manager のクローンが NetBackup に追加された場合にのみ発生します。NetBackup Snapshot Manager のクローン作成では、既存の NetBackup Snapshot Manager ボリュームを使用して新しい NetBackup Snapshot Manager が作成されます。これにより、重複するエントリが CloudPoint_plugin.conf ファイルに作成されます。

回避方法:

重複したプラグイン情報を CloudPoint_plugin.conf ファイルから手動で編集および削除します。

たとえば、CloudPoint_plugin.conf ファイルに Azure プラグイン構成の重複エントリ (太字) がある、次のような例を考えてみます。

{
    "CPServer1": [
      {
        "Plugin_ID": "config10",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  },
  {
    "CPServer2": [
      {
        "Plugin_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
       {
    "cpserver101.yogesh.joshi2-dns-zone": [
      {
        "Plugin_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
      {
        "Plugin_ID": "AZURE_PLUGIN",
        "Plugin_Type": "azure",
        "Config_ID": "azure.4400a00a-8d2b-4985-854a-74f48cd4567e",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  }
 ]
}

Azure に配備された Snapshot Manager バージョン 10.0 を使用したスナップショット操作からのバックアップが、SSL 証明書エラーにより失敗する

Azure に配備された Snapshot Manager バージョン 10.2 を使用したスナップショット操作からのバックアップが、CRL (curl) に関連する SSL 証明書エラーにより失敗します。

回避方法:

Snapshot Manager bp.conf ファイルに ECA_CRL_CHECK = 0 を追加し、Azure エンドポイントがメディアサーバーからアクセスできることを確認します。