Backup Vault は、バックアップ用に分離された変更不可で消去不能なストレージを提供する Google マネージドのリージョン リソースです。データは Vault、データソース、バックアップの階層に整理され、保持期間の適用とプロジェクト レベルの ID 分離により、偶発的な削除や悪意のある削除から保護されます。
このドキュメントでは、階層型リソースモデル、サポートされているワークロード、バックアップ モデル、ロケーションの互換性、可用性、命名要件など、バックアップ ボルトの仕組みについて説明します。
リソース階層
Backup and DR サービス内のデータは、Backup Vault 内の 3 階層の階層に整理されます。
Backup Vault: グローバルな最小保持ポリシーを適用する最上位のコンテナ。
データソース: 特定の保護対象エンティティ（Compute Engine インスタンスなど）を表す子リソース。これは、最初のバックアップ時に自動的に作成されます。
バックアップ: 特定のポイントインタイム リカバリ ポイントを持つ個別のバックアップを表すデータソースの子リソース。
次の図は、バックアップ ボルトのリソースモデルを示しています。
制限事項
このページでは、Google Cloud コンソールで管理されるリソース（Compute Engine や Cloud SQL など）のバックアップ ボルトについて説明します。Oracle や Google Cloud VMware Engine などのワークロードにアプライアンス管理コンソールを使用している場合は、アプライアンス管理コンソールから管理されるバックアップ ボルトの概要をご覧ください。
バックアップ ボルト内の AlloyDB クラスタと Filestore インスタンスは、マルチリージョンではサポートされていません。
Backup and DR サービスは、Backup Vault バックアップからワークロードを復元する際に、互換性のある宛先ロケーションに制限を課しません。
Backup Vault とソース ワークロードのロケーションによっては、ネットワーク転送料金が発生する場合があります。詳細については、Backup and DR サービスの料金をご覧ください。
サポートされているリソース
| ワークロード タイプ | 管理 |
|---|---|
| Compute Engine インスタンス | Google Cloud コンソール |
| Compute Engine ディスク | Google Cloud コンソール |
| Filestore インスタンス | Google Cloud コンソール |
| Cloud SQL インスタンス | Google Cloud コンソール |
| AlloyDB クラスタ | Google Cloud コンソール |
| Google Cloud VMware Engine、Oracle データベース、SQL Server データベース | アプライアンス管理コンソール |
リソースのバックアップ モデル
| 一元化モデル | 分散型モデル | |
|---|---|---|
| Google Cloud コンソール | 中央管理者プロジェクトに Backup Vault とバックアップ プランを作成して、バックアップ管理を統合します。管理者は、これらの集中管理プランを使用して、複数のサービス プロジェクトにわたってリソースを保護できます。また、IAM 権限を使用して、バックアップ プランへのアクセスをアプリケーション オーナーに委任することもできます。 |
各プロジェクト内に個別の Backup Vault とバックアップ プランを作成して、バックアップ管理を分離します。このアプローチは、個々のアプリケーション チームが独自のリソースのバックアップを担当する分散型組織に最適です。 |
| アプライアンス管理コンソール | アプライアンス管理コンソールをデプロイし、中央管理者プロジェクトに Backup Vault を作成することで、バックアップ管理を統合します。管理者は、中央管理コンソール内でバックアップ ポリシーを構成して、複数のサービス プロジェクトにわたる Google Cloud VMware Engine VM などのリソースを保護します。 |
プロジェクトまたはビジネス部門ごとに個別の Appliance Management Console と Backup Vault をデプロイして、バックアップ管理を分離します。このアプローチは、バックアップ管理の責任が複数のチームに分散している分散型組織に最適です。 |
Backup Vault でサポートされているロケーション
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）では、ゾーン分割はサポートされていません。つまり、これらのリージョン内の複数のゾーンが、物理的に分離されたデータセンター キャンパスに配置されていない可能性があります。そのため、単一の局所的な物理災害イベントが同じリージョン内の複数のゾーンに影響を与える可能性があり、ゾーン分割をサポートするリージョンと比較してデータ損失のリスクが高まります。
サポートされているマルチリージョン
次のマルチリージョンに Backup Vault を作成できます。
| マルチリージョン名 | 説明 |
|---|---|
ASIA |
アジア内のデータセンター |
EU |
欧州連合（EU）内のデータセンター |
US |
米国内のデータセンター |
ワークロードのロケーションの互換性
次の表に、リージョン Backup Vault とクロスリージョン Backup Vault を使用する場合に、サポートされている各ワークロードに対応する Backup Vault のロケーションを示します。 Google Cloud コンソールのバックアップ プランは、移行元ワークロードと同じリージョンに作成する必要があります。
| ワークロード | Backup Vault は、ソース ワークロードと同じリージョンに存在している必要があります。 | リージョン サポート | マルチリージョンのサポート | クロスリージョン サポート |
|---|---|---|---|---|
| Compute Engine インスタンス | × | |||
| Compute Engine ディスク | × | |||
| Cloud SQL インスタンス | ○ | |||
| AlloyDB クラスタ | ○ | |||
| Filestore インスタンス | × | |||
| Google Cloud VMware Engine、Oracle データベース、SQL Server データベース | × |
マルチリージョン互換性
マルチリージョンを使用するには、次の要件を満たす必要があります。
ワークロードがマルチリージョン Backup Vault をサポートしている場合、移行元のワークロードのロケーションは、マルチリージョン Backup Vault のロケーションと互換性がある必要があります。
バックアップできるのは、同じ接頭辞を共有するリージョン内のリソースのみです。たとえば、
asia接頭辞が付いたリージョンのリソースは、asiaマルチリージョンにのみバックアップできます。
次の表に、マルチリージョン Backup Vault を使用する場合に、サポートされている各ワークロードと互換性のある Backup Vault のロケーションを示します。
| ワークロード タイプ | マルチリージョン Backup Vault の使用をサポートしているか？ | サポートされている Backup Vault のマルチリージョン |
|---|---|---|
| Compute Engine インスタンス | asia、eu、us |
|
| Compute Engine ディスク | asia、eu、us |
|
| Filestore インスタンス | なし | |
| Cloud SQL インスタンス | asia、eu、us |
|
| AlloyDB クラスタ | なし | |
| Google Cloud VMware Engine、Oracle データベース、SQL Server データベース | なし |
対象
リージョンとクロスリージョンのロケーションに作成された Backup Vault は、単一ゾーンの停止に対する復元力を提供します。バックアップ データは、少なくとも 2 つの別々のゾーンに冗長的に保存されます。
マルチリージョン ロケーションで作成されたバックアップ ボルトは、単一リージョンの停止に対する復元力を提供します。バックアップ データは、少なくとも 2 つの別々のリージョンに冗長的に保存されます。
マルチリージョン Backup Vault とクロスリージョン Backup Vault を比較する
| 条件 | マルチリージョンのバックアップ | リージョン間でのバックアップ |
|---|---|---|
| バックアップの作成 | 大陸内の 2 つのリージョン間で Google によって自動化されます。 | バックアップを作成するリージョンを明示的に定義する自律性。 |
| ユースケース | 高可用性とオペレーションの簡素化 | 厳格なコンプライアンス、データ所在地法、ターゲットの障害復旧サイト（ソース リージョン境界の内外）。 |
| 管理 | オーバーヘッドが少ない。単一の Vault、自動バランス調整 | 中程度のオーバーヘッド。特定のターゲット ペアを設定する必要があります。 |
| 顧客管理の暗号鍵（CMEK） | マルチリージョン Backup Vault は、Backup Vault と同じリージョンの CMEK を使用する必要があります。 | クロスリージョン Backup Vault は、Backup Vault と同じリージョンの CMEK を使用する必要があります。 |
| 費用への影響 | マルチリージョン アップロードとダウンロードの料金（該当する場合）。マルチリージョン Vault のバックアップ ストレージ料金。管理手数料。 | リージョン間のデータ転送料金。バックアップ ストレージ料金。管理手数料。 |
| 対応しているワークロード |
|
|
Backup Vault の名前
Backup Vault 名は次の要件を満たす必要があります。
Backup Vault 名に使用できるのは、小文字、数字、ハイフン（
-）のみです。スペースは使用できません。Backup Vault 名の先頭と末尾は、数字または文字にする必要があります。
Backup Vault 名は 3 ～ 63 文字で指定する必要があります。ピリオドを使用している名前には最大 222 文字を使用できますが、ピリオドで区切られている各要素は 63 文字以下である必要があります。
Backup Vault 名は、ドット区切りの十進表記の IP アドレスとして表すことはできません。例:
192.0.2.255
バックアップの削除禁止
適用された保持期間により、指定された期間が経過するまでバックアップが削除されなくなります。この期間中は、Vault に保存されたバックアップに対して保管料金が発生します。強制保持を構成する前に、リソース階層で説明されている費用とコンプライアンスの影響を確認してください。
適用する最短保持期間
Backup Vault の最短保持期間を適用すると、バックアップを削除できるタイミングを制御して、偶発的な削除や悪意のある削除からデータを保護できます。Backup Vault 内のバックアップは、適用される最短保持期間が終了した後にのみ削除できます。新しい Backup Vault を作成する場合は、1 日から 99 年の間の最小適用保持期間を指定する必要があります。
最小保持期間が 3 日の Backup Vault を作成する場合、この Vault にバックアップを保存するバックアップ ルールのバックアップの削除までの期間は 3 日以上にする必要があります。
バックアップ ルールで指定された期間、削除を禁止する
この設定により、Backup Vault は関連付けられたバックアップ プランで定義された保持期間を採用できます。
Backup Vault でこのオプションを有効にすると、次の動作が発生します。
- バックアップ ルールで指定された保持期間が優先され、強制保持として機能します。ただし、Vault の適用される最短保持期間は満たす必要があるため、ルールで指定された保持期間は Vault レベルの最小値よりも短くすることはできません。
- 手動での削除は禁止されます。この適用された保持期間中は、バックアップを手動で削除することはできません。バックアップ プランのルールで指定された期間が経過した後にのみ自動的に削除されます。
この設定が有効になっている場合、バックアップ ボルトの [適用された保持期間] 列には [ルールから継承] と表示されます。
例: 保持の優先順位
次の構成があるとします。
Backup Vault の適用する最短保持期間: 3 日
Backup Vault のバックアップ ルールで指定された期間、削除を禁止する: 有効
バックアップ プランの [次の日数後にバックアップを削除]: 7 日
結果:
バックアップは、バックアップ プランのルールで指定された 7 日間は削除できません。7 日間が経過した後にのみ自動的に削除されます。
適用される保持期間とバックアップ プランで設定された有効期限の比較については、Backup and DR サービスでのデータ保持の概要をご覧ください。
適用する保持期間をロックする
Backup Vault をロックすると、Backup Vault の最短保持期間が短縮されるのを防ぐことができます。ロックした後でも、適用される最短保持期間を延長することはできます。適用される最短保持期間を更新するをご覧ください。
ロックを設定する際は、ロックが有効になる日付を定義する必要があります。発効日に達するまでは、バックアップ ボルトの適用される保持期間を延長または短縮できます。ただし、ロックの発効日を過ぎると、プロジェクト オーナーであっても、その Backup Vault の適用される保持期間を短縮することはできません。
たとえば、強制適用期間の最小値を 5 日に設定し、Vault をロックするように指定し、ロックの有効日を 2024 年 7 月 31 日午前 0 時（UTC）に設定したとします。2024 年 7 月 31 日午前 12 時（UTC）までは、強制適用される最小保持期間を増減できます。その後は、適用される最短保持期間を延長することのみ可能です。
Backup Vault のアクセス制限
Backup Vault のアクセス制限設定を使用すると、Backup Vault にデータをバックアップしたり、Backup Vault からデータを復元したりできるソースを制御できます。この設定により、バックアップ ボルトに保存できるリソースのタイプが決まります。
バックアップ ボルトには、次のいずれかのアクセス制限設定を選択できます。この設定は永続的で、変更することはできません。
現在の組織へのアクセスを制限する: バックアップと復元のオペレーションは、現在の組織内でのみサポートされます。この選択により、Backup Vault はGoogle Cloud コンソールで管理されるリソース（Compute Engine インスタンスなど）と互換性がありますが、アプライアンス管理コンソールで管理されるリソースとは互換性がありません。
現在のプロジェクトへのアクセスを制限する: バックアップと復元のオペレーションは、現在のプロジェクト内でのみサポートされます。この選択により、バックアップ ボルトはGoogle Cloud コンソール（Compute Engine インスタンスなど）で管理されるリソースと互換性がありますが、アプライアンス管理コンソールで管理されるリソースとは互換性がありません。
現在の組織へのアクセスを制限し、バックアップ アプライアンスへのアクセスは制限しない: Google Cloud コンソールで管理されているリソースの場合、バックアップと復元のオペレーションは現在の組織内でのみサポートされます。アプライアンス管理コンソールで管理されるリソース（Google Cloud VMware Engine VM など）もサポートされていますが、これらのリソースのバックアップと復元のオペレーションは現在の組織に制限されません。この選択により、Backup Vault はGoogle Cloud コンソールで管理されるリソースと、アプライアンス管理コンソールで管理されるリソースと互換性を持つようになります。
無制限のアクセスを許可: 任意のプロジェクトまたは組織との間でバックアップと復元オペレーションを実行できます。この選択により、Backup Vault は Google Cloud コンソールで管理されるリソースと、アプライアンス管理コンソールで管理されるリソースと互換性を持つようになります。
暗号化
デフォルトでは、 Google Cloud は Google-owned and Google-managed encryption keys を使用して、保存されているデータを自動的に暗号化します。データを保護する鍵について特定のコンプライアンスや規制の要件がある場合は、バックアップに顧客管理の暗号鍵（CMEK）を使用できます。顧客管理の暗号鍵（CMEK）をご覧ください。
次のステップ
- Google Cloud コンソールで Backup Vault を作成して管理する
- Google Cloud コンソールで Backup Vault を作成して管理する
- Compute Engine インスタンスを Backup Vault にバックアップする
- Cloud SQL インスタンスを Backup Vault にバックアップする
- AlloyDB クラスタを Backup Vault にバックアップする
- Filestore インスタンスを Backup Vault にバックアップする
- ディスクを Backup Vault にバックアップする