この記事では、仮想マシンのリテンション期間のしくみについて説明します。 バックアップが行われるたびに、復元操作を実行できる場所から復旧ポイントが作成されます。
仮想マシンの場合、初回バックアップは完全バックアップであり、後続のバックアップは増分バックアップです。
復旧ポイントとリテンション期間
スケジュールされた初回および増分バックアップ
ブロック 1、ブロック 2、ブロック 3、ブロック 4 の 4 つのブロックで構成されるデータ ディスクを備えた仮想マシン V1 の簡略化された例を見てみましょう。 各ブロックのサイズは 16 KB です。
手順 1 -Initial バックアップ: 初期バックアップは完全バックアップです。 これは、後続の増分バックアップが適用される際のベースラインの役割を果たします。 ソース VM 上のブロック 1 とブロック 2 にデータが書き込まれるとします。 同じデータが D1 および D2 として Recovery Services コンテナー ストレージにレプリケートされます。
手順 2 -Incremental バックアップ 1: VM のブロック 3 に新しいデータが追加されたとします。 同じデータが次の増分でレプリケートされ、変更されたブロックのみが D3 として保存されます。 各手順では、ブロックの変更が 1 KB であっても、16 KB のブロック全体が復旧ポイントにアップロードされます。
手順 3 -Incremental バックアップ 2: 次に、ソース VM のブロック 3 とブロック 2 にデータの変更があるとします。 これらの変更は、次の増分バックアップで D3' および D2' としてレプリケートされます。
オンデマンド バックアップ
VM に対する保護を設定した後であれば、いつでもそのオンデマンド バックアップの実行を選択できます。
- 最初のスケジュールされた初回バックアップの前にトリガーされた場合は、オンデマンド バックアップは完全バックアップになります。
- 初回バックアップが完了した後にオンデマンド バックアップがトリガーされた場合、それは増分バックアップになります。
- オンデマンド バックアップで作成された復旧ポイントのリテンション期間は、バックアップをトリガーするタイミングを指定するリテンション期間の値です。
ストレージ費用
初期バックアップ用に作成された 復旧ポイント には、データを含むすべてのブロックが含まれています。 後続の増分復旧ポイントは、データが変更されたブロックのみで構成されます。 ストレージのコストは、すべての復旧ポイントにまたがるすべてのブロックの合計に対応します。
上記の例を使用して、各手順の後のストレージ コストを把握してみましょう。
| 手順 | バックアップの種類 | 変更されたブロック | ストレージの種類 |
|---|---|---|---|
| 1 | 初回バックアップ | ブロック 1、ブロック 2 | 復旧ポイント 1 (D1 および D2) に対応 |
| 2 | 増分バックアップ 1 | ブロック 3 | 復旧ポイント 1 (D1 および D2) と復旧ポイント 2 (D3) に対応 |
| 3 | 増分バックアップ 2 | ブロック 2、ブロック 3 | 復旧ポイント 1 (D1 および D2)、復旧ポイント 2 (D3)、復旧ポイント 3 (D2' および D3') に対応 |
復旧ポイントの有効期限
各復旧ポイントには、バックアップ ポリシーで指定されたリテンション期間があります。 一定の間隔でクリーンアップが行われ、有効期限が切れた復旧ポイントはすべてクリーンアップされます。
復旧ポイントは有効期限が切れると削除またはマージされます。
ケース 1: 最初の復旧ポイントの有効期限切れ
初回復旧ポイントは、有効期限が切れると次の増分復旧ポイントにマージされます。 増分復旧ポイントで上書きされたすべてのデータ ブロックは削除され、残りはマージされます。 その後、その増分バックアップが初回完全バックアップになります。 例を見てみましょう。
- 初期バックアップ中に作成された復旧ポイント 1 には、VM の完全バックアップがあります。
- 復旧ポイント 1 の有効期限が切れると、復旧ポイント 2 が次の完全バックアップになります。
- ブロック D1 は 復旧ポイント 2 とマージされ、ブロック 2 のデータは復旧ポイント 2 で上書きされるため、 D2 は削除されます。 この変更はブロック D2' としてキャプチャされます。
- ブロック D1 は後続の復旧ポイントでそのまま保持されます (次のバックアップの前にそこに変更が加えられるまで)。
ケース 2: 増分復旧ポイントの間のポイントの期限切れ
- 復旧ポイント 2 が復旧ポイント 1 より前に期限切れになった場合、復旧ポイント 2 のデータは、次に使用可能な復旧ポイント (復旧ポイント 3) とマージされます。 そのため、ブロック D3 は 復旧ポイント 3 とマージされます。
- 復旧ポイント 1 は、ブロック D1 と D2 を使用した完全バックアップです。
- イン間の増分復旧ポイントの有効期限が切れると、Azure Backupは、後続の保持された復旧ポイントで上書きされたデータ ブロックのみを解放します。
- 上書きされないデータ ブロックは、増分チェーンを維持するために必要であり、次に使用可能な保持復旧ポイントに転送 (マージ) されます。
- この動作により、ストレージの削減は段階的に行われ、1:1 が期限切れの復旧ポイントの数にマップされない場合があります。
ケース 3: オンデマンドの復旧ポイントの有効期限切れ
この例では、スケジュール (毎日のバックアップ) ポリシーが n 日間の保有期間で実行されるようにスケジュールされています。 保持期間が 10 日間に指定されている場合に、スケジュールされた次のバックアップの前である 4 日目にオンデマンド バックアップがトリガーされると、それは依然として増分バックアップになります。 復旧ポイント (オンデマンド RP1) は、 復旧ポイント 3 の後、および 復旧ポイント 4 より前に作成されます。 14 日目の終わりに、オンデマンド復旧ポイント (オンデマンド RP1) の有効期限が切れ、次に使用可能な復旧ポイントとマージされます。 サーバー上にまだ存在するデータ ブロックはマージされますが、変更 (上書きまたは削除) されたデータ ブロックは有効期限が切れた復旧ポイントから削除されます。
復旧ポイントに対するポリシーの変更の影響
ポリシーは変更されると、新規と既存の両方の復旧ポイントに適用されます。 詳細については、「 復旧ポイントに対するポリシー変更の影響」を参照してください。
復旧ポイントに対する保護の停止の影響
VM の保護を停止するには、次の 2 つの方法があります。
- 保護を停止してバックアップ データを削除する。 このオプションでは、将来のすべてのバックアップ ジョブによる VM の保護を停止し、すべての復旧ポイントを削除します。 論理的な削除が有効になっている場合、削除されたデータは 14 日間保持されます。 論理的に削除された状態の項目に対しては、料金が発生しません。 14 日間の期間内であれば、データの削除を取り消すことができます。 論理的な削除が有効になっていない場合、データはすぐにクリーンアップされ、VM を復元したり、 バックアップの再開 オプションを使用したりすることはできません。
- 保護を停止してバックアップ データを保持する。 このオプションを選択すると、今後のすべてのバックアップ ジョブで VM が保護されなくなります。 ただし、Azure Backup サービスは、バックアップされた復旧ポイントを永続的に保持します。 保管庫に復旧ポイントを保持するには、支払いが必要です (詳細については、Azure Backup の価格をご覧ください)。 必要な場合は、VM を復元することができます。 VM 保護を再開する場合は、[ バックアップの再開 ] オプションを使用できます。 バックアップを再開すると、リテンション期間ルールが有効期限に適用されます。 バックアップ データの削除オプションを使用して、 バックアップ データを削除 することもできます。
保護を停止せずに VM を削除した場合の影響
保護を最初に停止せずに仮想マシン (VM) を削除すると、復旧ポイントに影響を与える可能性があり、推奨されません。 VM を削除する前にバックアップを停止することが理想的です。 VM が削除された後は、それ以上のバックアップはトリガーされませんが、バックアップ項目は引き続き Recovery Services コンテナーで 正常 として表示されます。 削除後に手動バックアップが試行された場合、バックアップ ジョブは VM のチェックを強制し、 VMNotFoundV2 エラーで失敗します。 復旧ポイントはアイテム保持ポリシーに従って定期的にクリーンアップされますが、VM の最後のコピーは無期限に保持されます。
シナリオに応じて、次のオプションがあります。
VM を復元する: 使用可能な任意の復旧ポイントを使用して VM を復元できます。 継続性を確保するには、同じ名前を使用して VM を復元し、同じリソース グループに配置します。 その後、同じコンテナーを使用して復元された VM を保護すると、既存の復旧ポイントが自動的に再アタッチされます。
VM の保護を停止してデータを削除する: Recovery Services コンテナーに移動し、データの削除による保護の停止を選択できます。これにより、バックアップ項目と関連する復旧ポイントが削除されます。
注
VM が削除された後も、データの削除で保護が明示的に停止されない限り、最後の復旧ポイントは無期限に保持されます。 その結果、保持されているバックアップ データに対する課金が続行されます。 VM の保護を停止する方法について説明します。
論理的に削除された状態の項目における復旧ポイントの有効期限切れによる影響
回復サービス ボールトでソフト削除が有効になっている場合、期限切れの回復ポイントはソフト削除された状態にとどまり、削除されません。 復旧ポイントが論理的に削除された状態の場合、料金は発生しません。
バックアップ パフォーマンスに対する顧客離脱の影響
VM のストレージの合計が 8 TB で、チャーンが 5% であるとします。 その場合、対応する増分バックアップのストレージは、8 TB の 5% である 0.4 TB になります。 チャーンが高くなると、後続の増分バックアップのバックエンド ストレージが高くなります。 チャーンはバックアップ パフォーマンスに影響します。 チャーンが高くなると、バックアップ プロセスが遅くなり、バックエンド ストレージの使用量が大きくなります。
バックアップ パフォーマンスに対するチャーンの影響を理解するために、このシナリオをご確認ください。
| 仮想マシン | VM1 | VM2 | VM3 |
|---|---|---|---|
| データ ディスクの数 | 4 個 (A1、A2、A3、A4) | 4 個 (B1、B2、B3、B4) | 4 個 (C1、C2、C3、C4) |
| 各ディスクのサイズ | 4テラバイト (4 TB) | 4テラバイト (4 TB) | 4テラバイト (4 TB) |
| バックアップデータロス | A1 - 4 TB | B1 - 1 TB、B2 - 1 TB B3-1 TB、B4-1 TB |
C1 - 2 TB、C4 - 2 TB |
バックアップのパフォーマンスは、VM2>VM3>VM1 の順序になります。 これは、チャーンされたデータが別々のディスクに分散されることが理由です。 ディスクのバックアップは並列して行われるため、VM2 が最も優れたパフォーマンスを示します。
よく寄せられる質問
オンデマンド バックアップの保有期間はどのように確認できますか?
オンデマンド バックアップのバックアップ ジョブ の [回復ポイントの有効期限 (UTC) ] フィールドには、復旧ポイントの保有期間が表示されます。 詳細については、「 オンデマンド バックアップを実行する」を参照してください。