このページでは、バックアップ ボールト、サポートされているバックアップ モデル、リージョン、リソースについて説明します。
バックアップ ボールトは、セルフマネージド ストレージ（作成した Cloud Storage バケット）と同様に、バックアップを保存するコンテナです。ただし、Backup Vault を使用すると、安全で分離された専用のストレージでバックアップを保護できるため、追加のメリットがあります。Backup Vault は、バックアップの悪意のある削除や偶発的な削除に対する復元力をサポートするように設計されています。この機能は、ユーザーエラーからの復元やサイバー復旧など、さまざまなデータ保護のユースケースをサポートします。
バックアップが Backup Vault に保存されている場合、バックアップ データの保存と管理は Backup and DR Service によって処理されます。データが保存されている基盤となるストレージ リソースには直接アクセスできないため、これらのリソースは直接攻撃から保護されます。また、Backup Vault では、適用される最小保持期間を指定できます。これにより、指定された期間が経過するまでバックアップを期限切れにしないように強制し、偶発的な削除や悪意のある削除から保護できます。
Backup Vault の作成、アクセス、管理には、Google Cloud Backup and DR サービスを使用します。Backup Vault は、バックアップを単一のリージョンに保存します。バックアップを複数のリージョンに保存する必要がある場合は、セルフマネージド ストレージを使用します。
リソースモデル
次のセクションでは、バックアップ ボールト リソースモデルについて説明します。
Backup Vault には、バックアップ データを整理するための 3 レベルの階層型リソースモデルがあります。
- バックアップ ボールト。Google Cloud バックアップと DR バックアップ データを保存するためのトップレベルのユーザー定義リソース。
- データソース。バックアップされる特定のリソース（仮想マシンやデータベース インスタンスなど）を表します。1 つのデータソースに複数のバックアップを含めることができます。データソースはバックアップ ボールトの子リソースです。
- バックアップ。データソースで指定されたリソースの単一のバックアップを表します。バックアップはデータソースの子リソースです。
次の図は、バックアップ ボールトのリソースモデルを示しています。
サポートされているリソース
次の表は、バックアップ ボールトがサポートするリソースと、それらの管理に使用するものを理解するのに役立ちます。
| ワークロード | 管理者 |
|---|---|
| Compute Engine インスタンス | Google Cloud コンソール |
| Google Cloud VMware Engine、Oracle データベース、SQL Server データベース | 管理コンソール |
Google Cloud コンソールを使用して保護されたリソースのモデルをバックアップする
このセクションでは、Google Cloud コンソールを使用して保護されるリソースの 2 つのバックアップ モデルについて説明します。
一元化モデル: 一元化モデルでは、指定された中央管理者プロジェクト内にバックアップ ボールトとプランを作成することで、バックアップ管理を効率化します。この一元リポジトリには、複数のサービス プロジェクトで実行されている Compute Engine VM など、さまざまなリソースのバックアップが統合されます。組織は、これらの一元管理されたバックアップ プランを使用して、異なるサービス プロジェクトに存在する Compute Engine VM を保護します。
バックアップ管理者は、IAM 権限を使用して、サービス プロジェクト内のアプリケーション オーナーまたはプラットフォーム オーナーにバックアップ プランへのアクセス権を付与することもできます。アクセス権を付与すると、プラットフォーム所有者はアプリケーションのバックアップの所有権を取得できます。
分散モデル: 分散モデルでは、組織の特定のニーズと必要な分離レベルに基づいて、さまざまなプロジェクトにバックアップ ボールトが作成されます。つまり、Compute Engine VM などのさまざまなリソースを含むプロジェクトごとに、バックアップ ボールトとバックアップ プランが作成されます。このアプローチは、VM のバックアップの責任がそれぞれのアプリケーション チームにある分散型組織にとって重要です。
管理コンソールを使用して保護されているリソースのモデルをバックアップする
このセクションでは、管理コンソールを使用して保護されるリソースの 2 つのバックアップ モデルについて説明します。
一元化モデル: 一元化モデルでは、Backup Vault を作成し、指定された中央管理者プロジェクト内に管理コンソールをデプロイすることで、バックアップ管理を効率化します。この一元リポジトリには、複数のサービス プロジェクトで実行されている VMware Engine VM など、さまざまなリソースのバックアップが統合されます。組織は、管理コンソール内でポリシーを構成して、異なるサービス プロジェクトに存在するリソースを保護します。
分散モデル: 分散モデルでは、組織固有のニーズと必要な分離レベルに基づいて、さまざまなプロジェクトに管理コンソールとバックアップ ボールトが作成されます。たとえば、組織は事業部門ごとに個別の管理コンソールを使用できます。このアプローチは、リソースの管理とバックアップの責任が複数のチームに分割されている分散型の組織に適しています。
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 |
ラスベガス | ||
| 南アメリカ | |||
southamerica-east1 |
サンパウロ |
低 CO2 |
|
southamerica-west1 |
サンチアゴ |
低 CO2
|
|
| ヨーロッパ | |||
europe-central2 |
ワルシャワ | ||
europe-north1 |
フィンランド |
低 CO2
|
|
europe-southwest1 |
マドリッド |
低 CO2
|
|
europe-west1 |
ベルギー |
低 CO2
|
|
europe-west2 |
ロンドン |
低 CO2
|
|
europe-west3 |
フランクフルト |
低 CO2
|
|
europe-west4 |
オランダ |
低 CO2
|
|
europe-west6 |
チューリッヒ |
低 CO2
|
|
europe-west8 |
ミラノ | ||
europe-west9 |
パリ |
低 CO2
|
|
europe-west10 |
ベルリン |
低 CO2
|
|
| 中東 | |||
me-central1 |
ドーハ | ||
me-central2 |
ダンマーム | ||
me-west1 |
イスラエル | ||
| アジア太平洋 | |||
asia-east1 |
台湾 | ||
asia-east2 |
香港 | ||
asia-northeast1 |
東京 | ||
asia-northeast2 * |
大阪 | ||
asia-northeast3 |
ソウル | ||
asia-southeast1 |
シンガポール | ||
asia-southeast2 |
ジャカルタ | ||
australia-southeast1 |
シドニー | ||
australia-southeast2 |
メルボルン | ||
| インド | |||
asia-south1 |
ムンバイ | ||
asia-south2 |
デリー |
* モントリオールと大阪には、それぞれ 1 つまたは 2 つの物理データセンターに 3 つのゾーンがあります。まれに発生する災害の場合、これらのリージョンに保存されているデータが失われる可能性があります。
Backup Vault の名前
バックアップ ボールト名は次の要件を満たす必要があります。
- バックアップ ボールト名には、小文字、数字、ダッシュ（
-）、アンダースコア（_）、ピリオド（.）のみ使用できます。スペースは使用できません。 - バックアップ ボールト名の先頭と末尾は、数字または文字にする必要があります。
- バックアップ ボールト名の長さは 3 ～ 63 文字にする必要があります。ピリオドを含む名前には最大 222 文字を使用できますが、ピリオドで区切られている各要素は 63 文字以下である必要があります。
- バックアップ ボールト名は、ドット区切りの十進表記の IP アドレスとして表すことはできません。例:
192.0.2.255
Backup Vault の最小適用保持期間
Backup Vault の最小保持期間を適用すると、バックアップの削除可能日時を制御して、偶発的な削除や悪意のある削除からデータを保護できます。Backup Vault 内のバックアップは、適用される最小保持期間が終了した後にのみ削除できます。新しい Backup Vault を作成する場合は、1 日から 99 年の間で最小保持期間を指定する必要があります。
Backup Vault をロックすると、Backup Vault の最小保持期間の短縮を防ぐことができます。ロックした後でも、適用する最小保持期間を増やすことができます。適用する最小保持期間を更新するをご覧ください。
ロックを設定する場合は、ロックが有効になる日付を定義する必要があります。発効日が到来するまでは、バックアップ ボールトの適用される保持期間を増やすことも短縮することもできます。ただし、ロックの発効日を過ぎると、プロジェクト オーナーであっても、そのバックアップ ボールトの適用される保持期間を短縮することはできません。
たとえば、最小適用期間を 5 日に設定し、Vault をロックするように指定し、ロックの有効日付を 2024 年 7 月 31 日午前 0 時（UTC）に設定したとします。2024 年 7 月 31 日（UTC）午前 0 時までは、強制適用される最小保持期間を増減できます。その後、適用する最短保持期間の延長のみ可能となります。
Backup Vault のアクセス制限
Backup Vault のアクセス制限の設定を使用すると、Backup Vault にバックアップまたは復元できるデータのソースを制御できます。この設定により、Backup Vault に保存できるリソースのタイプが決まります。
バックアップ ボールトには、次のいずれかのアクセス制限設定を選択できます。この設定は永続的で変更できません。
- 現在の組織へのアクセスを制限する: バックアップと復元のオペレーションは、現在の組織内でのみサポートされます。この選択により、バックアップ ボールトは、Compute Engine VM など、Google Cloud コンソールで管理されるリソースと互換性がありますが、管理コンソールで管理されるリソースとは互換性がありません。
- 現在のプロジェクトへのアクセスを制限する: バックアップと復元のオペレーションは、現在のプロジェクト内でのみサポートされます。この選択により、バックアップ ボールトは Google Cloud コンソールで管理されるリソース（Compute Engine VM など）と互換性がありますが、管理コンソールで管理されるリソースとは互換性がありません。
- 現在の組織へのアクセスを制限し、バックアップ アプライアンスへのアクセスは制限しない: Google Cloud コンソールから管理されるリソースの場合、バックアップと復元のオペレーションは現在の組織内でのみサポートされます。管理コンソールで管理されているリソース（VMware Engine VM など）もサポートされていますが、これらのリソースのバックアップと復元オペレーションは、現在の組織に限定されません。この選択により、バックアップ ボールトは Google Cloud コンソールで管理されるリソースと、管理コンソールで管理されるリソースと互換性を持つようになります。
- 無制限のアクセスを許可する: 任意のプロジェクトまたは組織との間でバックアップと復元のオペレーションを許可します。この選択により、バックアップ ボールトは Google Cloud コンソールで管理されるリソースと、管理コンソールで管理されるリソースと互換性を持つようになります。
次のステップ
- コンソールで Backup Vault を作成して管理する Google Cloud
- コンソールでデータソースを管理する Google Cloud
- コンソールでバックアップを管理する Google Cloud