Host-based VM Backup 関連

ESXi 6.0 または ESXi 6.0.x で、変更ブロックのトラッキングを有効にして VMware VM をバックアップするときに潜在的な問題が検出されます。
現象
変更ブロックのトラッキング（CBT）は、ESXi 6.0 または ESXi 6.0.x の不正な変更セクタリストを返します。Arcserve UDP は潜在的に、一貫していない仮想マシンバックアップ（完全および増分の両方）を引き起こす問題の影響を受けます。詳細については、KB 記事を参照してください。
この問題が発生した場合は、カタログジョブが失敗し、復旧ポイントビューでエラーが報告される可能性があります。
解決策
VMware では、この問題の修正をリリースしました。このパッチを ESXi ホスト上で適用してください。
詳細については、VMware KB 記事または Arcserve KB 記事を参照してください。

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

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

ESXi 5.5 またはそれ以前のバージョンに存在する VM に対して、SAN 転送モードを使用したバックアップおよびリストアジョブが失敗し、非 SAN 転送モードに戻されます。
現象
SAN 転送モードが可能な場合でも、バックアップまたはリストアジョブで、HotAdd、NBD、または NBDSSL 転送モードが使用されます。
解決策
現在 VMware で利用可能な解決策はありません。
詳細については、「VDDK 6.0.1 の既知の問題のリリースノート」を参照してください。

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 での問題のあるライタの無効化-復旧ポイントチェックで問題が検出された場合、ArcserveKB 記事の 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 スナップショット静止方式を使用している場合、バックアップに整合性がない可能性があります。これは特にアプリケーション（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 仮想マシンの増分バックアップジョブを実行する場合、バックアップされたデータサイズが予想より大きいことがあります。
現象
VMware の既知の問題のために、アプリケーションレベルの静止で、変更ブロックのトラッキング（CBT）により変更が誇張されます。
解決策
この問題は、VMware ESXi 5.5 以降、および VMware ESX 5.1 Patch 02 で修正されています。VMware vCenter Server 5.5 が VMware ESXi 5.1 ホストを管理する場合は、それらに対してパッチが適用されます。この修正に関する詳細については、VMware のナレッジベースを参照してください。
問題が継続する場合は、プロキシサーバ上で以下のレジストリを設定します。
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\<VM instance UUID>]
"ResetCBT"=dword:00000001
例:
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\502d3c43-e3c9-9919-78f9-89082ca5e1cc]
"ResetCBT"=dword:00000001
- 注：このレジストリ値を設定すると、次回の増分バックアップジョブは検証バックアップジョブに変換され、それ以降の増分バックアップジョブは、継続して適切なサイズで実行されます。

VMware の既知の問題により、ストレージ DRS が有効になっている場合、バックアップジョブの実行中に Storage vMotion が発生すると、バックアップジョブが失敗し、アクティビティログに以下のメッセージが表示されます。
Unable to open the VMDK file.
VMware は、以下の内容のエラーメッセージを報告します。
A file was not found.
詳細については、VMware KB 記事 2055943 を参照してください。

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 に対してスナップショットを作成できるようになりました。
詳細については、リンクを参照してください。

HTTP プロトコルおよびポート 80 を使用しているときに、vCenter Server/ESXi 5.0 Update 3 以降から VMware 仮想マシンをインポートする場合、接続に失敗します。この問題は VMware での既知の問題です。
詳細については、リンクを参照してください。

Arcserve UDP ジョブが実行されると、ESX/ESXi/vSphere 5.5 のパープルスクリーンが表示されます。
現象
これは、E1000 および E1000e 仮想ネットワークアダプタを使用する ESXi 5.0、5.1、5.5 ホストおよび仮想マシンに影響する、VMware の既知の問題です。
- 注：この問題は、以下の VMware 更新で解決されます。

ESXi 5.0 パッチリリース ESXi500-201401001。詳細については、VMware ナレッジベースを参照してください。
ESXi 5.1 Update 2 （VMware ダウンロードで提供されています）。詳細については、VMware ナレッジベースを参照してください。
ESXi 5.5 Update 1 （VMware ダウンロードで提供されています）。詳細については、VMware ESXi 5.5 Update 1 のリリースノートを参照してください。
ESXi 6.0 GA （VMware ダウンロードで提供されています）。詳細については、VMware ESXi 6.0 のリリースノートを参照してください。

解決策
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 ポリシーが変更されます。

Hyper-V 仮想マシンに接続されている iSCSI ハードディスクがバックアップされません。
現象
Hyper-v VM をバックアップした後、iSCSI デバイス上のボリュームはリストア UI でリスト表示されません。
解決策
Arcserve UDP にエージェントベースのバックアッププランを作成するか、または Arcserve UDP エージェント（Windows）を使用して、仮想マシンをバックアップします。

ゲストオペレーティングシステムが Windows Server 2003 である場合、実行前/後コマンドは、Hyper-v VM 上のホストベースエージェントレスバックアップジョブでは実行されまえん。
現象
Hyper-v VM でのホストベースエージェントレスバックアップジョブでは、ゲストオペレーティングシステムが Windows Server 2003 である場合、実行前/後コマンド実行できません。アクティビティログに以下の警告が出力されます。
予期しない仮想マシン名です。実行前/実行後コマンドを実行できません。
解決策
Windows Server 2008、Windows Vista、またはそれ以降のバージョンのオペレーティングシステムでは、この問題は発生しません。

バックアッププロキシが Windows 2003 R2 64 ビットのマシンの場合に VMware VM のバックアップジョブがクラッシュすることがあります。
現象
Windows 2003 R2 64 ビットマシンが VMware VM を保護するバックアッププロキシサーバとして使用される場合、バックアップジョブがクラッシュする可能性があります。以下のエラーメッセージがデバッグログに表示されます。
[2016/01/21 10:18:11:316 00 03820 03336 ] [VDDKLOG] VixDiskLib: VixDiskLib_OpenEx: Open a disk.{AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:18:11:316 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: VixDiskLibVim_GetNfcTicket: Get NFC ticket for [datastore1 (3)] VMname/VMware_1.vmdk.{AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:19:11:691 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: Error 18000 (listener error GVmomiFaultInvalidResponse).{AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:19:11:691 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: Login failure.Callback error 18000 at 2439.{AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:19:11:691 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: Failed to find the VM.Error 18000 at 2511.{AFBackend.exe::AFBackupVirtual.dll(1746.0)}
解決策
Arcserve UDP バージョン 6.5 には、VMware VDDK 6.0.2 が組み込まれています。ただし、VDDK 6.0.2 は Windows 2003 R2 を公式にサポートしていません。回避策として、以下のいずれかのオプションを使用できます。

VDDK 6.0.2 で正式にサポートされているプロキシ（Windows 2008 R2、Windows 2012 または Windows 2012 R2 のプロキシなど）の使用に切り替えます。
組み込みの VDDK 6.0.2 を Arcserve UDP 6.5 でもサポートされている VDDK 5.5.5 に置き換えます。VDDK を置き換える方法の詳細については、「Arcserve UDP の組み込みのバージョン（6.0.2）と異なるバージョンの VDDK を適用する方法」を参照してください。

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 ドライバがデッドロックを引き起こすという既知の問題があります。詳細については、ナレッジベースを参照してください。
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 暗号化ボリュームをリストアできます。
ゲスト OS の静的 IP アドレスの設定に失敗しました。

現象：

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

解決策:

この問題を回避するには、リストアされた VM で静的 IP アドレスを手動で設定します。