このページでは、Cloud SQL インスタンス、Compute Engine インスタンス、Compute Engine ディスクをバックアップするための高度なバックアップ戦略を定義できるバックアップ プランについて説明します。
バックアップ プランでは、リソースをバックアップするタイミングと方法を定義できます。バックアップの頻度、バックアップの保持期間、バックアップを保存するBackup Vault の場所を指定できます。バックアップ プランをリソースに関連付けると、Backup and DR はバックアップ プランの構成に従って、それらのリソースのバックアップを自動的にバックアップして保持します。
バックアップ プランを作成する前に、バックアップの保存場所を指定する必要があります。これを行うには、Backup Vaultを作成する必要があります。
バックアップ プランにはバックアップ ルールがあります。次の点に注意してください。
- 1 つ以上のバックアップ ルールを使用できます。
バックアップの作成頻度（時間単位、日単位、週単位、月単位、年単位）を定義できます。
- 1 時間ごとのバックアップの 1 時間あたりの頻度（ジョブの実行頻度）は、バックアップするデータリソースのタイプによって異なります。1 時間ごとのバックアップの頻度範囲をご覧ください。
- 週次バックアップの場合は、ルールの曜日を選択できます。
- 月次バックアップでは、ルールの特定の日付を選択できます。たとえば、当月 15 日などです。
スケジュール バックアップとオンデマンド バックアップの両方に使用できます。
バックアップ ジョブを開始できる特定の期間を定義できるバックアップ ウィンドウが含まれます。バックアップ ウィンドウでは、次のものが使用されます。
- 24 時間形式で、開始時刻と終了時刻は 00 ～ 24 時間の間で指定します。
- 時間枠の最短時間は 6 時間です。
マシンの構成の [データ保護] セクションで [ブートディスクを除外] がオンになっている場合でも、バックアップ プランには常にブートディスクが含まれます。詳細については、非ブートディスクを追加したインスタンスを作成するをご覧ください。
1 時間ごとのバックアップの頻度範囲
1 時間ごとのバックアップの頻度を指定します。時間単位の頻度が 1 の場合、ジョブは開始時刻から終了時刻まで 1 時間ごとに実行されます。
これは recurrence_type が HOURLY に設定されている場合に必須であり、それ以外の場合は適用されません。値が指定されていて、recurrence_type が HOURLY でない場合、検証エラーが発生します。
各リソースタイプでサポートされている値は次のとおりです。
| リソースの種類 | 1 時間あたりのフリークエンシー |
|---|---|
| Compute Engine インスタンス | 4-23 |
| Compute Engine ディスク | 1-23 |
| Cloud SQL インスタンス | 6-23 |
| AlloyDB for PostgreSQL クラスタ | 1-23 |
| Filestore インスタンス | 1-23 |
Backup and DR サービスのデータの保持の概要
Backup and DR サービスは、2 種類の保持を使用してバックアップのライフサイクルとセキュリティを管理します。
- すべてのバックアップは、バックアップ プランで割り当てられた期間保持され、その期間の終了時に期限切れになります。バックアップは、バックアップ プランの [バックアップを削除するまでの期間] 設定で設定された有効期限の前に手動で削除できます。
必要に応じて、バックアップを Backup Vaultに保存し、バックアップ ボルト構成の [強制保持期間] セクションで [削除を防止する期間] の値を設定することで、特定の期間に一部のバックアップを削除できないようにすることができます。
- 適用される保持期間は、バックアップ プランの [バックアップを削除するまでの期間] 設定よりも長く設定できます。バックアップは、適用されている保持期間が終了するまで削除されません。
- バックアップ Vault 全体に対して強制保持期間を設定することも、バックアップ Vault で、Vault で保護されている各データリソースのバックアップ プランの [バックアップを削除するまでの期間] の値を適用することもできます。
バックアップ ストレージの使用量
バックアップ プランでは、バックアップ ストレージについて次の点を考慮してください。
- バックアップは、定義されたバックアップ保持期間に達すると自動的に削除されます。
- バックアップ削除のデフォルト値は、バックアップの保存に使用される Backup Vault の最短保持期間から継承されます。
- バックアップの保持期間は、Backup Vault の最小保持期間よりも短くすることはできません。最小保持期間と同じか、それよりも長くする必要があります。
- バックアップ プランを使用して作成されたバックアップは常に不変であるため、バックアップ ボルトの最短保持期間中は変更または削除できません。
CMEK 対応の Backup Vault へのワークロードのバックアップ
Backup Vault が CMEK で構成されると、そこに保存されたバックアップは指定された鍵を使用して保護されます。バックアップ プランを 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 にバックアップする必要があります。
バックアップ プランでサポートされているリージョン
バックアップ プランを作成できるのは、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 |
ワルシャワ | ||
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 |
ミラノ | ||
europe-west9 |
パリ |
低 CO2
|
|
europe-west10 |
ベルリン | ||
europe-west12 |
トリノ | ||
| 中東 | |||
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