このページでは、リソースをバックアップするための高度なバックアップ戦略を定義できるバックアップ プランについて説明します。バックアップ プランを使用して、次のリソースをバックアップできます。
Cloud SQL インスタンス
Compute Engine インスタンスとディスク
AlloyDB for PostgreSQL クラスタ
Filestore インスタンス
バックアップ プランでは、リソースをバックアップするタイミングと方法を定義できます。バックアップの頻度、バックアップの保持期間、バックアップを保存する Backup Vault のロケーションを指定できます。バックアップ プランをリソースに関連付けると、Backup and DR はバックアップ プランの構成に従って、それらのリソースのバックアップを自動的にバックアップして保持します。
バックアップ プランを作成する前に、Backup Vault を作成して、バックアップの保存場所を指定する必要があります。
バックアップ プランには 1 つ以上のバックアップ ルールが含まれています。各バックアップ ルールでは、次のパラメータを定義します。
頻度: バックアップを 1 時間ごと、毎日、毎週、毎月、毎年実行するようにスケジュールを設定できます。
1 時間: 使用可能な頻度は、リソースタイプによって異なります。詳細については、時間単位のバックアップの頻度範囲をご覧ください。
毎週: 特定の曜日を選択できます。
毎月: 月の特定の日（15 日など）を選択できます。
バックアップ タイプ: スケジュール バックアップのルールを使用するか、オンデマンド バックアップを開始できます。
バックアップ ウィンドウ: バックアップ ジョブを開始できる期間を定義できます。バックアップ ウィンドウには次の要件があります。
24 時間形式を使用し、開始時刻と終了時刻は 00 ～ 24 の範囲で指定する必要があります。
6 時間以上である必要があります。
制約: バックアップ プランには常にブートディスクが含まれます。[マシン構成] の [データ保護] セクションで [ブートディスクを除外] を選択しても、バックアップ プランにはブートディスクが含まれます。詳細については、非ブートディスクを追加したインスタンスを作成するをご覧ください。
1 時間ごとのバックアップの頻度範囲
このセクションでは、1 時間ごとのバックアップの頻度を指定します。頻度を 1 時間に設定すると、ジョブは開始時刻から終了時刻まで 1 時間ごとに実行されます。
recurrence_typeがHOURLYに設定されている場合、この設定は必須です。recurrence_typeがHOURLYでない場合、この設定は適用されません。この設定に値を指定し、
recurrence_typeがHOURLYでない場合、検証エラーが発生します。
各リソースタイプでサポートされている値は次のとおりです。
| リソースの種類 | 1 時間あたりのフリークエンシー |
|---|---|
| Compute Engine インスタンス | 1-23 |
| Compute Engine ディスク | 1-23 |
| Cloud SQL インスタンス | 6-23 |
| AlloyDB for PostgreSQL クラスタ | 1-23 |
| Filestore インスタンス | 1-23 |
Compute Engine インスタンス リソースについては、1 時間ごとのバックアップのベスト プラクティスをご覧ください。
データベース ログのバックアップ
データベース リソース（Cloud SQL や AlloyDB など）の場合、バックアップ プラン内でログ バックアップを有効にできます。これにより、フル バックアップ ポイント間のトランザクション ログをキャプチャして、ポイントインタイム リカバリ（PITR）が可能になります。
Backup and DR のデータ保持の概要
Backup and DR は、次の 2 つの保持タイプを使用して、バックアップのライフサイクルとセキュリティを管理します。
割り当てられた保持期間: バックアップ プランで [バックアップを削除するまでの期間] 設定を使用して定義されます。
バックアップはこの期間保持され、期間の終了時に期限切れになります。
強制保持によって削除が禁止されていない限り、この日付より前にバックアップを手動で削除できます。
適用される保持期間: 削除を防止する設定を使用して、Backup Vault 構成で定義されます。
この設定により、指定された期間はバックアップを削除できなくなります。
適用される保持期間が割り当てられた保持期間よりも長い場合、バックアップは適用される保持期間が終了するまで削除されません。
適用される保持期間は、Backup Vault 全体に適用することも、保護されたリソースごとに割り当てられた保持期間（バックアップの削除後）を適用するように Backup Vault を構成することもできます。
オンデマンドのカスタム保持期間の最大値
この設定は、オンデマンド バックアップ（自動スケジュール外で手動で作成されたバックアップ）を保持できる最大日数を定義します。これにより、ユーザーが手動スナップショットの保持期間を誤って過度に長く設定することを防ぐことができます。
バックアップ ストレージの使用量
バックアップ プランのバックアップ ストレージには、次のルールがあります。
自動削除: 定義されたバックアップ保持期間に達すると、バックアップは自動的に削除されます。
最小保持期間: バックアップ保持期間は、Backup Vault の最小保持期間以上にする必要があります。
継承されたデフォルト: バックアップ削除のデフォルト値は、Backup Vault の最短保持期間から継承されます。
不変性: バックアップ プランを使用して作成されたバックアップは変更できません。Backup Vault の最短保持期間中は、変更も削除もできません。
CMEK 対応の Backup Vault にワークロードをバックアップする
CMEK を使用して Backup Vault を構成すると、そこに保存されたバックアップは指定した鍵を使用して保護されます。バックアップ プランを CMEK 対応の Vault に関連付ける場合は、次のルールが適用されます。
CMEK で保護されたワークロード: ソース ワークロードが CMEK で保護されている場合（CMEK で暗号化されたディスクを含む Compute Engine インスタンスなど）、CMEK 対応の Backup Vault にバックアップする必要があります。 Google-owned and Google-managed encryption keysを使用する Backup Vault に、CMEK で保護されたリソースをバックアップすることはできません。
Google-owned and Google-managed encryption keysを使用するワークロード: ソース ワークロードが Google-owned and Google-managed encryption keysを使用している場合は、 Google-owned and Google-managed encryption keysを使用する Backup Vault にバックアップする必要があります。
バックアップ ジョブの再試行
スケジュールされたジョブが失敗すると、スケジューラはジョブを最大 3 回まで自動的に再試行します。
- 最初の失敗: ステータスが「再試行」に設定され、4 分間待機します。
- 2 回目の失敗: 次の再試行は 16 分後にキューに登録されます。
- 3 回目の失敗: 64 分後に最終再試行がキューに登録されます。
- 最終的な失敗: 合計 4 回の試行後、ステータスが [失敗] に変わります。そのスケジュール期間では、それ以降のジョブは試行されません。
ジョブの再試行は、[モニタリング] > [ジョブ] に報告されます。再試行を識別するために、4 つのジョブすべてが同じジョブ番号を共有し、一意の接尾辞（Job_12345、Job_12345a、Job_12345b など）が付けられます。
バックアップ プランでサポートされているリージョン
バックアップ プランを作成できるのは、Backup and DR が利用可能で、バックアップ対象のリソースが存在するリージョンのみです。バックアップ プランを作成するには、互換性のあるロケーションで Backup Vault も使用可能である必要があります。サポートされていないリージョンにバックアップ プランを作成する必要がある場合は、アプライアンス管理コンソールのバックアップ テンプレートを使用します。
バックアップ プランは、次のリージョンでサポートされています。
| 地域 | リージョン名 | リージョンの説明 | |
|---|---|---|---|
| 北米 | |||
northamerica-northeast1 * |
モントリオール |
 低 CO2
|
|
northamerica-northeast2 |
トロント |
低 CO2 |
|
us-central1 |
アイオワ |
低 CO2 |
|
us-east1 |
サウスカロライナ | ||
us-east4 |
北バージニア | ||
us-east5 |
コロンバス | ||
us-south1 |
ダラス |
低 CO2
|
|
us-west1 |
オレゴン |
低 CO2 |
|
us-west2 |
ロサンゼルス | ||
us-west3 |
ソルトレイクシティ | ||
us-west4 |
ラスベガス | ||
northamerica-south1 * |
ケレタロ | ||
| 南アメリカ | |||
southamerica-east1 |
サンパウロ |
低 CO2
|
|
southamerica-west1 |
サンチアゴ |
低 CO2
|
|
| ヨーロッパ | |||
europe-central2 |
ワルシャワ |
低 CO2
|
|
europe-north1 |
フィンランド |
低 CO2
|
|
europe-north2 |
ストックホルム |
低 CO2
|
|
europe-southwest1 |
マドリッド |
低 CO2
|
|
europe-west1 |
ベルギー |
低 CO2
|
|
europe-west2 |
ロンドン |
低 CO2
|
|
europe-west3 |
フランクフルト | ||
europe-west4 |
オランダ |
低 CO2
|
|
europe-west6 |
チューリッヒ |
低 CO2
|
|
europe-west8 |
Milan |
低 CO2
|
|
europe-west9 |
パリ |
低 CO2
|
|
europe-west10 |
ベルリン | ||
europe-west12 |
トリノ |
低 CO2 |
|
| 中東 | |||
me-central1 |
ドーハ | ||
me-central2 |
ダンマーム | ||
me-west1 |
イスラエル | ||
| アフリカ | |||
africa-south1 |
ヨハネスブルグ | ||
| アジア太平洋 | |||
asia-east1 |
台湾 | ||
asia-east2 |
香港 | ||
asia-northeast1 |
東京 | ||
asia-northeast2 * |
大阪 | ||
asia-northeast3 |
ソウル | ||
asia-southeast1 |
シンガポール | ||
asia-southeast2 |
ジャカルタ | ||
australia-southeast1 |
シドニー | ||
australia-southeast2 |
メルボルン | ||
| インド | |||
asia-south1 |
ムンバイ | ||
asia-south2 |
デリー |
* ケレタロ（northamerica-south1）、モントリオール（northamerica-northeast1）、大阪（asia-northeast2）は、ゾーン分割をサポートしていません。つまり、これらのリージョン内の複数のゾーンが、物理的に分離されたデータセンター キャンパスに配置されていない可能性があります。そのため、単一の局所的な物理的な災害が発生した場合、同じリージョン内の複数のゾーンに影響が及ぶ可能性があり、ゾーン分割をサポートするリージョンと比較してデータ損失のリスクが高まります。
バックアップ プランとルールの名前
バックアップ プラン名とルール名は、次の要件を満たす必要があります。
- 英小文字、数字、ダッシュ（
-）、アンダースコア（_）、ピリオド（.）を含みます。スペースは使用できません。 - 先頭と末尾は数字または英字にする必要があります
- 最大 63 文字
- ドット区切りの十進表記の IP アドレスとして表すことはできません。例:
192.0.2.255