このページでは、バックアップ ボールト、サポートされているバックアップ モデル、ロケーション、リソースについて説明します。
バックアップ ボールトは、バックアップを保存するコンテナです（作成した Cloud Storage バケットなどのセルフマネージド ストレージ）。ただし、Backup Vault を使用すると、安全で分離された専用のストレージでバックアップを保護できるため、追加のメリットがあります。Backup Vault は、バックアップの悪意のある削除や偶発的な削除に対する復元力をサポートするように設計されています。この機能は、ユーザーエラーからの復元やサイバー復旧など、さまざまなデータ保護のユースケースをサポートします。
バックアップが Backup Vault に保存されている場合、バックアップ データの保存と管理は Backup and DR サービスが処理します。データが保存されている基盤となるストレージ リソースには直接アクセスできないため、これらのリソースは直接攻撃から保護されます。また、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 は、リージョンとマルチリージョンに作成できます。
リージョン
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
|
|
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 |
デリー |
* モントリオールと大阪には、それぞれ 1 つまたは 2 つの物理データセンターに 3 つのゾーンがあります。まれに発生する災害の場合、これらのリージョンに保存されているデータが失われる可能性があります。
マルチリージョン
Backup Vault は、次のマルチリージョンに作成できます。
| マルチリージョン名 | マルチリージョンの説明 |
|---|---|
ASIA |
アジア内のデータセンター |
EU |
欧州連合（EU）内のデータセンター |
US |
米国内のデータセンター |
ワークロードのロケーションの互換性
次の表に、リージョン バックアップ ボールトを使用する場合の、サポートされているワークロードごとに互換性のあるバックアップ ボールト ロケーションを示します。Google Cloud コンソールのバックアップ プランは、移行元のワークロードと同じリージョンに作成する必要があります。
| ワークロード | Backup Vault はソース ワークロードと同じリージョンに配置する必要がありますか？ | サポートされている Backup Vault リージョン |
|---|---|---|
| Compute Engine インスタンス | ○ | サポートされているすべてのリージョン |
| Google Cloud VMware Engine、Oracle データベース、SQL Server データベース | いいえ | サポートされているすべてのリージョン |
ワークロードがマルチリージョン Backup Vault の使用をサポートしている場合、ソース ワークロードのロケーションはマルチリージョン Backup Vault のロケーションと互換性がある必要があります。
マルチリージョンの互換性は、ワークロードのロケーション接頭辞によって決まります。
- 接頭辞が「asia」のリージョンのリソースは、「asia」マルチリージョンにのみバックアップできます。
- 接頭辞が「us」のリージョンのリソースは、「us」マルチリージョンにのみバックアップできます。
- 接頭辞が「europe」のリージョンのリソースは、「eu」マルチリージョンにのみバックアップできます。
次の表に、マルチリージョン Backup Vault を使用する場合の、サポートされているワークロードごとに互換性のある Backup Vault のロケーションを示します。
| ワークロード | マルチリージョン Backup Vault の使用をサポートしていますか？ | サポートされている Backup Vault のマルチリージョン |
|---|---|---|
| Compute Engine インスタンス | ○ | asia、eu、us |
| Google Cloud VMware Engine、Oracle データベース、SQL Server データベース | いいえ | なし |
対象
リージョン ロケーションに作成された Backup Vault は、単一ゾーンの停止に対する耐障害性を提供します。バックアップ データは、少なくとも 2 つの個別のゾーンに冗長的に保存されます。
マルチリージョンのロケーションに作成された Backup Vault は、単一リージョンの停止に対する復元力を備えています。バックアップ データは、少なくとも 2 つの個別のリージョンに冗長的に保存されます。
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 に保存できるリソースのタイプが決まります。
バックアップ ボールトには、次のいずれかのアクセス制限設定を選択できます。この設定は永続的で変更できません。
- 現在の組織へのアクセスを制限する: バックアップと復元のオペレーションは、現在の組織内でのみサポートされます。この選択により、バックアップ ボールトは、Google Cloud コンソールで管理されるリソース（Compute Engine VM など）と互換性がありますが、管理コンソールで管理されるリソースとは互換性がありません。
- 現在のプロジェクトへのアクセスを制限する: バックアップと復元のオペレーションは、現在のプロジェクト内でのみサポートされます。この選択により、バックアップ ボールトはGoogle Cloud コンソールで管理されるリソース（Compute Engine VM など）と互換性がありますが、管理コンソールで管理されるリソースとは互換性がありません。
- 現在の組織へのアクセスを制限し、バックアップ アプライアンスへのアクセスは制限しない: Google Cloud コンソールで管理されているリソースの場合、バックアップと復元のオペレーションは現在の組織内でのみサポートされます。管理コンソールで管理されるリソース（VMware Engine VM など）もサポートされていますが、これらのリソースのバックアップと復元オペレーションは現在の組織に限定されません。この選択により、バックアップ ボールトはコンソールで管理されるリソースと管理コンソールで管理されるリソースと互換性を持つようになります。 Google Cloud
- 無制限のアクセスを許可する: 任意のプロジェクトまたは組織との間でバックアップと復元のオペレーションを許可します。この選択により、バックアップ ボールトはコンソールで管理されるリソースと管理コンソールで管理されるリソースと互換性を持つようになります。 Google Cloud
次のステップ
- Google Cloud コンソールで Backup Vault を作成、管理する
- Google Cloud コンソールでデータソースを管理する
- Google Cloud コンソールでバックアップを管理する