復旧ポイントの管理
この記事では、仮想マシンのリテンション期間のしくみについて説明します。 バックアップが行われるたびに、復元操作を実行できる場所から復旧ポイントが作成されます。
仮想マシンの場合、初回バックアップは完全バックアップであり、後続のバックアップは増分バックアップです。
復旧ポイントとリテンション期間
スケジュールされた初回および増分バックアップ
4 つのブロック (ブロック 1、ブロック 2、ブロック 3、ブロック 4) で構成されるデータ ディスクを備えた仮想マシン V1 をシンプルな例として取り上げましょう。 各ブロックのサイズは 16 KB です。
手順 1 - 初回バックアップ: 初回バックアップは完全バックアップです。 これは、後続の増分バックアップが適用される際のベースラインの役割を果たします。 ソース VM 上のブロック 1 とブロック 2 にデータが書き込まれるとします。 同じデータが D1 および D2 として Recovery Services コンテナー ストレージにレプリケートされます。
手順 2 - 増分バックアップ 1: VM のブロック 3 に新しいデータが追加されるとします。 同じデータが次の増分でレプリケートされ、変更されたブロックのみが D3 として保存されます。 各手順では、ブロックの変更が 1 KB であっても、16 KB のブロック全体が復旧ポイントにアップロードされます。
手順 3 - 増分バックアップ 2: 次は、ソース VM 上のブロック 3 とブロック 2 にデータの変更があったとします。 これらの変更は、次の増分バックアップで D3' および D2' としてレプリケートされます。
オンデマンド バックアップ
VM に対する保護を設定した後であれば、いつでもそのオンデマンド バックアップの実行を選択できます。
- 最初のスケジュールされた初回バックアップの前にトリガーされた場合は、オンデマンド バックアップは完全バックアップになります。
- 初回バックアップが完了した後にオンデマンド バックアップがトリガーされた場合、それは増分バックアップになります。
- オンデマンド バックアップで作成された復旧ポイントのリテンション期間は、バックアップをトリガーするタイミングを指定するリテンション期間の値です。
Storage コスト
初回バックアップで作成された復旧ポイントには、データを備えたブロックがすべて含まれています。 後続の増分復旧ポイントは、データが変更されたブロックのみで構成されます。 ストレージのコストは、すべての復旧ポイントにまたがるすべてのブロックの合計に対応します。
上記の例を使用して、各手順の後のストレージ コストを把握してみましょう。
| 手順 | バックアップの種類 | 変更されたブロック | ストレージの種類 |
|---|---|---|---|
| 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: 増分間の復旧ポイントの有効期限切れ
- "復旧ポイント 1" の前に "復旧ポイント 2" の有効期限が切れた場合、"復旧ポイント 2" のデータが、次に利用可能な復旧ポイントである "復旧ポイント 3" とマージされます。 ブロック D3 も "復旧ポイント 3" とマージされます。
- "復旧ポイント 1" は引き続き、ブロック D1 と D2 を使用した完全バックアップです。
ケース 3: オンデマンドの復旧ポイントの有効期限切れ
この例では、スケジュール (日単位のバックアップ) ポリシーが、n 日の保持期間で実行するようスケジュールされています。 保持期間が 10 日間に指定されている場合に、スケジュールされた次のバックアップの前である 4 日目にオンデマンド バックアップがトリガーされると、それは依然として増分バックアップになります。 復旧ポイント ("オンデマンド RP1") は、"復旧ポイント 3" の後で "復旧ポイント 4" の前に作成されます。 14 日目の最後に、オンデマンド復旧ポイント ("オンデマンド RP1") は有効期限が切れて、次の使用可能な復旧ポイントにマージされます。 サーバー上にまだ存在するデータ ブロックはマージされますが、変更 (上書きまたは削除) されたデータ ブロックは有効期限が切れた復旧ポイントから削除されます。
復旧ポイントに対するポリシーの変更の影響
ポリシーは変更されると、新規と既存の両方の復旧ポイントに適用されます。 詳細については、「復旧ポイントに対するポリシーの変更の影響」を参照してください。
復旧ポイントに対する保護の停止の影響
VM の保護を停止するには、次の 2 つの方法があります。
- 保護を停止してバックアップ データを削除する。 このオプションでは、将来のすべてのバックアップ ジョブによる VM の保護を停止し、すべての復旧ポイントを削除します。 論理的な削除が有効な場合は、削除されたデータが 14 日間保持されます。 論理的に削除された状態の項目に対しては、料金が発生しません。 14 日間の期間内であれば、データの削除を取り消すことができます。 論理的な削除が有効でない場合は、データがすぐにクリーンアップされます。VM を復元したり、バックアップの再開オプションを使用したりすることはできません。
- 保護を停止してバックアップ データを保持する。 このオプションを選択すると、今後のすべてのバックアップ ジョブで VM が保護されなくなります。 ただし、Azure Backup サービスによって、バックアップされている復旧ポイントが無期限に保持されます。 コンテナーの復旧ポイントを保持するには、料金を支払う必要があります (詳細については、Azure Backup の料金に関するページを参照してください)。 必要な場合は、VM を復元することができます。 VM の保護を再開する場合は、バックアップの再開オプションを使用できます。 バックアップを再開すると、リテンション期間ルールが有効期限に適用されます。 バックアップ データの削除オプションを使用して、バックアップされたデータを削除することもできます。
保護を停止せずに VM を削除した場合の影響
保護を停止せずに VM を削除すると、復旧ポイントに影響が生じます。これはシナリオとして望ましくありません。 仮想マシンを削除する前にバックアップを停止しておくのが理想的です。 リソースが存在しないため、スケジュールされたバックアップが VMNotFoundV2 というエラーと共に失敗します。 復旧ポイントはリテンション期間ポリシーに応じて定期的に消去されますが、仮想マシンの最後のコピーは無期限に維持され、それに応じてお客様に対する請求が発生します。 シナリオに応じて、次の 2 つのオプションがあります。
- オプション 1: 任意の復旧ポイントを使用して VM を復元します。 削除された VM を復旧したい場合は、同じ名前を使用して同じリソース グループ内で復元します。 復元された VM を同じコンテナーで保護すると、既存の復旧ポイントが自動的にアタッチされます。
- オプション 2: Recovery Services コンテナーに移動して、保護を停止すると共にデータを削除します。
論理的に削除された状態の項目の復旧ポイントで有効期限が切れた場合の影響
Recovery Services コンテナーで論理的な削除が有効な場合は、有効期限が切れた復旧ポイントが論理的に削除された状態のままになり、クリーンアップされません。 復旧ポイントが論理的に削除された状態の場合、料金は発生しません。
バックアップ パフォーマンスに対するチャーンの影響
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 TB | 4 TB | 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)] フィールドに、回復ポイントの保有期間が表示されます。 詳細については、「オンデマンド バックアップを実行する」を参照してください。