仮想スタンバイ(VSB)関連
- ローカル ディスクまたは共有フォルダにデータをバックアップした後、RPS セッションからアドホック VSB を実行できません。
- 解決策
- この問題を回避するには、復旧ポイント サーバ ビューからアドホック VSB ジョブをサブミットします。
- 以下の手順に従います。
- Arcserve UDP コンソールにログインします。
- [リソース] > [デスティネーション] > [復旧ポイント サーバ]に移動します。
- [デスティネーション: 復旧ポイント サーバ]ページで、復旧ポイント サーバを展開し、以下のいずれかを実行します。
- データ ストア名をクリックします。
- データ ストアを右クリックして、[復旧ポイントの参照]を選択します。
- [復旧ポイント]ページが開きます。
- アドホック VSB を実行するノードを右クリックして、[スタンバイ VM の作成]を選択します。
- アドホック VSB ジョブが成功します。
- エージェント ベースのバックアップ セッションの仮想スタンバイ ジョブで、アクティビティ ログに誤ったメッセージが表示されます。
- 解決策
- アクティビティ ログのメッセージは無視できます。
- 仮想スタンバイ プランの展開が失敗しました。
- ホスト ベースのエージェントレス バックアップ プランを作成した後、Nutanix に対する VSB のセカンダリ タスクを追加し、デスティネーションを Nutanix から GCP に変更すると、仮想スタンバイ プランの展開が以下のエラーで失敗します。
- 「仮想スタンバイ設定」をノード <パラメータ> へ適用できません。(仮想スタンバイ ジョブ スクリプトの保存に失敗しました。)
- 解決策
- この問題を回避するには、Nutanix に対する VSB セカンダリ タスクを完全に削除し、GCP に対する VSB タスクを再設定してから、仮想スタンバイ プランを展開します。
- VSB クラウド プロキシが Arcserve UDP コンソールに接続できません。
- GCP に対する VSB および AWS に対する VSB を実行するときに、Google Cloud/AWS に展開されている VSB クラウド プロキシを追加すると、ノードのステータスにエラーが示されて、以下のメッセージが表示されます。
- Arcserve UDP エージェントは Arcserve Unified Data Protection と通信できません。Arcserve UDP エージェントが現在の Arcserve Unified Data Protection に接続され、現在の Arcserve Unified Data Protection によって管理されていることを確認してください。
- 解決策
- このエラーは正常な動作なので無視してください。Arcserve UDP コンソールは、インターネットの外部(VSB クラウド プロキシ)からはアクセスできません。
- 注: ノードの更新やノードの削除などの操作は、上記のエラーに関係なく正常に動作します。
- GCP に対する VSB のときに JSON ファイルをアップロードできません。
- GCP に対する VSB の実行中に、JSON ファイルのアップロードが失敗し、以下のエラーが発生します。
- クラウド設定の処理中にエラーが発生しました。エラー: アクセスが拒否されました。認証情報を確認してください。
- C:\Program Files\Arcserve\Unified Data Protection\Management\logs\ARCAPP-Gateway.log にあるコンソール ログを確認してください。ログに以下のエラーがある場合、JSON のエラーは invalid_grant が原因です。
- 2024-05-23T11:25:03,257 (EdgeExecutors.cachedPoolForHandlingQueueMessageInGateway) pool-13-thread-5 [INFO] []Failed to connect to cloud.Error getting access token for service account: 400 Bad Request
- POST https://oauth2.googleapis.com/token
- {"error":"invalid_grant","error_description":"Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values in the JWT claim."}, iss: xxxx-xxx-serviceaccount@udpqa-gcp.iam.gserviceaccount.com
- 解決策
- ログに上記のエラーがある場合は、コンソール マシンのシステム クロックがインターネット/NTP の時刻と同期しているかどうかを確認してください。同期していない場合は、クロックがインターネット/NTP サーバと同期するように時刻を設定します。
- 時刻を設定するには、以下のいずれかを実行します。
- タイム ゾーンは正しいが、時刻がインターネット/NTP サーバと同期していない場合は、以下を行います。
- Windows OS で、システムの右下隅にある日付と時刻を右クリックします。
- [日付と時刻の調整]をクリックします。
- [日付と時刻]画面で、[今すぐ同期]をクリックします。
- クロックを NTP サーバと同期するには、コマンド プロンプトで w32tm /resync コマンドを実行します。このコマンドが失敗した場合は、time <インターネットと一致する正確な時刻> コマンドを使用して、時刻を手動で設定します。
- コンソール マシンが Active Directory の一部である場合は、ドメイン コントローラから時刻が更新されます。ドメイン コントローラ マシンのクロック/時刻がインターネット/NTP サーバと同期しているかどうかを確認します。同期していない場合は、ドメイン コントローラで時刻を更新し、コンソールで時刻を同期します。
- Google Cloud プロキシ(Google Compute Engine 仮想マシン)での Arcserve UDP エージェントのアンインストールが失敗する場合があります。
- Google Cloud プロキシ(Google Compute Engine 仮想マシン)で Arcserve UDP エージェントをアンインストールすると、ステータスが Failed で失敗する場合があります。
- 解決策
- この問題を回避するには、ページング ファイル サイズを Windows の推奨サイズに増やします。
- 以下の手順に従います。
- 以下のいずれかを実行します。
- [スタート] > [コントロール パネル] > [システムとセキュリティ] > [システム]をクリックします。
- デスクトップの[PC]アイコンを右クリックし、[プロパティ]を選択します。
- [関連設定]で、[システムの詳細設定]をクリックします。
- [システムのプロパティ]ダイアログ ボックスで、[詳細設定]タブをクリックし、[パフォーマンス]の[設定]をクリックします。
- [パフォーマンス オプション]ダイアログ ボックスで、[詳細設定]タブをクリックし、[仮想メモリ]の[変更]をクリックします。
- [仮想メモリ]ダイアログ ボックスで、[すべてのドライブのページング ファイルのサイズを自動的に管理する]チェック ボックスをオフにして、[カスタム サイズ]をクリックします。
- [初期サイズ(MB)]および[最大サイズ(MB)]を、[すべてのドライブの総ページング ファイル サイズ]ボックスにある Microsoft の推奨値に設定します。
- [設定]をクリックし、[OK]を 2 回クリックします。
- Google Cloud プロキシ サーバを再起動し、Arcserve UDP エージェントのアンインストール プロセスを再度開始します。
- 注: 新しい値を有効にするには、クラウド プロキシ サーバを再起動する必要があります。
- Arcserve UDP エージェントが正常にアンインストールされます。
- 仮想スタンバイによって Windows 11 VM のゲスト OS 情報が作成されると、vSphere 8.0 では Windows 10 として表示されます。
- 仮想スタンバイ タスクでの Virtual Private Cloud の変更は、Amazon EC2 に反映されません。
- 仮想スタンバイ タスクを実行した後、後続のタスクで異なる Amazon VPC を使用するために、仮想スタンバイ タスクのネットワーク設定で Virtual Private Cloud (VPC)を変更した場合、その変更は Amazon EC2 で更新されません。
- 解決策
- Amazon EC2 では、仮想スタンバイ タスクを少なくとも 1 回実行後した後に UDP コンソールから VPC を変更することはできません。この問題を回避するため、Arcserve UDP を使用して、古いインスタンスを終了させ、以前のセッションからの既存のデータを含む新しいインスタンスを作成できるようになりました。
- 以下の手順に従います。
- セカンダリ タスクとして、EC2 に対する VSB を含むバックアップ プランを設定します。
- 正常な AWS への VSB タスクをいくつか実行します。
- VSB タスク[ネットワーク設定]の VPC 設定を変更します。
- 更新された VPC 設定は、次回の VSB タスクが成功した後に、インスタンスに反映されます。
- 注:
- EC2 で作成された古いインスタンスは無視され、更新された VPC を持つ新しいインスタンスが EC2 に作成され、ネットワークの変更が反映されます。
- 新しいネットワーク設定は古いスナップショットにも反映されます。
- モニタ ノードに接続できず、VSB タスクがプランから削除された場合、VSB タスク環境設定を削除できません。
- VSB タスクを削除してプランを保存すると、プランが正常に展開されます。ただし、ジョブ スクリプトはソース ノードから削除されず、アクティビティ ログに次のメッセージが表示されます: モニタ xxx へのハートビート信号の送信に失敗しました。
- 解決策
- C:\Program Files\Arcserve\Unified Data Protection\Engine\Configuration\AFJobQueue フォルダからソース ノードのジョブ スクリプトを手動で削除してから、エージェント サービスを再起動します。
- モニタが 2 つの異なるコンソールによって管理されていた場合に、クラウド(Azure/EC2)に対する VSB プラン内のモニタからアクティビティ ログをコンソールに送信できませんでした。
- 現在のコンソールから関連する VSB アクティビティ ログの一部を表示できませんでした。
- 解決策
- モニタが 2 つのコンソールによって管理されている場合、最初にアクセスするコンソールによってログが収集されます。別のコンソールでログを表示できます。
- バックアップ先が共有フォルダのエージェントベース バックアップを使用した Nutanix に対する VSB のプランで、スタンバイ VM ページに復旧ポイントのリストを表示できませんでした。
- バックアップ先が共有フォルダのエージェントベース バックアップを作成した場合、VSB ジョブの完了後にスタンバイ VM ページに復旧ポイントを表示できません。
- 解決策
- 必要に応じて、Nutanix から直接スタンバイ VM を開始します。
- SAN (Storage Area Network)で設定された VMware ESX Server 環境では、アプリケーションは最初のフル バックアップ セッションのみを SAN を使用して ESX Server システムにコピーします。後続のすべてのフル バックアップおよび増分バックアップについては、変換されたバックアップ セッションは LAN を使用してコピーされます。アプリケーションのこの動作は、VMware の制限によるものです。詳細については、VMware Web サイトを参照してください。
- コンソールから VSB インスタンスを起動すると、正常に起動するにもかかわらず RDP 接続が失敗します。
- 現象
- 正常起動後に VSB インスタンスが起動に失敗します。システム ログには詳細が表示されません。
- 解決策
- AWS 中国リージョンで、EC2 ドライバがダウンロードされません。ドライバを手動でダウンロードする必要があります。
- 以下の手順に従います。
- ドライバをダウンロードするには、リンクをクリックしてください。
- zip ファイルを展開します。
- すべてのファイルをフォルダ C:\Program Files\Arcserve\Unified Data Protection\Engine\CloudDrivers\AmazonEC2 に配置します。
- 新しいバックアップを実行し、新しい VSB 起動可能スナップショットを作成します。
- VMware の制約により、仮想スタンバイでは、無償ライセンスを使用する ESXi Server システム上で仮想マシンを作成できません。仮想マシンを作成するには、ライセンスを購入する必要があります。
- VMware の既知の制限により、場所が英語以外のロケールに設定されると、アクティビティ ログに英語でエラーが書き込まれます。
- 最初のディスクにシステム ボリュームをインストールする場合、ソース マシンのシステム ボリュームと起動ボリュームが同じディスク上にあることを確認します。
- 注: この制限はクラウドへの VSB に対してのみ適用されます。
- データ ストアにバックアップ セッションがあり、[仮想スタンバイの再開]をクリックする場合、仮想スタンバイ ジョブが開始されません。
- 現象
- この問題を解決するには、手動のレプリケーションを最初に実行します。ノードを右クリックし、[今すぐレプリケート]をクリックします。レプリケーションが完了したら、仮想スタンバイ ジョブを再開します。
- ソース ノード上で Arcserve UDP RPS または Arcserve UDP エージェントを Arcserve UDP v6.5 にアップグレードした後、Hyper-V への仮想スタンバイ ジョブが失敗しました。
- 現象
- Arcserve UDP エージェント(Windows)は Arcserve UDP RPS データ ストアにバックアップされ、RPS は Arcserve UDP v6.5 にアップグレードされます。また、Arcserve UDP エージェント(Windows)は共有フォルダにバックアップされ、エージェントは Arcserve UDP v6.5 にアップグレードされます。Hyper-V に対する仮想スタンバイ VSB ジョブは失敗し、以下のいずれかのエラー メッセージが表示されます。
- {http://webservice.arcflash.com}IsVmFileExist に対するディスパッチ方法が見つかりません。
- {https://webservice.arcflash.com}IsVmFileExist に対するディスパッチ方法が見つかりません。
- 解決策
- Hyper-V サーバ上で Arcserve UDP エージェントを Arcserve UDP v6.5 にアップグレードします。
- 電源を入れると、ディスクがオフライン ステータスで起動します。この動作が発生するのは、Windows 2008 およびそれ以降のオペレーティング システムに SAN ポリシーが導入されたためです。オペレーティング システムは、複数のサーバへのアクセス権を持つ共有ディスクを保護します。サーバがディスクを検出すると、Windows はオフライン状態でディスクを配置します。ディスクがオンライン状態で配置されると、そのディスクはオンライン状態のままになります。
- この動作のもう 1 つの原因は、読み取り専用ボリュームが含まれる仮想マシンの電源をオンにすることです。この状況を修正するには、書き込み可能な状態のディスクにボリュームを配置します。
- アプリケーションでは、vCenter サーバを VMware リンク モードを使用してインポートすることはサポートされていません。リンク モード グループ内のすべての vCenter サーバ インスタンスを保護するには、vCenter サーバ インスタンスをそれぞれ個別に追加します。
- 仮想スタンバイでは、ソース コンピュータ上のシステム ボリュームまたはブート ボリュームがダイナミック ディスク上に存在する場合、復旧ポイントを Hyper-V 形式に変換できません。
- Windows 2008 R2 SP1 および Windows 2012 の Hyper-V サーバ システム上で保護されている仮想マシンで使用される、ダイナミック RAM の量を定義する仮想スタンバイ タスクの作成はサポートされていません。
- 現在のスナップショットを使用して仮想から物理へ(V2P)の復旧を実行する場合、以下のエラー メッセージが表示されます。
- 復旧ポイントの情報を取得することに失敗しました。
- 現象
- この動作は、最新のスナップショットを使用して V2P 復旧を実行した場合で、仮想スタンバイ タスクがノードに再展開された後、ノードの変換ジョブが完了しなかったときに発生します。
- 解決策
- 以下の手順に従います。
- Arcserve UDP エージェント バックアップ ジョブをサブミットしてノードの現在の状態をキャプチャします。
- ノードのベア メタル復旧を実行します。
- 仮想スタンバイ VM の電源をオフにします。
- 仮想スタンバイ変換ジョブをサブミットします。
- ノードの現在の復旧ポイント スナップショットが作成されます。
- V2P ユーザ インターフェースに最新のスナップショットが表示されない場合があります。
- 現象
- この問題は、最新のスナップショットからの V2P 復旧を完了した後に V2P 復旧を実行した場合に発生します。
- 解決策
- Arcserve UDP エージェント ベア メタル復旧を使用して V2P 復旧を実行します。
- Arcserve UDP エージェントのバックアップ セッションを変換する仮想スタンバイ マシンは、いくつかの条件下で、パーティションと、対応する 4 KB セクタ ディスクのボリュームを検出できません。たとえば、バックアップ ソース マシン(Arcserve UDP エージェントがインストールされている)にネイティブの 4 KB セクタ ディスクが含まれ、Arcserve UDP エージェントが 4 KB セクタ ディスクのボリュームをバックアップしたとします。この動作は、ソース ディスクに 4 KB セクタが含まれており、仮想スタンバイ マシンが 512 バイトのセクタ ディスクをサポートしている場合に発生する可能性があります。変換後、仮想スタンバイ マシン上のゲスト オペレーティング システムでは、セクタ サイズの変更により、ディスク メタデータの検索に失敗します。
- 注: この制限は、Hyper-V サーバ上で実行されている仮想スタンバイ ジョブのみに適用されます。
- ホスト ベースの仮想マシン セッションの場合、ネットワーク アダプタが VM に接続され、後で切断されると、仮想スタンバイには VM の現在のリストより多くのネットワーク アダプタが表示されます。
- 仮想スタンバイ モニタのパスワードを変更し、Arcserve UDP コンソール UI で仮想スタンバイ モニタ用のノードを更新した後に、そのモニタ サーバを使用したプランの展開が失敗する可能性があります。
- 現象
- プランの展開が失敗し、次のエラー メッセージが表示されます。
- '仮想スタンバイ設定' をノード 'xxx' へ適用できません。(xxx からモニタ xxx に接続できませんでした。ユーザ認証情報が無効です)
- 解決策
- そのプラン内の仮想スタンバイ タスクを編集し、モニタに正しいパスワードを入力し、プランを保存します。
- RPS とプロキシ サーバの両方がクラウド内にある場合、仮想スタンバイ ジョブは失敗します。
- 仮想スタンバイの状態で、ソース ノードの状態がハートビート タイムアウトと表示されます。
- ソース ノードに .Net Framework がインストールされていないか、プランの展開中に EFI を使用してソース ノードを起動している場合、仮想スタンバイ ジョブが失敗します。
- Microsoft Azure クラウドへの仮想スタンバイ ジョブが失敗します。
- 現象
- 仮想スタンバイ ジョブで新しい復旧ポイントのスナップショットの作成が失敗します。
- 現象
- ソース ノード ホスト名を変更し、バックアップ ジョブを実行すると、仮想スタンバイ ジョブで新しい復旧ポイントのスナップショットの作成が失敗し、以下のエラー メッセージが表示されます。
- 仮想スタンバイ VM は最新の復旧ポイントによって最新の状態になっています。仮想スタンバイでは、バックアップ先で別の復旧ポイント スナップショットを作成するための新しいバックアップ セッションが検出されませんでした。
- 解決策
- 新しいフル バックアップ ジョブを実行し、再度プランを展開します。
- Microsoft Azure で仮想スタンバイ VM の電源をオンにできません。
- 現象
- Microsoft Azure で仮想スタンバイ VM の電源をオンにできず、アクティビティ ログに以下のエラー メッセージが表示されます。
- パラメータ networkSecurityGroupName は必須であり、null にはできません。
- 解決策
- 回避策として、以下の手順に従います。
- プランを再度展開します。
- 注:Arcserve UDP モニタおよび Arcserve UDP RPS では、Arcserve UDP のバージョンが同じである必要があります。
- 仮想スタンバイ VM の電源をオンにします。
- バックアップ先が共有フォルダの場合、ソース ノードまたはエージェントレス バックアップ プロキシのエージェント Web サービスは、いくつかの仮想スタンバイ ジョブを実行した後に異常な状態になる可能性があります。
- 現象
- ソース ノードまたはエージェントレス バックアップ プロキシ上のエージェント Web サービスが応答せず、OutOfMemory エラーが Webservice.log ファイルに出力されます。
- 解決策
- このエラーは、ソース ノードまたはエージェントレス バックアップ プロキシが仮想スタンバイ タスクを持つプランで設定され、バックアップ タスクのバックアップ先が共有フォルダである場合に発生します。このような場合、ソース ノードまたはエージェントレス バックアップ プロキシは、仮想スタンバイ変換役割で実行されます。エージェント Web サービスは、JVM を実行するためにより多くのメモリを必要とします。エージェント Web サービスの JvmMx 値を増やします。
- 以下の手順に従います。
- レジストリを開くには、コマンド ライン インターフェースを開き、以下のコマンドを実行します。
- regedit
- 「\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun 2.0\CASAD2DWebSvc\Parameters\Java」に移動します。
- 以下のようにキーを変更します。
- キー名: JvmMx
- 値: <値を分単位で入力>。たとえば、値を 512 以上に増やします。
- regedit を終了します。
- UDP エージェント サービスを再起動して設定を有効にします。
- [EC2 リソースの終了]オプションは、ノードが EC2 に対する仮想スタンバイ タスクで設定されている場合は表示されません。
- 現象
- UDP 7.0 U1、UDP 7.0、または UDP 6.5 U4 で EC2 に対する仮想スタンバイ タスクがあるプランを使用してノードが設定されている場合、そのコンソールを UDP 7.0 U2 にアップグレードすると、それらの特定のノードには[EC2 リソースを終了する]オプションは表示されません。
- 解決策
- 関連するプランの[変更]オプションをクリックして保存します。
- Windows Server 2008 R2 と拡張ネットワーク アダプタ(ENA)を使用した Windows Server 2012 の仮想スタンバイでは、マシンをオンにしてもネットワーク サービスが起動しないため、ネットワークに対応させるためにバッチ スクリプトを実行する必要があります。
- 現象
- Windows Server 2008 R2 および Windows Server 2012 の仮想スタンバイ マシンをオンにすると、Elastic Network Adapter (ENA)でサポートされるインスタンス タイプで設定されている場合、AWS 管理コンソールに 1/2 チェックが表示されます。
- 詳細については、https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking-ena.html で「Elastic Network Adapter (ENA)でサポートされるインスタンス タイプ」を参照してください。
- 解決策
- 以下の手順に従います。
- UDP コンソールから、マシン単位でスタンバイをオンにします。
- Windows マシンのいずれかに AWS CLI をインストールして設定します。
- FixWindowsInstanceNetworksChecks.bat を実行します。以下のリンクからダウンロードできます。
- バッチ ファイルを実行するには、以下のコマンドを使用します。
- instance_type: 環境設定プランで指定されたインスタンス タイプ。
- instance_id: AWS 管理コンソールまたは仮想スタンバイ アクティビティ ジョブ ログから取得できる VSB インスタンスの ID。
- [仮想マシン]タブで、インスタンス タイプのデータを確認して、環境設定プランを確認します。
- アクティビティ ログから、インスタンス タイプを派生させます。
- 実行するコマンド:
- スクリプトの実行が終了した後、Windows Server 2008 R2 または Windows Server 2012 のインスタンスに接続できます。
現象
Arcserve UDP 復旧ポイント サーバをバックアップ先にしたバックアップ プランを作成し、バックアップ ジョブを実行します。バックアップが成功した後、プランを変更し、バックアップ先としてローカル ディスクまたは共有フォルダを選択して、アドホック VSB ジョブを実行すると、RPS データストアにバックアップされたセッションがアドホック VSB ウィザードのデータ ストア リストに表示されません。
現象
エージェント ベースのバックアップ セッションのためにデフォルトの[データ転送にプロキシとしてモニタ サーバを使用します]オプションで仮想スタンバイ タスクを保存した場合でも、アクティビティ ログに誤ったメッセージが表示されます。しかし、仮想スタンバイ ジョブはモニタ サーバをプロキシとして使用して実行されます。
モニタ サーバは [xx.xx.xx.xx] で、データ転送のプロキシとして使用されません。
現象
現象
現象
現象
現象
現象
現象
現象
ノードが RPS データ ストアにバックアップされ、別の RPS データ ストアにレプリケートされて、さらにレプリケーションのソースで仮想スタンバイ マシンを作成する場合、プランの展開後に、仮想スタンバイ ジョブの古いセッションに対して仮想スタンバイを直接再開できます。しかし、ジョブをサブミットした後、仮想スタンバイ ジョブが開始されません。
解決策
現象
RPS とプロキシ サーバがクラウドにあるときに仮想スタンバイを EC2 タスクに設定すると、以下の問題が発生する可能性があります。
解決策
この問題を回避するには、ローカル RPS とクラウド プロキシ サーバを使用します。
Microsoft Azure クラウドのソース マシンのシステム ディスク サイズを拡張し、仮想スタンバイ ジョブを実行すると、以下のエラー メッセージが表示されます。
VM [x.x.x.x] のセッションのクラウドへの変換に失敗しました。内部エラーが発生しました。Arcserve サポートにお問い合わせください。
解決策
Azure portal で、左側のパネルから[ストレージ アカウント]パネルに移動し、ソース マシンで以前生成したページ BLOB を削除して、仮想スタンバイ ジョブの名前を変更します。
FixWindowsInstanceNetworksChecks.bat instance_id instance_type
例:
この例は、インスタンスを確認する方法を示しています。
FixWindowsInstanceNetworksChecks.bat i-0384bbbf2e7ce7e2c t3.medium