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 は、ソース ワークロードと同じリージョン（リージョン）、ソース ワークロードとは異なるリージョン（クロスリージョン）、または複数のリージョン（マルチリージョン）に作成できます。
サポートされているリージョンとクロスリージョン
次のリージョンとクロスリージョンに 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）では、ゾーン分割はサポートされていません。つまり、これらのリージョン内の複数のゾーンが、物理的に分離されたデータセンター キャンパスに配置されていない可能性があります。そのため、単一の局所的な物理的な災害が発生した場合、同じリージョン内の複数のゾーンに影響が及ぶ可能性があり、ゾーン分割をサポートするリージョンと比較してデータ損失のリスクが高まります。
サポートされているマルチリージョン
次のマルチリージョンに 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
バックアップの削除禁止
偶発的な削除や悪意のある削除からデータを保護するには、管理者として Backup Vault の強制保持期間を構成します。構成すると、バックアップは完全に不変になります。指定した期間が経過するまで、ユーザー、他のユーザー、Google が手動で削除することはできません。
強制保持は、次の 3 つの主な Vault 設定を使用して制御します。
- 最小適用保持期間: Vault を作成するときに、ベースラインの保持期間（1 日～ 99 年）を設定する必要があります。これにより、ボールト全体の最低価格が設定されます。
この期間が経過するまで、バックアップを削除することはできません。この Vault にデータを保存するバックアップ プランのバックアップ保持期間は、この最小値以上である必要があります。
バックアップ ルールから保持期間を継承する: Vault のベースラインの最短保持期間のみに依存するのではなく、特定のバックアップ プランで定義されている正確な保持期間を採用するように Vault を構成できます。この設定は、Vault の作成時に有効にする必要があります。
Vault の最小保持期間が 3 日で、バックアップ プランの保持期間が 7 日の場合、バックアップは 7 日間ロックされます。結果: 手動での削除が完全に防止されます。バックアップが自動的に削除されるのは、バックアップ プランの特定の期間が経過した場合のみです。
適用する保持期間をロックする: 厳格なコンプライアンス要件がある場合は、適用する最短保持期間の構成を永続的にロックできます。
ロックを設定する際は、発効日を選択します。発効日までは、最短保持期間を増減して誤りを修正できます。発効日を過ぎると、プロジェクト オーナーであっても保持期間を短縮することはできません。増やすことのみが可能です。
Backup Vault のアクセス制限
Backup Vault のアクセス制限設定を使用すると、Backup Vault にデータをバックアップしたり、Backup Vault からデータを復元したりできるソースを制御できます。この設定により、Backup Vault に保存できるリソースのタイプが決まります。
バックアップ ボルトには、次のいずれかのアクセス制限設定を選択できます。この設定は永続的で、変更することはできません。
現在の組織へのアクセスを制限する: バックアップと復元のオペレーションは、現在の組織内でのみサポートされます。この選択により、Backup Vault はGoogle Cloud コンソールで管理されるリソース（Compute Engine インスタンスなど）と互換性がありますが、アプライアンス管理コンソールで管理されるリソースとは互換性がありません。
現在のプロジェクトへのアクセスを制限する: バックアップと復元オペレーションは、現在のプロジェクト内でのみサポートされます。この選択により、Backup Vault は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 を作成して管理する
- Compute Engine インスタンスを Backup Vault にバックアップする
- Cloud SQL インスタンスを Backup Vault にバックアップする
- AlloyDB クラスタを Backup Vault にバックアップする
- Filestore インスタンスを Backup Vault にバックアップする
- ディスクを Backup Vault にバックアップする