| Arcserve |
以下の問題が本リリースに存在していることが判明しています。
Data Corruption During UDP Upgrade due to Backward Compatibility
You may notice data corruption for backward compatibility of protecting UDP v5 nodes to UDP v6 RPS, it might cause data corruption on deduplication data store.
This issue does not impact if you are using one of the following options:
This issue impacts if you have:
When do you face this data corruption:
If you are upgrading from Arcserve UDP v5 to Arcserve UDP v6, you may face this issue in the following scenarios:
症状
The data corruption issue might happen in the following two scenarios.
Scenario 1: The Agent node is with Arcserve UDP v5 and the RPS node is with Arcserve UDP v6. Agent job fails to back up and generates the incomplete recovery point on the deduplication data store. Deleting the incomplete recovery point from the deduplication data store may lead to data corruption.
Scenario 2: The source RPS node is with Arcserve UDP v5 and the destination RPS node is with Arcserve UDP v6. The Replication job fails and generates the incomplete recovery point destination deduplication data store. Deleting the incomplete recovery point from the destination deduplication data store may lead to data corruption.
Reason
Due to the mismatch of interface between different versions, when Arcserve UDP v6 RPS tries to delete the incomplete sessions generated by Arcserve UDP v5, it may wrongly delete additional index files which leads to data corruption.
解決方法
If you are upgrading from Arcserve UDP v5 to Arcserve UDP v6:
Note: Before applying the patch, do not run any backup/replication jobs.
Note: If you opt for this option, do not upgrade to Arcserve UDP v6. You can directly upgrade from Arcserve UDP v5 to Arcserve UDP v6 update 1.
If you have already upgraded from Arcserve UDP v5 to Arcserve UDP v6:
Note: Contact Arcserve Support to get the patch.
How to handle corrupted recovery points?
You cannot recover any recovery point that is corrupted due to the backward compatibility issue as the corresponding index file is incorrectly deleted.
To make sure that the subsequent recovery points do not depend on the corrupted recovery point, we recommend to take again full backup for the impacted node.
In addition, other jobs related to merge job that need to read from the corrupted recovery point might continue failing even though new full backup is done.
To solve the above, we recommend to rename the node folder in the backup destination folder of dedupe data store. Add Backup as prefix to the original node name.
For example:
NODE_NAME[1a98528f-db3c-45de-83d6-9d729815ab7d]
to
BackupNode_Name[1a98528f-db3c-45de-83d6-9d729815ab7d]
As a result, new folder name of the source node is created that automatically converts the recovery point as full when the specific node backs up to the data store again.
For the renamed folder, you can perform the following options:
You can select to delete the renamed node through data store UI, if all the recovery points in the renamed folder are not useful anymore. The automatic retention management of the Plan only applies to the new recovery points done after the renaming of the folder.
Windows 10 Edge Web ブラウザを使用している場合、［リストア］または［エージェントへのログイン］をクリックして Windows または Linux エージェントにコンソールからログインできない場合があります。別のブラウザを使用してログインしてください。
症状
ESXi ホストで同じ GUID を持つ 2 台の仮想マシン（VM1、VM2）があり、2 台の VM が異なる vCenter （VC1、VC2）によってそれぞれ管理されているとします。VM1 をコンソールにインポートします。コンソールでは、同じ GUID を持つノードが許可されないため、両方の VM をインポートすることはできません。しかし vCenter VC2 からも VM をインポートしたとします。オート ディスカバリを実行すると、まず VC1 に接続し、GUID によって VM1 を検出し、［ハイパーバイザ］列が VC1 の情報で更新されます。その後、VC2 に接続すると、GUID によって VM2 が検出され、［ハイパーバイザ］列が VC2 の情報で更新されます。
解決方法
2 台の VM が同じ GUID を持つことは非常にまれです。しかし万が一発生した場合、Arcserve UDP では GUID を使用して VM を識別するため、ホスト ベースのエージェントレス バックアップで誤った VM がバックアップされる可能性があります。この問題を解決するため、いずれかの VM の GUID を手動で変更できます。これを行う方法の詳細については、「ソリューション ガイド」で関連トピックを参照してください。
症状
Arcserve UDP コンソールにログインできません。コンソールには、5 分間のログイン後でも、以下のメッセージが表示されます。
ID サービスを開始します。
解決方法
この問題を解決する方法：
症状
ノードのいずれかでレプリケーション ジョブが進行中である場合、複数のノードに対するジャンプ スタート ジョブが失敗します。
解決方法
ジャンプ スタート ジョブをサブミットする前にそのレプリケーション ジョブが完了するのを待機するか、他のノードに対してジャンプ スタート ジョブをサブミットします。
症状
テープへのコピー ジョブが以下の状況で失敗する可能性があります。
解決方法
最初の問題の場合、ローカライズされていないユーザ名を使用して Arcserve UDP エージェント ノードを Arcserve UDP コンソール UI に追加します。
2 番目の問題の場合、ローカライズされていないユーザ名を使用して RPS ノードを Arcserve UDP コンソールに追加します。
症状
NAT 環境でプランを変更する必要がある場合、プランに以下のタスクが含まれていると、［リモートで管理されている RPS からレプリケート］タスクに NAT デバイス設定の重複が表示されます。
プランを変更し、タスク 1 の環境設定を参照する必要がある場合、［サーバは NAT ルータの後方にあります］オプションが設定されていると、［サーバは NAT デバイスの背後にあります］オプションが重複して表示されます。NAT ルータの情報が正しく入力されている場合、レプリケーション ジョブは成功します。
解決方法
プランを変更する場合、［リモートで管理されている RPS からレプリケート］タスクの［サーバは NAT デバイスの背後にあります］フィールドが重複していても無視できます。［サーバは NAT ルータの後方にあります］フィールドを使用して、レプリケーション ジョブが確実に成功するようにします。
症状
ボリューム クラスのレジストリ BLI 上限フィルタは削除されました。そのため、BLI ドライバは、ボリュームをモニタできません。
解決方法
変更トラッキング ドライバを再インストールした後に増分バックアップの実行を続行できます。
次の手順に従ってください：
<installation path>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
<installation path>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
症状
イベント ログに以下のメッセージが表示されることがあります。「削除の対象としてマークされているレジストリ キーに対して不正な操作を実行しようとしました。」または「レジストリ ファイルは他のアプリケーションまたはサービスで使用されています。ファイルはすぐにアンロードされます。レジストリ ファイルを保持しているアプリケーションまたはサービスはこれ以降正しく機能しない可能性があります。」
解決方法
原因および解決策については、Microsoft サポート技術情報 2287297 を参照してください。
症状
ドライバ文字へのセッションのマウントは失敗します。
デスティネーションがローカル フォルダで、FAT32 ボリューム上にある場合、この問題が発生します。ドライバのマウントは、NTFS ボリューム上にキャッシュ ファイルを作成することだけをサポートします。
解決方法
新しいレジストリ キーを追加し、キャッシュ ファイル パスを別のボリュームにカスタマイズします。
次の手順に従ってください：
詳細情報：
キャッシュ ファイルは、書き込み可能なボリュームがマウントされたときに、ドライバをマウントすることによって作成されます。詳細リストア カタログ/リストア ジョブについては、書き込み可能なボリュームが作成されます。Windows 8、Windows Server 2012、またはそれ以降のオペレーティング システムの上のボリュームをバックアップするセッションの場合、セッションをドライバ文字にマウントするときに、常に書き込み可能なボリュームをマウントします。
症状
サブミットしたバックアップは正常に表示されますが、Arcserve UDP エージェント（Windows） UI からはジョブ モニタを参照できません。これは、バックアップ ジョブが、データ ストアの最大同時ノード数の設定に適合するためです。そのバックアップ ジョブは待機キューに入れられます。
解決方法
Arcserve UDP コンソールを開くと、保留中のジョブ モニタがノード ビューに表示されます。
症状
ホスト ベースのエージェントレス検証バックアップ ジョブが実行されており、かつプランで圧縮が有効になっている場合、ジョブ モニタ上の圧縮率は実際の値よりも高く表示されます。
エージェント バックアップ ジョブおよびホスト ベースのエージェントレス フル/増分バックアップ ジョブを含め、その他のすべてのバックアップ ジョブにはこの問題はありません。
解決方法
アクティビティ ログには正しく圧縮率が出力されます。ホスト ベースのエージェントレス検証バックアップ ジョブの完了後、これを参照します。
症状
VMware VM のバックアップ ジョブは、Arcserve UDP コンソールで正常に終了します。ジョブは緑のアイコンによってマークされ、アクティビティ ログには「バックアップ ジョブが正常に完了しました」というメッセージが表示されます。ただし、バックエンド プロセスのダンプ ファイル（例： AFBackend.exe.7912.00.dmp）がエージェントのインストール パスの BIN フォルダに生成されます。例：C:\Program Files\Arcserve\Unified Data Protection\Engine\BIN。
解決方法
これは、VMware VDDK の問題により発生します。VDDK は Arcserve UDP が VDDK への API コールをクローズしているときにクラッシュする場合があります。これはバックアップ ジョブの最終段階で発生するため、この問題は無視できます。その時点で、バックアップ ジョブはほぼ完了しており、復旧ポイントも正常にラップされています。
「言語パッケージを BMR ISO イメージに統合できません」
症状
この問題はサードパーティ アンチウイルス ソフトウェア（マカフィー）フィルタ ドライバが原因で発生しますが、他のサードパーティ フィルタでも発生する可能性があります。
解決方法
アンチウイルス ソフトウェアを無効にし、ブート キットの作成を再度試みてください。
症状
ソース マシンが、ハードウェアが異なる物理マシンまたは Hyper-V サーバ上の仮想マシンに対して BMR を実行する Active Directory サーバである場合、そのサーバは起動せず、ブルー スクリーンが表示され、以下のメッセージが表示されます。
STOP: c00002e2 ディレクトリ サービスは以下のエラーのために開始できませんでした。システムに付属のデバイスは機能していません。エラー状態:0xc0000001。
解決方法
BMR PE 環境へシステムを再起動し、C:\Windows\NTDS フォルダ内にある *.log ファイルの名前をすべて変更し、システムを再起動します。たとえば、ファイル名を「edb.log」から「edb.log.old」へ変更し、システムを再起動します。
症状
ターゲット マシンが、2008 Hyper-V サーバまたは 2008R2 Hyper-V サーバ上の IDE ディスクを含む VM の場合、BMR 中にディスク/ボリュームをマップできない可能性があります。
BMR を使用する 2008 Hyper-V サーバまたは 2008R2 Hyper-V サーバ上の IDE ディスクを含む VM にデータをリストアする場合、ソース ディスク/ボリュームとターゲット ディスク/ボリュームのサイズが同じように見えても、ソース ディスク/ボリュームをターゲット ディスク/ボリュームにマップすることはできません。これは、2008 Hyper-V サーバまたは 2008R2 Hyper-V サーバに IDE ディスクが作成される場合、実際のディスク サイズはユーザが指定したサイズよりも小さいためです。
解決方法
VM で作成するディスクのサイズを増やします。たとえば、25 GB のディスクのデータをリストアする場合、ターゲット VM に 26 GB のディスクを作成することをお勧めします。
症状
これは、VMware ESX Server で発生する問題です。Windows 2003 VM については、デフォルトのディスク コントローラは LSI Logic SCSI アダプタであり、このタイプの SCSI アダプタ用のドライバは Windows ADK 8.1 に含まれていません。この問題は、古い SCSI アダプタが搭載された一部の古いサーバでも発生する可能性があります。
解決方法
この問題を解決するには、ハードウェア ベンダの Web サイトからのドライバを取得し、BMR ユーザ インターフェースからドライバをロードします。
[VDDKLOG] SSLCheckLockingCallback: locking callback overwritten!Expected 7FEE3A836E0, saw 113C2420
この問題を回避するには、VDDKLogLevel レジストリ キーを以下のパスで 0 に設定します。
\HKEY_LOCAL_MACHINE\Software\Arcserve\Unified Data Protection\Engine\
ストレージ システム ‘xxx’ の複数のボリュームにわたってスナップショット コピー '{xxx}_backup' の作成を '10' 秒おきに '100' 回再試行しましたが、失敗しました。
レジストリ キーを追加するには、以下の手順に従います。
HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine
DoNotUseFlexCloneLicenseToCloneLun
Arcserve UDP 復旧ポイント ビューに切り替えた後、バックアップ セッションでファイル パスの下にマウントされるボリュームをマウントできません。
症状
ボリュームがマウントされたままの場合、Arcserve UDP 復旧ポイント ビューは、バックアップ セッションではなくオペレーティング システムによってマウントされるボリュームを直接開きます。
ボリュームがマウント解除されている場合、Arcserve UDP 復旧ポイント ビューのファイル パスの下には何も表示されません。
解決方法
このタイプのボリュームのマウントには、［復旧ポイントのマウント］を使用します。
症状
VMware で最近公開された KB 記事によると、ESXi 6.0 または ESXi 6.0x で、変更ブロックのトラッキング（CBT）のバグが発生し、それにより CBT で間違った変更セクタ リストが返されます。この問題により、Arcserve UDP が影響を受ける可能性があり、結果として仮想マシンのバックアップ（フルおよび増分）が不整合になります。詳細については、VMware の KB 記事を参照してください。
この問題が発生した場合は、カタログ ジョブが失敗し、復旧ポイントのチェックでエラーが報告される可能性があります。
解決方法
VMware では、この問題の修正をリリースしました。このパッチを ESXi ホスト上で適用してください。詳細については、VMware KB 記事または Arcserve KB 記事を参照してください。
症状
この問題は、Hyper-V ホストが Windows 2012 R2 で、VM のゲスト OS が SUSE Linux Enterprise Server （SLES） 12 でランレベルが 5 （グラフィカル インターフェース）である場合に発生します。この場合、エージェントレス バックアップ ジョブは、「スナップショットの取得」段階でハングし、最終的に失敗します。その後、VM ゲスト OS が応答しなくなります。
解決方法
これは、Arcserve UDP の問題ではありませんが、Windows と SUSE の互換性の問題です。Hyper-V ホストで diskshadow コマンドを使用して VSS スナップショットを作成する場合、同様の問題が発生します。以下の手順に従って問題を確認します。
この問題に対する回避策はありません。Microsoft に依頼して根本原因を解決することをお勧めします。または、SLES 12 のランレベルを 5 から 3 に変更して試すこともできますが、これによって完全に解決できるという保証はありません。
症状
VMware VM で、プレフライト チェック（PFC）でデータの整合性チェックを行うと、正しい認証情報を指定した場合でも以下の警告メッセージが表示されます。
アプリケーションで仮想マシンにアクセスできなかったため、検証されませんでした。ユーザの認証情報が正しいこと、および管理者権限があることを確認してください。
解決方法
この問題は、VMware VM 用の PFC でのみ発生します。バックアップなどの他の機能には影響がありません。回避策として、Arcserve UDP コンソールがインストールされているマシンに Arcserve UDP エージェントをインストールします（エージェント サービスを開始する必要はありません）。
症状
SAN 転送モードが可能な場合でも、バックアップまたはリストア ジョブで、HotAdd、NBD、または NBDSSL 転送モードが使用されます。
解決方法
この問題は VMware VDDK 6.0.1 の既知の問題です。VMware からの解決策はまだありません。詳細については、「VDDK 6.0.1 の既知の問題」のリリース ノートを参照できます。
症状
SAN 転送モードが可能な場合でも、VM の仮想ディスクのプロビジョニングされたサイズが 4 TB または 4 TB の倍数であれば、バックアップおよびリストアで 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 VM を静止した場合、スナップショットに破損したデータが含まれます。バックアップはスナップショットからデータを読み取るため、バックアップされたデータも破損します。この問題の詳細については、VMware の KB 記事を参照してください。
注： この問題は、すべての VMware ESXi バージョン、およびゲスト OS が Windows 2008 R2 SP1 および Windows 2012 の VM 上で発生します。この場合、VMware によってエラーが返されないため、Arcserve UDP はデータ破損の問題を検出できません。データのリストアを試行するまで、問題に気付かない可能性があります。
解決方法
以下のタスクを実行して、問題を検出および解決します。
症状
VMware VM をバックアップするために Microsoft VSS inside VM スナップショット静止方式を使用している場合、バックアップに整合性がない可能性があります。これは特にアプリケーション（Exchange など）がインストールされた VM のバックアップで発生する可能性があります。
解決方法
回避策として、この問題が解決されるまで、VMware Tools スナップショット静止方式を使用し、さらに VSS ライタ MSSearch Service Writer および Shadow Copy Optimization Writer を VM のゲスト OS で無効にします。
ネットワーク アダプタ <<アダプタ名>> を仮想スイッチに接続できません。
症状
VM をバックアップする際、スナップショットを作成する前に、クラスタ化された VM に対してフェールオーバが発生します。これにより、バックアップ セッションで記録された Hyper-V ホストが VM 環境設定と一致しなくなります。
解決方法
ネットワーク アダプタを Hyper-V ホスト上の仮想スイッチに手動で接続するか、または［別の場所にリストアする］オプションを使用して VM を復旧し、VM のリストア環境設定を設定できます。
症状
1 つの仮想マシンのバックアップ ジョブはすでに完了しているにも関わらず、Hyper-V マネージャでは仮想マシンのステータスがまだ「バックアップ」になっています。そのため、その時点でこの VM に対する別のバックアップ ジョブが開始された場合、「この仮想マシンの処理中に Hyper-V VSS ライタでエラーが発生しました」というエラーで失敗します。さらに、その時点では Hyper-V マネージャでの VM の電源オン/オフなど、いくつかの操作を実行できません。VM が Hyper-V クラスタである場合、その VM に対してライブ マイグレーションを実行できません。
この問題は、以下の状況で発生します。
解決方法
VM が「ロック状態」であっても、ゲスト OS は通常どおり使用できます。したがって、この問題はゲスト OS の使用/可用性には影響しません。ただし、このような状況を懸念し、それを回避したい場合は、以下のいずれかを実行します。
症状
これは、変更ブロックのトラッキング（CBT）に関する VMware の既知の問題です。アプリケーション レベルの静止で、変更ブロックのトラッキングにより変更が誇張されます。
解決方法
この問題は、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 KB 記事 2055943 を参照してください。
症状
バックアップ ソース VM には 2-TB を超える VMDK があり、バージョン 5.5 未満の ESX/ESX（i）サーバは、ディスク サイズが最大 2-TB の仮想ディスクのみをサポートします。ただし、VM 復旧中に以下のエラーが発生する場合があります。
解決方法
これは、VMware の制限事項です。バージョン 5.5 未満の VMware ESX/ESX（i）サーバがサポートする最大サイズは 2 T-16 GB （2032 GB）です。
大容量のディスクで変換を実行するには、デスティネーションとして VMware ESX（i）サーバ 5.5 を使用することをお勧めします。
詳細については、VMware KB 記事 1012384 を参照してください。
症状
7 つを超える VMDK を持つ SCSI コントローラが含まれる仮想マシン上でバックアップ ジョブを実行する場合、バックアップ ジョブは失敗します。スナップショットを作成するために VMware では特定の SCSI コントローラ上に VMDK 用に最大数の空きスロットを必要とするため、バックアップジョブは失敗します。SCSI コントローラは最大 15 スロットを持つことができます。たとえば、SCSI コントローラに 7 つの VMDK がある場合、スナップショットは各 VMDK に対して作成できます（合計 14 のスロットが使用され、空きスロットが 1 つ残ります）。SCSI コントローラに 8 つの VMDK がある場合、使用可能なスロットが 15 しかないため、スナップショットを作成できず、バックアップ ジョブは失敗します。
注：手動でのスナップショット作成も失敗します。
解決方法
単一の SCSI コントローラ上に 7 つを超えるディスクを持つ仮想マシンについては、以下の手順に従います。
各 VMDK に対してスナップショットを作成できるようになります。
この問題は、Arcserve Backup がバックアップでサポートできる VMDK ディスクの数が最高で 7 つであるという VMware の制限によるものです。
詳細については、次の VMware Knowledge Base 記事を参照してください。http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2015181
この問題を解決するには、Central Protection Manager から古い VM を削除し、新しい VM をインポートします。
症状
これは、E1000 および E1000e 仮想ネットワーク アダプタを使用する ESXi 5.0、5.1、5.5 ホストおよび仮想マシンに影響する、VMware の既知の問題です。
注：この問題は、以下の VMware 更新で解決されます。
解決方法
VMXNET3 アダプタに切り替えます。詳細については、VMware KB 記事 2059053 を参照してください。
症状
VM がノード ビューにインポートされる場合、同じ VM インスタンス UUID を持つ別の VM がノード ビューにすでに追加されていると失敗します。
症状
Host-Based VM Backup プランに、以前のリリースの Arcserve D2D （たとえば r16.5）がインストールされているプロキシ マシンが含まれている場合、そのプランを保存すると「ディスパッチ メソッドが見つかりません」という内容のエラー メッセージが表示されます。
解決方法
この問題は、現行バージョンの API が旧バージョンの Arcserve D2D の API と互換性がないために発生します。回避策として、Arcserve D2D を Arcserve UDP エージェント（Windows） の現行バージョンに手動でアップグレードできます。
症状
Host-Based VM Backup ジョブが数時間ハングし、次に進めません。
解決方法
アクティビティ ログ内のプロセス ID を参照して、afbackend.exe を終了し、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 VM をバックアップした後、iSCSI デバイス上のボリュームはリストア UI でリスト表示されません。
解決方法
Arcserve UDP にエージェント ベースのバックアップ プランを作成するか、または Arcserve UDP エージェント（Windows） エージェントを使用して、その仮想マシンをバックアップします。
症状
Hyper-V VM でのホスト ベース エージェントレス バックアップ ジョブでは、ゲスト オペレーティング システムが Windows Server 2003 である場合、実行前/後コマンド実行できません。アクティビティ ログには次の警告が出力されます： 「仮想マシンに予期しない名前が指定されています。実行前/実行後コマンドを実行できません。」
解決方法
Windows Server 2008、Windows Vista、または以降のオペレーティング システムのバージョンではこの問題は発生しません。これらのオペレーティング システムを使用してください。
症状
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.0 では、VMWare VDDK 6.0.1 が組み込まれていますが、VDDK 6.0.1 は Windows 2003 R2 を正式にサポートしていません。回避策として、以下のいずれかのオプションを使用できます。
Arcserve UDP で組み込みバージョン（6.0.1）以外の異なる VDDK バージョンを適用する方法
症状
ESX 情報を使用してログインし、リソース プールをインスタント VM の場所として選択した場合、インスタント VM がリソース プールではなく ESX ホストの下に配置されます。インスタント VM をコンソールから削除し、同じ名前でインスタント VM を再作成した場合、インスタント VM のタイムスタンプに追加されるべきサフィックス (1) が名前に追加されます。
解決方法
これは、ESX Server が vCenter によって管理されているためです。vCenter のログイン情報を使用してインスタント VM を作成します。
症状
インスタント VM を起動し、Hyper-V 復旧サーバを再起動した後、インスタント VM を起動できない可能性があります。
解決方法
このブート問題を解決するには、インスタント VM を再起動します。
症状
Windows ボリュームが NFS 共有フォルダとして割り当てられており、この共有ボリューム パスがインスタント VM ファイルのパスとして指定されています。Windows ボリュームをフォーマットし、インスタント VM を作成しようとすると、インスタント VM の作成に失敗します。ESXi ホストが NFS データ ストアを追加できないため、インスタント VM の作成が失敗します。VMware は、以下の内容のエラー メッセージを表示します。
VMware で VM の作成が失敗しました。
vmkernal.log ファイルには、以下のエラー ログが表示されます。
No underlying device for major, minor
解決方法
この問題を解決するには、復旧サーバで以下の手順を実行します。
［管理ツール］ダイアログ ボックスが表示されます。
［サービス］ダイアログ ボックスが表示されます。
インスタント VM が作成されます。
NodeName が VM （ホスト名）である場合、ログ フィルタは動作しません。［ログの表示］リンクをクリックするとログ ビューがロードされます。
症状
ログ ビューでは、保護されている VM にホスト名がない場合、その NodeName 値は「VM （ノード名）」として表示されます。この場合、その他のフィルタは作動しません。
解決方法
手動で VM(ホスト名) からホスト名に NodeName を変更できます。その後、すべてのフィルタが正常に機能します。たとえば、NodeName "VM(xxxxx01-AB)" を "xxxxx01-AB" に変更します。
インストールのマウンティング ドライバが、デバッグ ログにエラー コード 1460 を生成して失敗します。
症状
Windows セットアップ API がエラー 1460 を報告します。このエラーは、タイムアウト期間が過ぎたことを意味します。デバイス ドライバの更新では、デフォルト タイムアウト値は 300 秒です。
解決方法
タイムアウト値を調整するには、以下の手順に従います。
Exchange データベース リストアが失敗し、次のエラー メッセージが表示されます。「マウントできませんでした。」
症状
Exchange サーバが VM 内にインストールされ、その VM を保護するために Arcserve UDP エージェント（Windows） を実行している場合に、この問題が発生します。バックアップがしばらくの間実行された後、VM が以前に保存された VM スナップショットに戻された場合、Exchange データベースを元の場所に回復しようとすると、「Exchange ストレージ グループ/データベース［DB_Name］はその元の場所にリストアされましたが、マウントに失敗しました」というエラーでリストアは失敗します。
根本原因はまだ調査中ですが、現時点では、Exchange データベースおよび最新のトランザクション ログ ファイルの内部で記録されたタイム スタンプに関連していると思われます。
解決方法
Exchange データベースを代替ディレクトリに回復してみてください。または、データベースをマウント解除し、デスティネーション フォルダ内のファイルをすべて削除してから、リストアを実行してみてください。
Microsoft SQL Server がより多くのメモリを割り当てることができない場合、Arcserve UDP コンソールの応答が遅くなることがあります。
症状
特に Arcserve UDP データベースに過剰なデータがある場合、Microsoft SQL Server は、照会を処理するためにより多くのメモリを割り当てることが必要になる場合があります。しかし、Microsoft SQL Server が利用可能なメモリの不足または設定されている上限のためにメモリを取得できない場合、照会処理が非常に遅くなり、そのために Arcserve UDP コンソールの応答に影響を及ぼします。
解決方法
［ログ］ - ［削除］を使用してデータベースから一部のログを削除した後、SQL Service を再起動します。
症状
マージ ジョブを手動でサブミットすると、ジョブが実行されず、以下のメッセージがアクティビティ ログに表示されます。
<ノード名> に対してマージ ジョブを実行できず、別のジョブが実行されています
解決方法
このエラーの原因として、同じ復旧ポイント サーバで異なるデータ ストアにあるノードに対して他のジョブが実行されていることが考えられます。この問題を回避するには、実行中のジョブが完了するまで待機し、再試行します。
症状
バックアップまたはレプリケーション ジョブが、「指定されたファイルが見つかりません」というエラーによって失敗します。
Windows イベント ログを確認します。McAfee が、データ ストア ファイル（P0000000042.data など）をトロイの木馬ウイルスの Exploit-ScriptNull として検出し、削除しています。
解決方法
アンチウイルス設定の除外リストに復旧ポイント サーバ（RPS）のデータ ストアの場所を設定します。
注：一部のアンチウイルス ソフトウェアについては、サーバ側で除外リストを設定する必要があります。
症状
かなり低い帯域幅へのネットワーク スロットルを設定した場合、または、デスティネーション RPS サーバへのネットワーク スループットが遅い場合に、この問題が発生します。そのため、キューに入っているデータが送信されるのを待機するのに数分かかる可能性があります。
解決方法
レプリケーション ジョブが正常に終了するのを待ちます。
症状
ユーザ アカウント制御（UAC）をサポートする Windows オペレーティング システム（Windows Vista 以降）で IP アドレスまたはノード名によってノードを追加しようとする場合、または UAC をサポートする Hyper-V サーバから仮想マシンをインポートしようとする場合、組み込み管理者ではなく、管理者グループに含まれるローカル アカウントである新しい Windows ユーザ アカウントを使用していると、以下のメッセージが表示されます。
「管理者権限が必要です。」
解決方法
組み込みの管理者またはドメイン管理者のアカウントを使用します。または、リモート UAC を無効にすることもできます。
これは、UAC の「リモート制限」と呼ばれるデフォルトの Windows の動作です。このアカウントでノードを追加する場合は、以下の手順を実行して リモート UAC を無効にします。
Windows レジストリ エディタが開きます。
注：Windows レジストリ エディタを開くには、管理者の認証情報の指定が必要になる場合があります。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Windows の動作の詳細については、Microsoft サポート技術情報 http://support.microsoft.com/kb/951016 を参照してください。
症状
ノード用のハイパーバイザ機能の削除はこのリリースでは提供されていません。
解決方法
そのノードを削除し、再度それを追加します。
症状
Arcserve UDP 内のオール イン ワン UI では、ユーザが複数の Arcserve UDP コンソールを持つことは想定されていません。そのため、あるサーバから別のサーバにエージェントを移動させるシナリオが発生するのは、古いサーバが廃止される場合だけです。
解決方法
あるコンソールから別のコンソールにノードを移動させることは非常にまれなシナリオです。
バックアップ先が Windows Server 2012 上のデデュプリケート可能な NTFS ボリュームで、Arcserve UDP エージェント（Windows） が Windows Server 2003 にインストールされている場合、リストア、マージ、またはカタログ ジョブが失敗する可能性があります。ジョブは Windows エラー コード 50 で失敗し、「リクエストはサポートされていません」というメッセージが表示されます。
症状
マカフィーまたは別のサードパーティ ソフトウェアが Windows Server 2012 にインストールされている場合は、レジストリで EnableECP=1 に設定されています。
解決方法
レジストリで、EnableECP の値を「1」から「0」へ変更します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanManServer\Parameters
詳細については、http://support.microsoft.com/kb/2817216 を参照してください。
症状
2 番目のレプリケーション ジョブは、準備ステータスでハングし、10 分後に失敗します。
解決方法
実行が必要な操作は特にありません。2 番目のレプリケーション ジョブが失敗した後、対応するメークアップ ジョブがトリガされます。
症状
レプリケーション（イン）ジョブが失敗し、アクティビティ ログには、「<パス> 上のセッションをロックすることに失敗しました」というメッセージが表示されます。セッションはすでにファイル コピー ジョブによってロックされていました（コンピュータ名：<名前>、プロセス ID <ID>）。これは、ファイル システム カタログ ジョブでのバックアップが有効になっている場合に、レプリケーション ターゲットのデータ ストアからファイル コピー ジョブを実行するように設定すると発生します。
解決方法
ファイル コピー ジョブがセッションをロックするため、レプリケーション ジョブを実行できません。解決するには、以下のいずれかのオプションを使用できます。
症状
リストア ジョブの後、以下の項目プロパティが正しくリストアされていない可能性があります。
解決方法
見つからない項目をリストアするには、PST へのエクスポート オプションを使用します。
症状
この問題は、以下の状況で発生する可能性があります。
解決方法
これらの状態を解決するには、以下の解決方法のいずれかを実行して問題に対応します。
症状
Update 4 またはそれ以前のバージョンのエージェントを使用する場合は、以下のエラーが発生します。
Exchange ストレージ グループ/データベースが元の場所にリストアされましたが、マウントできませんでした。
解決方法
エージェントを Arcserve UDP エージェント バージョン 6.0 にアップグレードします。
症状
リストア先がリモート共有フォルダ（\\FileServer\ShareFolder\RestDest など）で、バックアップ先が同じパスのリモート共有フォルダ（\\FileServer\ShareFolder\RestDest など）である場合、エラーが発生します。
ルート共有フォルダへの接続に使用されるユーザ アカウントが許可リストに含まれていない場合、リストア先フォルダに対してどのアカウントを使用しても、リストア ジョブは失敗します。
解決方法
接続を確立するためにバックアップ先に対して割り当てられているユーザ アカウントを、ルート共有フォルダの許可リストに追加します。また、そのユーザ アカウントがファイルをリストアするための適切な権限を持っていることを確認します。
ユーザ アカウントをバックアップ オペレータ グループに追加します。また、そのユーザ アカウントがセキュリティ制限を無効にする権限を持っていることを確認します。
症状
復旧ポイントに対して暗号化が有効な場合、現在のサーバからバックアップされた復旧ポイントに対してはパスワードを入力する必要はありません。ただし、Windows OS をアップグレード（たとえば Windows Server 2008 から Windows Server 2008 R2 に）した場合、パスワードは Arcserve UDP エージェント（Windows） ユーザ インターフェース上で自動的に入力されないため、パスワードを再入力する必要があります。
解決方法
復旧ポイントの暗号化パスワードまたはセッション パスワードを記録し、取り出しやすく安全な場所に保管してください。
症状
VMware 仮想マシンをリストアする際に、以下のエラーが発生します。
このファイルへのアクセス権がありません。詳細については、リストア デバッグ ログを参照してください。必要に応じて Arcserve サポートまでお問い合わせください。
リストア デバッグ ログで以下のログ エントリを参照できます。
[VDDKLOG] CnxAuthdConnect:Returning false because SSL verification requested and target authd does not support SSL
[VDDKLOG] CnxConnectAuthd:Returning false because CnxAuthdConnect failed
[VDDKLOG] Cnx_Connect:Returning false because CnxConnectAuthd failed
[VDDKLOG] Cnx_Connect:エラー メッセージ：SSL が必要
解決方法
このエラーの原因は、VMware ESX ホスト上で SSL 認証が無効になっていることです。このエラーを解決するには、以下のいずれかの方法を使用します。
config.defaults.security.host.ruissl
/etc/vmware/config
SSL 認証が有効になります。
ログの参照中に、サーバ接続エラーが表示されます。
症状
ユーザがエージェントまたはコンソールからアクティビティ ログを参照する場合、以下のエラーが表示される可能性があります。
「サーバ 'arcservedocs.com' に接続できませんでした。」
解決方法
このメッセージは無視してください。
症状
ノードは RPS データ ストアにバックアップされ、別の RPS データ ストアにレプリケートされます。さらに、レプリケーションのソースで仮想スタンバイ マシンが作成されます。プランの展開後に、仮想スタンバイ ジョブの古いセッションがある場合は、仮想スタンバイを直接再開できます。しかし、ジョブをサブミットした後、仮想スタンバイ ジョブが開始されません。
解決方法
この問題を解決するには、手動のレプリケーションを最初に実行します。ノードを右クリックし、［今すぐレプリケート］をクリックします。レプリケーションが完了した後、仮想スタンバイ ジョブを再開します。
症状
仮想スタンバイ ジョブが以下のエラーで失敗します。
ディスク シグネチャを取得できません（シグネチャは空です）
解決方法
Arcserve UDP バージョン 6.0 では、VMWare VDDK lib がバージョン 5.5 からバージョン 6.0 にアップグレードされました。VDDK v6 では、VDDK lib を初期化するために、指紋用の新しいフィールドが必要です。VSB コンバータからのコールは、指紋がない Arcserve UDP バージョン 5.0 に基づいています。これにより、コンバータからモニタへのコールが失敗します
この問題を解決するには、コンバータを Arcserve UDP バージョン 6.0 に更新します。
症状
Arcserve UDP エージェント（Windows） は Arcserve UDP RPS データ ストアにバックアップされ、RPS は Arcserve UDP 6.0 にアップグレードされます。また、Arcserve UDP エージェント（Windows） は共有フォルダにバックアップされ、エージェントは Arcserve UDP 6.0 にアップグレードされます。Hyper-v への仮想スタンバイ VSB ジョブが失敗し、以下のエラーが表示されます。
{http://webservice.arcflash.com}IsVmFileExist に対するディスパッチ方法が見つかりません。
または
{https://webservice.arcflash.com}IsVmFileExist に対するディスパッチ方法が見つかりません。
解決方法
Hyper-V サーバ上で Arcserve UDP エージェントを Arcserve UDP 6.0 にアップグレードします。
この動作のもう 1 つの原因は、「読み取り専用」ボリュームが含まれる仮想マシンの電源をオンにすることです。この状況を修正するには、書き込み可能な状態のディスクにボリュームを配置します。
復旧ポイントの情報を取得することに失敗しました。
この動作は、最新のスナップショットを使用して V2P 復旧を実行した場合で、仮想スタンバイ タスクがノードに再展開された後、ノードの変換ジョブが完了しなかったときに発生します。
解決方法
解決方法
Arcserve UDP エージェント ベア メタル復旧を使用して V2P 復旧を実行します。
注：この制限は、Hyper-V サーバ上で実行されている仮想スタンバイ ジョブのみに適用されます。
症状
Arcserve UDP エージェント（Windows） には 2-TB のディスクがあり、バージョン 5.5 未満の ESX/ESX（i）サーバは、ディスク サイズが最大 2-TB の仮想ディスクのみをサポートします。ただし、変換中に以下のエラーが発生する場合があります。
解決方法
これは、VMware の制限事項です。バージョン 5.5 未満の VMware ESX/ESX（i）サーバがサポートする最大サイズは 2 T-16 GB （2032 GB）です。
大容量のディスクで変換を実行するには、デスティネーションとして VMware ESX（i）サーバ 5.5 を使用することをお勧めします。
詳細については、VMware KB 記事 1012384 を参照してください。
症状
プランの展開が失敗し、次のエラー メッセージが表示されます。「Unable to apply 'Virtual Standby settings' to node 'xxx'.（xxx からモニタ xxx に接続できませんでした。ユーザ認証情報が無効です）」
解決方法
そのプラン内の仮想スタンバイ タスクを編集し、モニタに正しいパスワードを入力し、プランを保存します。
VMware VM のエージェントレス バックアップに対してカタログ生成が失敗する
症状
VM ゲスト OS の内部の VMware または Microsoft によって引き起こされる VSS スナップショットの問題により、VMware VM のエージェントレス バックアップ用のカタログ生成は、次のメッセージで失敗する可能性があります。
「インデックス ブロックを正しいボリューム ブロックにマップできませんでした。IndexAlloc エラーが発生しました」
解決方法
注：この問題はまれにしか発生しません。詳細については、VMware KB 記事 2006849 または Microsoft KB 記事 2853247 を参照してください。
ファイル コピー/アーカイブのジョブが起動しません。
症状
ファイル コピー/アーカイブのジョブが起動しません。
解決方法
まれに、復旧ポイントを指すために使用されるファイルをファイル コピー/アーカイブ用に保持する必要があり、ファイル コピー/アーカイブのジョブが完了した後に削除できない場合があります。そのようなファイルの名前は、特定のノードのバックアップ先フォルダの下に *.alck ファイルとして保存され、ファイル サイズはゼロになります。回避策として、これらのファイルを確認して手動で削除できます。
症状
デスティネーション ボリュームが FAT32 ファイルシステムの場合、“Arcserve Backup” または “Arcserve High Availability” コンポーネントを単一インストーラからダウンロードできません（ASDownloader.exe を使用）。パッケージのファイル サイズが FAT32 ファイル システムでサポートされている 4 GB の制限を超えているためです。
解決方法
回避策として、NTFS ボリュームをダウンロードできます。
Arcserve UDP アプライアンス上で Arcserve UDP v6 にアップグレードした後、Arcserve UDP コンソールの［設定］タブに［ファクトリ リセット］が表示されます。［ファクトリ リセットを実行］をクリックしてファクトリ リセットを実行しようとした場合、［ファクトリ リセットの確認］ダイアログ ボックスの［リセット］をクリックすると、次のエラー メッセージが表示されます。
アプライアンス ファクトリのリセットに失敗しました。以下のコマンドを使用して、アプライアンス ファクトリを手動で再設定します：C:\Program Files\Arcserve\Unified Data Protection\Management\Appliance パスの下の cmd で "powershell.exe .arcserve_factoryreset.ps1 –perserve_data –auto_reboot " を実行します。
注：このエラー メッセージは正しくありません。UDP v6 にアップグレードするアプライアンス ユーザの場合、アプライアンス マシン上に Arcserve UDP 復旧パーティションがないため、ファクトリ リセットはサポートされていません。
アプライアンスで Linux バックアップ サーバを使用している場合、Linux 復旧ポイントに対するインスタント VM はアプライアンス上でサポートされていません。
症状
Linux インスタント VM ジョブが失敗し、次のエラー メッセージが表示されます。
VM $vmname から IP アドレスを取得できませんでした。VM およびバックアップ サーバが同一ネットワーク上にあることを確認してください。
解決方法
この失敗は、インスタント VM ジョブで作成されたスタンバイ VM が原因です。Appliance_hostname:8018 によって Linux バックアップ サーバをコンソールに追加しましたが、Appliance_hostname:8014 によって Linux バックアップ サーバに接続しようとしています。アプライアンス マシン上では、ポート 8014 は UDP Windows エージェント サービスによって監視されているため、インスタント VM ジョブは失敗します。
Linux インスタント VM ジョブに対して静的 IP を解決する回避策を使用できます。
次の手順に従ってください：
"netstat -aon|findstr "port" " を使用して、ポートが使用されているかを確認できます。
注：Arcserve UDP v6 をアップグレードしている場合、UDP アプライアンス マシン上のポート 8018 は Linux バックアップ サーバ 8014 にリダイレクトするよう設定されています。以下のコマンドを使用して、UDP アプライアンス マシン上で 8018 を解放します。
netsh interface portproxy delete v4tov4 listenport=8018
注：ファイルが存在しない場合は作成します。 以下のコマンドを実行して、Linux バックアップ サーバを再起動します。
/opt/Arcserve/d2dserver/bin/d2dserver restart
#iptables -A INPUT -p tcp --dport 8018 -j ACCEPT
#iptables -A INPUT -p tcp --dport 8035 -j ACCEPT
#/etc/init.d/iptables save
netsh interface portproxy add v4tov4 listenport=8018 connectaddress=192.168.10.2 connectport=8018 protocol=tcp
netsh interface portproxy add v4tov4 listenport=8035 connectaddress=192.168.10.2 connectport=8035 protocol=tcp
C:\Program Files\Arcserve\Unified Data Protection\Engine\BIN\Appliance
netsh interface portproxy add v4tov4 listenport=8018 connectaddress=$VMIp connectport=8018 protocol=tcp
netsh interface portproxy add v4tov4 listenport=8035 connectaddress=$VMIp connectport=8035 protocol=tcp
重要：この回避策は、以下のオプションには適用されません。
Copyright © 2015 Arcserve. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.