Host-based VM Backup 関連

記憶域スペースダイレクト（S2D）クラスタで実行されている Hyper-V クラスタ VM のバックアップを実行すると、アクティビティログに以下の誤ったメッセージが表示されます。
VM はスタンドアロンモードでバックアップされます。

バックアップ中に Windows Server 2019 VM の静止スナップショットを作成できません。
現象
Windows 2019 VM をバックアップする場合、以下に示すようにバックアップジョブのアクティビティログにエラーメッセージが表示される可能性があります。
仮想マシンのスナップショットを作成できませんでした。ESX Server/vCenter Server で「An error occurred while quiescing the virtual machine」というエラーが報告されました。詳細については、仮想マシンのイベントログを参照してください。
注：バックアッププランで［静止したスナップショットの作成に失敗した場合は、静止せずにスナップショットを取得］オプションが選択されている場合、バックアップジョブはエラーを無視し、VM を静止せずにスナップショットの作成を続行します。ただし、クラッシュコンシステントバックアップの場合、バックアップデータの整合性は保証されません。
解決策
この問題は VMware に関連したものです。この問題の回避策はありません。詳細については、VMware ナレッジベースのリンクを参照してください。

VM がリストアされるとオプション workingDir が消えますが、VMDK は workingDir で指定した場所にリストアされます。
現象
VM がデフォルト（VM と同じ場所）以外の異なる workingDir で設定されている場合、VM の復旧後、設定された workingDir は消えますが、VM の VMDK は元の workingDir で指定した場所にリストアされます。この問題は以下の場合にのみ発生します。

オプション［元の場所にリストアする］が使用されている場合。
バックアップ前に、ユーザが手動で VM にスナップショットを作成する場合。

解決策
VM の復旧後、オプション workingDir が消えます。
Arcserve UDP は VM 設定ファイル（.vmx ファイル）を直接バックアップするのではなく、vSphere API を使用して VM 設定情報を取得します。ただし、workingDir オプションは vSphere API で取得されないため、Arcserve UDP は workingDir 設定情報に関する情報をバックアップできません。必要な場合、VM のリストア後に手動で workingDir オプションを設定します。
VMDK は workingDir で指定された場所にリストアされます。
ユーザが手動でスナップショットを作成した後、デルタ VMDK は workingDir の場所に作成されます。デルタ VMDK がこの VMDK のアクティブディスクになります。したがって、Arcserve UDP が VM をバックアップすると、workingDir が VMDK 情報の一部として復旧ポイントに記録されます。その結果、VM のリストア時に、Arcserve UDP はデフォルトでこの場所にリストアします（workingDir）。この問題を回避するには、UDP オプション［別の場所にリストアする］を使用して、VMDK がリストアされる場所を手動で指定します。

VM が SEsparse スナップショットで実行されている場合、vSphere VM のエージェントレスバックアップで破損したデータがバックアップされます。
現象

手動でスナップショットを作成した VM のエージェントレスバックアップ中、VM の仮想ディスクが以下の場合にバックアップされたデータが破損する可能性があります。

VMFS-5 データストアまたは NFS データストアに存在し、サイズが 2 TB 以上の場合
VMFS-6 データストアに存在する場合

このような条件では、UDP で以下のような問題が発生する場合があります。

カタログジョブが失敗します。
復旧ポイントのチェックが失敗します。
アシュアードリカバリジョブが失敗します。
リストアされた VM が起動に失敗します。

解決策
vSphere の既知の問題は vSphere 6.7 U1 で修正されました。他の vSphere バージョンでの回避策については、VMware KB 記事を参照してください。

バックアップセッションをマウントできません。
現象
バックアップセッションがマウントされません。
解決策
VM 仮想ディスクでデータが破損している場合に問題が発生します。この問題を回避するには、VM を適切にシャットダウンし、VM の電源をオンにし、バックアップを実行して、最新のセッションからマウントします。

Hyper-V で、SUSE Linux Enterprise Server 12 VM のエージェントレスバックアップが失敗し、VM ゲスト OS がバックアップ後にハングします。
現象
Windows の制限のため、Hyper-V ホストが Windows 2012 R2 で、VM のゲスト OS が SUSE Linux Enterprise Server （SLES） 12 でランレベルが 5 （グラフィカルインターフェース）である場合、VM ゲスト OS が応答しなくなります。
解決策
Hyper-V ホストで diskshadow コマンドを使用して VSS スナップショットを作成する場合、同様の問題が発生します。Windows と SUSE の互換性の問題です。
注： Arcserve UDP はこの問題に関係ありません。
以下の手順に従って問題を確認します。

Hyper-V サーバにログインします。
Windows のコマンドラインを管理者として開きます。
以下の操作を実行します。

「diskshadow」と入力し、Enter キーを押します。
「add volume X:」と入力し、Enter キーを押します。
注： X: は VM の仮想ディスクファイルおよび環境設定ファイルが存在するボリュームです。環境設定ファイルまたは VM ディスクファイルが異なるボリュームにある場合、このコマンドを繰り返して、すべてのボリュームを追加します。
「create」と入力し、Enter キーを押します。
スナップショットの作成が終了したら、「end backup」と入力し、Enter キーを押してください。
「exit」と入力し、Enter キーを押します。

VM ゲスト OS がハングするかどうかを確認します。
VM ゲスト OS がハングしていない場合、［Windows イベントログ］、［アプリケーションとサービスログ］、［Microsoft］、［Hyper-V VMMS］、［Admin］を確認してください。スナップショット作成中の VM の失敗を示す 1 つのエラーログを回避する方法はありません。Microsoft に依頼して根本原因を解決することをお勧めします。または、SLES 12 のランレベルを 5 から 3 （グラフィカルインターフェースなし）に変更してください。ただし、解決は保証されません。

プレフライトチェック（PFC）が VMware VM に対して仮想マシンにアクセスできないというエラーを報告します。
現象
VMware VM の場合、プレフライトチェック（PFC）がデータ整合性に関する以下の警告メッセージを報告します。
アプリケーションで仮想マシンにアクセスできなかったため、検証されませんでした。ユーザの認証情報が正しいこと、および管理者権限があることを確認してください。
指定された適切な認証情報を確認します。
解決策
この問題は、VMware VM の PFC にのみ該当します。バックアップなどの他の機能には影響がありません。この問題を回避するには、Arcserve UDP コンソールがインストールされているマシン（エージェントサービスが起動している必要はありません）上で Arcserve UDP エージェントをインストールします。

VM の仮想ディスクのプロビジョニングされたサイズが 4 TB または 4 TB の倍数である場合、SAN 転送モードを使用したバックアップおよびリストアが失敗し、非 SAN 転送モードに戻されます。
現象
SAN 転送モードが可能な場合でも、バックアップまたはリストアジョブで、HotAdd、NBD、または NBDSSL 転送モードが使用されます。
解決策
この問題は VMware の既知の問題として一覧化されています。
VMware でリリースされたパッチを以下に示します。

ESXi 5.5 の場合 - パッチリリース ESXi550-201504001 （2112672）
ESXi 6.0 の場合 - パッチリリース ESXi600-201505001 （2116125）

回避策として、4 TB の倍数であるプロビジョニングサイズを使用しないでください。たとえば、4 TB または 8 TB の代わりに、3.9 TB や 8.1 TB を使用します。

VMware Tools スナップショット静止方式を使用している場合、VMware システムのエージェントレスバックアップは、破損したスナップショットをバックアップします。
現象
VMware Tools を使用して VMware VM を静止した場合、スナップショットに破損したデータが含まれます。バックアップはスナップショットからデータを読み取るため、バックアップされたデータも破損します。この問題の詳細については、VMware の KB 記事を参照してください。
注：この問題は、ゲスト OS が Windows 2008 R2 SP1 および Windows 2012 である VM を持つすべての VMware ESXi バージョンで発生します。VMware によってエラーが返されないため、Arcserve UDP はデータ破損の問題を検出できません。この問題は、データをリストアする場合にのみ発生する可能性があります。
解決策
以下のタスクを実行して、問題を検出および解決します。

復旧ポイントチェック - 復旧ポイントからボリュームをマウントし、バックアップジョブの最後に、Microsoft の CHKDSK ツールを実行してデータの整合性を確認します。chkdsk ツールの実行には時間がかかります。この問題を回避するには、日次または月次のバックアップジョブに対して、このオプションを有効にします。
VM のゲスト OS での問題のあるライタの無効化 - 復旧ポイントチェックで問題が検出された場合、Arcserve KB 記事の「How to check if you may be affected by this bug」で説明されている手順を実行します。この問題の回避策として、VMware は VM のゲスト OS で VSS ライタ MSSearch Service Writer （インストールされていない場合は無視してください）および Shadow Copy Optimization Writer （通常はすべての Windows VM に存在します）を無効にすることを推奨しています。VMware KB 記事に従って手動で実行できます。Arcserve UDP は、バックアップ中に問題のあるライタを無効にする簡単な方法も提供します。詳細については、リンクを参照してください。

VMware VM での Microsoft VSS Inside VM スナップショット静止方式で、整合性のないバックアップが生成される可能性があります。
現象
VMware VM をバックアップするために Microsoft VSS inside VM スナップショット静止方式を使用している場合、バックアップに整合性がない可能性があります。これは特にアプリケーション（Microsoft Exchange など）がインストールされた VM のバックアップで発生する可能性があります。
解決策
回避策として、この問題が解決されるまで、VSS ライタ MSSearch Service Writer および Shadow Copy Optimization Writer を VM のゲスト OS で無効にして、VMware Tools スナップショット静止方式を使用します。

クラスタ化された VM を元の Hyper-V クラスタにリカバリした後、ネットワークアダプタが仮想スイッチへの接続に失敗し、アクティビティログに以下の警告メッセージが表示されます。
ネットワークアダプタ '<<アダプタ名>>' を仮想スイッチに接続できません。
現象
VM をバックアップする際、スナップショットを作成する前に、クラスタ化された VM に対してフェールオーバが発生します。フェールオーバにより、バックアップセッションで記録された Hyper-V ホストが VM 環境設定と一致していません。
解決策
ネットワークアダプタを Hyper-V ホスト上の仮想スイッチに手動で接続するか、または［別の場所にリストアする］オプションを使用して VM を復旧し、VM のリストア環境設定を設定できます。

VMware の既知の問題により、ストレージ DRS が有効になっている場合、バックアップジョブの実行中に Storage vMotion が発生すると、バックアップジョブが失敗し、アクティビティログに以下のメッセージが表示されます。
Unable to open the VMDK file.
現象
VMware は、以下の内容のエラーメッセージを報告します。
A file was not found.
解決策
ストレージの動作が完了したら、バックアップジョブを再実行してください。

VM がスナップショットの作成に失敗したため、2 TB を超える VMDK を持つ VM の復旧に失敗します。
現象
バックアップソース VM には 2 TB を超える VMDK があり、バージョン 5.5 未満の ESX/ESX(i) サーバは、ディスクサイズが最大 2 TB の仮想ディスクのみをサポートします。ただし、VM 復旧中に以下のエラーメッセージが表示される場合があります。

vSphere クライアント：
- Create virtual machine snapshot VIRTUALMACHINE File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>’.
- File is larger than the maximum size supported by datastore.
ESX/ESXi 4.x の hostd ログファイル：
- Snapshot guest failed: The file is too big for the file system.
ESXi 5.0/5.1 の hostd ログファイル：
- Failed to do snapshot op: Error: (21) The file is too big for the datastore.

解決策
VMware の制限により、バージョン 5.5 未満の VMware ESX/ESX(i) サーバがサポートする最大サイズは 2 T-16 GB （2032 GB）です。
大容量のディスクで変換を実行するには、デスティネーションとして VMware ESX(i) サーバ 5.5 を使用することをお勧めします。
詳細については、VMware KB 記事 1012384 を参照してください。

ESXi サーバ上で実行されている Windows VM 用の単一の SCSI （Internet Small Computer System Interface）コントローラに、7 つを超えるディスクが接続されている場合、スナップショットの作成は失敗します。
現象
7 つを超える VMDK を持つ SCSI コントローラが含まれる仮想マシン上でバックアップジョブを実行する場合、バックアップジョブは失敗します。スナップショットを作成するために VMware では特定の SCSI コントローラ上に VMDK 用に最大数の空きスロットを必要とするため、ジョブは失敗します。SCSI コントローラは最大 15 スロットを持つことができます。たとえば、SCSI コントローラに 7 つの VMDK がある場合、スナップショットは各 VMDK に対して作成されます。合計 14 のスロットが使用され、空きスロットが 1 つ残ります。SCSI コントローラに 8 つの VMDK がある場合、使用可能なスロットが 15 しかないため、スナップショットが作成されず、バックアップジョブは失敗します。
- 注：手動でのスナップショットの作成も失敗します。
解決策
単一の SCSI コントローラ上に 7 つを超えるディスクを持つ仮想マシンについては、以下の手順に従います。
1. 仮想マシンをシャットダウンします。
2. Web クライアント内の VM を編集して、1 つ以上の SCSI コントローラを追加します。VI クライアントを使用している場合は、直接 SCSI コントローラを追加できません。代わりに、1 つ以上の仮想ディスクを追加し、存在しない仮想デバイスノード番号を指定すると、追加のコントローラが作成されます。
3. 既存のディスクを複数の SCSI コントローラ間で分散させます。
4. 仮想マシンの電源をオンにします。
各 VMDK に対してスナップショットを作成できるようになりました。
詳細については、こちらのリンクをクリックしてください。

Arcserve UDP ジョブを実行すると、VMware VM でパープルスクリーンが表示される場合があります。
現象
これは、E1000 および E1000e 仮想ネットワークアダプタを使用する仮想マシンに影響する、VMware の既知の問題です。
解決策
VMXNET3 アダプタに切り替えます。詳細については、VMware KB 記事 2059053 を参照してください。

リストア中、Hyper-V VM が子仮想ディスクを持つ場合、1 つのイメージを作成することで、子仮想ディスク内のデータが対応する親仮想ディスクにマージされます。VM 復旧後は、親子関係が存在しません。その結果、差分ディスクの環境設定は失われますが、親ディスクのデータは回復することができます。また、VM 復旧後、1 つのマージされたディスクからデータを取得できるように、このプロセスではデータが失われません。
注：エージェントレスバックアップの場合、VM 復旧が成功した後に、差分ディスクを手動で設定できます。

重複した VM インスタンス UUID が存在する場合、VM のインポートは失敗します。
現象
VM がノードビューにインポートされる場合、同じ VM インスタンス UUID を持つ別の VM がノードビューにすでに追加されていると VM が失敗します。

Host-based VM Backup プランが保存されます。選択されたプロキシマシンに Arcserve D2D r16.5 がインストールされている場合、プランは失敗します。
現象
Host-Based VM Backup プランに、以前のリリースの Arcserve D2D （たとえば r16.5）がインストールされているプロキシマシンが含まれている場合、そのプランを保存するとエラーメッセージが表示されます。
ディスパッチメソッドが見つかりません
解決策
この問題は、現行バージョンの API が旧バージョンの Arcserve D2D の API と互換性がないために発生します。回避策として、Arcserve D2D を Arcserve UDP エージェント（Windows）の現行バージョンに手動でアップグレードできます。

Host-Based VM Backup ジョブが、VM のバックアップ開始中段階でハングします。
現象
Host-Based VM Backup ジョブが数時間ハングし、次に進めません。
解決策
アクティビティログ内のプロセス ID を参照して、afbackend.exe を終了し、VM スナップショットが存在する場合は削除し、バックアップジョブを再サブミットします。

ホストベースの VM のリストアジョブ、および Hyper-V 仮想マシン（VM）のバックアップを実行した後、復旧された仮想マシン上のブートディスク以外のディスクのステータスがオフラインになります。
現象
オペレーティングシステムの動作により、デフォルトでのオフライン状態が設定されます。
複数のサーバによってアクセスされる共有ディスクを保護するために、Windows Server 2008 で SAN ポリシーが導入されました。ソース VM のデフォルト SAN ポリシーは、ブートディスク以外のすべての SAN ディスクで「Offline Shared」です。ポリシーをオフラインに設定すると、起動時に、SAN ディスクをオフラインモードにしておくことができます。復旧後、VM 用の新しいディスクが作成されます。VM からのディスクファイルは、SAN ディスクとして表示され、オペレーティングシステムはこのディスクをオフラインであると識別します。オフラインディスクをオンラインに設定し直すと、システムを再起動した後でもそのディスクはオンラインのままです。
解決策
この問題を回避するには、DISKPART.exe コマンドを指定します。ディスクは他のサーバ間で共有されており、データが破損する可能性があるため、バックアップ前にソース VM について SAN POLICY=OnlineAll を設定してください。データの保護には、正しい SAN ポリシーを使用する必要があります。
DISKPART.EXE コマンドライン
SAN ポリシーの照会
DISKPART > san
SAN Policy: Offline Shared
SAN ポリシーの変更
DISKPART > san policy=OnlineAll
DISKPART によって、現在の OS の SAN ポリシーが変更されます。

スナップショットの作成中に Linux VM のバックアップジョブがハングアップします。
現象
vSphere 上に存在する VM （たとえば、RedHat または SUSE）ベースの特定の Linux をバックアップする場合、バックアップジョブがスナップショットを取得する段階でハングします。
解決策
VM に基づいて、バックアッププロキシマシンの以下のレジストリ値を設定して、バックアップ用に非静止スナップショットを取得します。

特定の VM の場合：
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine\AFBackupDll\<vm-instance-uuid>]
DisableTakeQuiescenceSnapshot"=dword:00000001
注： <vm-instance-uuid> を、エージェントログイン後に見つかる VM インスタンス UUID に置き換えてください。
プロキシマシンによって保護されているすべての VM の場合：
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine\AFBackupDll\]
DisableTakeQuiescenceSnapshot"=dword:00000001

Arcserve UDP エージェントレスバックアップは、常に静止したスナップショットを作成しようとします。ただし、静止を有効にして VMware スナップショットを取得している間に同じカーネルを使用すると、特定の Linux カーネルバージョンでは、vmsync ドライバがデッドロックを引き起こすという既知の問題があります。詳細については、関連する KB 記事を参照してください。

VM が検出され、自動 VM 保護によって保護されている場合に、テープへのコピージョブが最初の復旧ポイントで失敗します。
現象
以下の手順に従って問題を確認します。

エージェントレスバックアッププランを作成し、プランに vSphere 階層内のコンテナオブジェクト（たとえば、リソースプール）を追加します。バックアップ先としてローカルフォルダまたは共有フォルダを設定し、同じプランにテープへのコピータスクを追加します。
コンテナオブジェクトの下のこれらの VM に対するバックアップジョブは、スケジュールに従って実行する必要があります。各バックアップジョブ後に、テープに復旧ポイントをコピーするために、テープへのコピージョブがトリガされます。
そのコンテナオブジェクトの下に新しい VM を追加するか、または既存の VM をそのコンテナに移動します。
次回のスケジュール時間に、新しく追加された VM に対して最初のバックアップジョブが自動的にトリガされます。ただし、最初の復旧ポイントがコピーされないよう、最初のバックアップジョブの完了後にはテープジョブへのコピーはトリガされません。テープへのコピージョブは、2 番目のバックアップジョブの完了後に正常にトリガできます。

注：この問題は、バックアップ先がローカル/共有フォルダまたは RPS の場合にのみ発生します。

Arcserve UDP SAN 転送モードではなく NBD/NBDSSL モードに切り替わります。
現象
ESXi データストアの名前に文字 @ が含まれている場合、VMware の制限によって SAN 転送モードは使用されないので、Arcserve UDP は NBD/NBDSSL に切り替わります。
解決策
SAN 転送モードを使用するには、ESXi データストアの名前を変更し、文字 @ を削除します。

BitLocker 暗号化ボリュームに対するファイルレベルリストア、BMR、仮想スタンバイ、インスタント VM、またはアシュアードリカバリテストが失敗する可能性があります。
現象
BitLocker 暗号化ボリュームを持つゲスト VM に対して UDP エージェントレスバックアップが実行されると、BitLocker 暗号化ボリュームはアクティビティログに FAT32 ボリュームとして記述され、BitLocker 暗号化ボリュームに対するファイルレベルリストア、BMR、仮想スタンバイ、インスタント VM、またはアシュアードリカバリテストを実行できません。
解決策
ゲスト VM 全体を回復することによって、BitLocker 暗号化ボリュームをリストアできます。

復元されたテンプレートから VM を展開すると、VM の EFI または BIOS の設定は失われます。

現象

復元されたテンプレートから VM を展開すると、EFI または BIOS ファームウェアのカスタマイズした設定は失われます。

解決策

EFI/BIOS ファームウェアの設定を手動で再度設定してください。

復元された Linux VM は、起動に失敗します。

現象 1：

Linux ゲスト OS で第 2 世代 VM を Hyper-V サーバにリストアすると、VM は起動に失敗し、以下のいずれかのエラーメッセージが表示されます。

Boot Failed. （起動に失敗しました。）EFI SCSI Device.

または

No Operation System was loaded. （オペレーティングシステムがロードされませんでした。）Press a key to retry the boot sequence... （キーを押して起動シーケンスを再試行してください...）

または

Failed to open \EFI\BOOT\grubx64.efi - Not Found （\EFI\BOOT\grubx64.efi を開けませんでした - 見つかりません）

Failed to load image \EFI\BOOT\grubx64.efi: Not Found （イメージ \EFI\BOOT\grubx64.efi のロードに失敗しました: 見つかりません）

start_image() returned Not Found （start_image() により Not Found が返されました）

現象 2：

Linux ゲスト OS で第 2 世代 VM を Hyper-V サーバにリストアした後、Hyper-V マネージャのファームウェアレベルでリストアされた VM の設定内にファイルブートエントリが存在しませんでした。

解決策

これを回避するには、インスタント VM 機能を使用して VM を復旧するか、または VM のゲスト OS に EFI ブートローダを手動で設定します。

以下の手順に従います。

オペレーティングシステム（OS） ISO を VM の CD/DVD デバイスにアタッチし、レスキューモードで VM を起動します。
注：異なる Linux ディストリビューションとバージョンの場合は、レスキューモードでの起動にそれぞれの方法がある可能性があります。詳細については、対応するディストリビューション/バージョンのドキュメントを確認してください。
（オプション）プロンプトが表示されたら、root としてログオンします。
shell プロンプトで、以下のコマンドを入力します。
efibootmgr --create --label <ブートローダラベル> --disk <ディスクデバイス> --loader <ブートローダ>
ブートローダラベル – CentOS などの任意の文字列を示します。
ディスクデバイス – /dev/sda など、EFI システムパーティション（ESP）を含んでいるディスクを示します。
ブートローダ – \EFI\ubuntu\shimx64.efi など、EFI システムパーティション（ESP）に格納されているブートローダの名前とパスを示します。
注：異なる Linux ディストリビューションとバージョンの場合は、以下に示すように異なるパスと名前の可能性があります。

Ubuntu - 常に \EFI\ubuntu\shimx64.efi を使用します。
CentOS - CentOS のバージョンが 7 以上の場合は、\EFI\centos\shim.efi を使用します。それ以外の場合は、/boot/efi/EFI/centos から .efi ファイルを検索し、ローダ名として指定します。
Redhat - Redhat のバージョンが 7 以上の場合は、\EFI\redhat\shim.efi を使用します。それ以外の場合は、/boot/efi/EFI/redhat から \EFI\redhat\grub.efi などの .efi ファイルを検索し、ローダ名として指定します。
SUSE - SUSE のバージョンが 7 以上の場合は、\EFI\SuSE\shim.efi を使用します。それ以外の場合は、/boot/efi/EFI/SuSE から \efi\SuSE\elilo.efi などの .efi ファイルを検索し、ローダ名として指定します。

Hyper-V の VM の設定で追加したファイルブートエントリを確認します。
システムを再起動します。

リストアジョブは、同じ名前の仮想ディスクが 2 つある Hyper-V VM では失敗します。
現象
同じ名前の仮想ディスクが 2 つある Hyper-V VM を同じフォルダにリストアすると、リストアジョブは次のエラーで失敗します。
仮想ディスク [xxx] の作成に失敗しました。エラー = [ファイルが存在します。 (80)]
解決策
この問題を回避するには、2 つの仮想ディスクを異なるフォルダにリストアします。

Windows Small Business Server 2011 ゲスト OS は、VMware VM のクライアントバージョンとして認識されます。
現象
VM に Windows Small Business Server 2011 ゲスト OS がある場合は、プレフライトチェック（PFC）によって次の警告が表示されます。
VMware は、クライアントバージョンの Microsoft Windows オペレーティングシステムが実行中の VM でアプリケーション整合性のある休止処理をサポートしていません。
VMware の既知の問題のため、VM の guest.guestFullName プロパティが［Microsoft Windows 7 （64 ビット）］に設定されます。そのため、Arcserve UDP は VM を Windows のクライアントバージョンとして認識します。
解決策
回避策として、Arcserve UDP が guest.guestFullName の代わりに config.guestFullName VM プロパティを使用することを確認してください。Arcserve UDP コンソールおよびプロキシマシンを変更するには、次のパスで VMwareVMUseConfiguredOS 文字列値 1 を追加する必要があります。
HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine
注：文字列値を追加した後、Arcserve UDP コンソールサービスとエージェントサービスを再起動する必要があります。

Arcserve UDP エージェントレスバックアップジョブの実行後、Hyper-V VM は遅くなります。
現象
Hyper-V VM に対して Arcserve UDP エージェントレスバックアップジョブを実行する場合は、バックアップジョブが OS に対して実行されないため、Hyper-V VM のゲスト OS は非常に遅くなります。VM が巨大な（数 TB）の単一仮想ディスク（VHD/VHDx）を使用し、ゲスト OS 内で頻繁に読み取り/書き込み操作を実行していると、この問題が発生します。
解決策
この問題を回避するには、VHD/VHDx ファイルが存在するボリュームから、Arcserve UDP Hyper-V CBT ドライバをアンロードします。
詳細または Arcserve UDP 環境用のパッチの取得については、Arcserve サポートにお問い合わせください。

ESXi 5.1 上に存在する VM に対してバックアップを実行すると、バックアップジョブが失敗します。
現象
Essential または Standard ライセンスが適用されている ESXi 5.1 上に存在する VM に対してバックアップを実行すると、バックアップジョブが失敗し、アクティビティログに以下のエラーメッセージが表示されます。
VMDK ファイル <VMDK ファイルパスおよび名前> を開くことができません。VMware は以下のエラーをレポートしました：ホストはこの機能について許可されていません。詳細については、デバッグログ <ログファイル名> を参照してください。必要に応じて Arcserve サポートまでお問い合わせください。
解決策

この問題は、VDDK 5.5 でのライセンスチェックメカニズムの変更が原因で発生します。この問題を回避するには、VDDK 5.5 を VDDK 6.0.2 に置き換える必要があります。

以下の手順に従います。

VMware Web サイトから VDDK 6.0.2 パッケージをダウンロードし、一時フォルダにファイルを解凍します。
エージェントレスバックアッププロキシマシンにログインします。
以下のパスに移動します。
C:\Program Files\Arcserve\Unified Data Protection\Engine\BIN\
バックアップのため、VDDK5.5 フォルダを VDDK5.5-org にコピーします。
次のパスにある bin フォルダを削除します。
Files\Arcserve\Unified Data Protection\Engine\BIN\VDDK5.5\BIN\VDDK64
ダウンロードした VDDK 6.0.2 パッケージの利用可能な bin フォルダを以下の場所にコピーします。
C:\Program Files\Arcserve\Unified DataProtection\Engine\BIN\VDDK5.5\BIN\VDDK64

VDDK 5.5 が正常に VDDK 6.0.2 に置き換えられました。

リストアダイアログボックスで、ドライブボリュームの名前が正しく表示されません。
現象
Hyper-V 2016 VM の復旧ポイントから VM またはファイルレベルリストアを実行すると、リストアダイアログボックスに、ボリューム名がドライブ文字ではなくボリューム GUID として表示されます。
解決策
これは Microsoft の既知の問題のために発生します。詳細については、関連する KB 記事を参照してください。

エージェントレスバックアップが失敗します。
現象
vSphere v6.7 では、VM で NVDIMM デバイスが利用可能な場合、または仮想ディスクが PMem データストアに存在する場合、VM のエージェントレスバックアップが失敗します。
解決策
回避策として、エージェントベースのバックアップを実行して VM を保護します。

ゲスト OS の静的 IP アドレスの設定に失敗しました。
現象
Hyper-V 2016 および 2019 では、リストアされた VM は VM の再起動後に静的 IP アドレスの設定に失敗します。この問題は、VM のゲスト OS で静的 IP アドレスを設定し、エージェントレスバックアップを実行し、VM をリストアした場合に発生します。
解決策
この問題を回避するには、リストアされた VM で静的 IP アドレスを手動で設定します。

追加の仮想ディスクがバックアップされます。
現象
エージェントレスプロキシ VM のバックアップジョブを実行し、HotAdd トランスポートモードを使用してそれぞれのエージェントプロキシ VM に関連付けられているエージェントレス VM に対して同時にバックアップジョブを実行すると、両方の VM のバックアップデータがエージェントレスプロキシ VM バックアップデータに追加されます。
解決策
回避策として、以下のいずれかの解決策を使用できます。

エージェントレスバックアップの代わりにエージェントベースのバックアップを使用して、エージェントレスバックアッププロキシを保護します。
プロキシ VM にエージェントレスバックアップを使用する場合、HotAdd モードの前に、バックアッププロキシ VM を使用するエージェントレスバックアッププランで NBD/NBDSSL トランスポートモードを設定します。
プロキシ VM のエージェントレスバックアップジョブがスケジュールされている場合、他のエージェントレスバックアップジョブが同じプロキシで実行されないことを確認します。

Windows Server 2016 で Hyper-V に復旧された Windows VM の静的 IP アドレスをリストアできません。
現象

Windows VM を Windows Server 2016 上の Hyper-V に復旧させると、VM の IP アドレスが静的である場合、復旧された VM の静的 IP 設定は失われます。

注： MAC アドレスは復旧できますが、Hyper-V サーバが Windows Server 2012 または Windows Server 2012 R2 上にある場合にのみ、静的 IP アドレスを復旧できます。

解決策

VM の復旧後、静的 IP アドレスを手動で設定します。