
したがって、仮想マシン(VM)のディスクを完全に復元する必要がある場合にできること:まず、インスタントリカバリ( インスタントVMリカバリ )を使用してから、VMデータを運用環境にコピーできます。 このシナリオでは、バックアップストレージが使用されることに注意する必要があります。これは、通常、技術仕様では運用ネットワークにあるストレージよりも劣っています。 主な優先順位が回復速度であり、中間テストをバイパスして、マシンを元の状態に直接復元する準備ができていると仮定します。 このシナリオでは、新しいVeeam Backup&Replication v8.0の機能が役立ちます。これは、VM を元の場所に復元するときに使用できるFull VM Restoreスクリプトのクイックロールバックオプションです。 このオプションは、VMディスク上の増分変更のみ(通常の場合のようにディスク全体ではない)をロールバックすることを示します。
このチェックマークは何をしますか?
ディスク全体を復元する代わりに、Veeam Backup&Replicationは、VMを選択したリカバリポイントの状態に戻すために必要なブロックのみを復元します。 指定されたリカバリポイントの作成以降に変更されたデータブロックのみがコピーされるため、リカバリ時間が大幅に短縮されます。 変更されたブロックを識別するために、Veeam Backupは増分バックアップを作成するときと同じ変更ブロック追跡(CBT)追跡技術を使用します。
- VMwareプラットフォームの場合-vSphere APIに対してリクエストが行われます
- Hyper-Vプラットフォームの場合-独自のコンポーネント(Veeam CBTエンジン)から同様の情報が提供されます
リカバリポイントが作成された時点からVMの現在の状態までの変更された仮想ディスクブロックのリストを取得すると、Veeam Backupは、どのポイントで変更され、どのブロックをディスクに復元して目的の状態にロールバックする必要があるかを正確に決定します。
シンプルな機能のようですが、さまざまな状況で非常に便利です。 たとえば、あるユーザーは、自分の仮想マシンがトロイの木馬の被害者になったとき、マルウェアを苦しめようと時間を無駄にしないことを決めたが、 クイックロールバックから回復しようとした-回復するのに数秒しかかからなかったと言いました。
そのため、コンソールでフルVM復元ウィザードを起動し、 復元モードを選択するステップに進みます 。
デフォルトでは、復元は元の場所に行われます(元の場所に復元するオプションが選択されています)。 この場合、 クイックロールバックオプションを選択できます。オンにして、次の手順に進みます。

Veeam Backupの機能:元のVMがまだ動作している場合はオフにし、変更されたブロックのみの復元を開始します。
通常のフルVMリカバリと比較してパフォーマンスがどのように変化するかを見てみましょう。

20 GBのVMDKのうち、2.2 GBが効果的に使用されています。 VMを完全に復旧する通常のシナリオ(左の例)では、2.2 GBをすべて復元する必要がありました(1分8秒かかりました)。 クイックロールバックを使用して同じマシンを復元し始めたとき(右の例)、29 MBのみを復元する必要がありました(12秒かかりました)。
テラバイトのディスクを搭載したマシンでこのオプションを使用した場合の効果はさらに明白になると考えられます。
クイックロールバックは、Veeam Backup Enterprise Manager Webコンソールから「1クリックで」VMを復元するときにも使用できることに注意してください(これは、VMを元の場所に完全に復元する組み込みスクリプトにすぎません)。

落とし穴はありますか?
これについて話しましょう。 前述のように、 クイックロールバックは修正ブロック情報(CBT)を使用します。 ただし、多くの緊急事態でこの情報を100%信頼できると見なすことはできません。 そのため、このオプションはデフォルトで無効になっています。 ユーザーは、ゲストOSレベルでの問題が復旧の必要性につながった場合にのみ使用することを強くお勧めします。
原因がハードウェアレベルの問題(たとえば、ホストまたはストレージシステム)または突然の電圧降下である場合、クイックロールバックの使用は安全ではありません -そのような状況では、SVTデータが歪む可能性が高く、間違ったブロックのリカバリを開始してVMディスクを台無しにするリスクがあります。
許容可能な場合のクイックロールバックの使用に関するいくつかの制限を忘れてはなりません。
- マシンの復元元となるバックアップコピーが、CBTトラッカーをオンにして作成されたことを確認します。 これを行うには、バックアップジョブウィザードの[ ストレージ]ステップで[ 詳細設定 ]ボタンをクリックし、対応するプラットフォームのタブに移動します( VMwareおよびHyper-Vの詳細 )。
- 次から次へと2つの増分復元を実行することはできません。 最初の回復が行われた後、ソースVMのCBTトラッカーが「リセット」され、増分回復を再度実行できるように少なくとも1つの増分バックアップパスが必要になります。
- VMwareの増分リカバリでは、ネットワークまたは仮想アプライアンスの2つのデータ転送モードのみを使用します。 このシナリオでは、直接SANアクセスモードを有効にできません。
ここで示した簡単な推奨事項により、 クイックロールバックを使用して仮想マシンを効率的に回復できるようになることを願っています。