このページでは、バックアップ ボルト、サポートされているバックアップ モデル、ロケーション、リソースについて説明します。
バックアップ ボルトは、バックアップを保存するコンテナです（たとえば、セルフマネージド ストレージ、作成した Cloud Storage バケットなど）。ただし、Backup Vault は、安全で分離された専用ストレージでバックアップを保護することで、追加のメリットを提供します。Backup Vault は、バックアップの悪意のある削除や偶発的な削除に対する復元力をサポートするように設計されています。この機能は、ユーザーエラーからの復元やサイバー復元など、さまざまなデータ保護のユースケースをサポートします。
バックアップが Backup Vault に保存されると、Backup and DR サービスがバックアップ データの保存と管理を処理します。データが保存されている基盤となるストレージ リソースを直接確認したり、アクセスしたりすることはできません。これにより、これらのリソースが直接的な攻撃から保護されます。また、Backup Vault では、適用される最短保持期間を指定できます。これにより、指定された期間が経過するまでバックアップを期限切れにできなくなり、誤って、または悪意をもって削除されないよう保護できます。
Backup Vault の作成、アクセス、管理は、Google Cloud Backup and DR サービスを使用して行います。バックアップ ボルトは、バックアップをリージョンまたはマルチリージョンに保存します。
リソースモデル
次のセクションでは、バックアップ ボルトのリソースモデルについて説明します。
バックアップ Vault には、バックアップ データを整理するための 3 レベルの階層型リソースモデルがあります。
- バックアップ Vault。Google Cloud Backup and DR バックアップ データを保存するための最上位のユーザー定義リソース。
- データソース。仮想マシンやデータベース インスタンスなど、バックアップされる特定のリソースを表します。1 つのデータソースに複数のバックアップを含めることができます。データソースはバックアップ ボルトの子リソースです。
- バックアップ。データソースで指定されたリソースの単一のバックアップを表します。バックアップはデータソースの子リソースです。
次の図は、バックアップ ボルトのリソースモデルを示しています。
サポートされているリソース
次の表は、バックアップ ボルトがサポートするリソースと、それらの管理に使用するものを理解するのに役立ちます。
| ワークロード | 管理者 |
|---|---|
| Compute Engine インスタンス | Google Cloud コンソール |
| Google Cloud VMware Engine、Oracle データベース、SQL Server データベース | 管理コンソール |
Google Cloud コンソールを使用して保護されたリソースのバックアップ モデル
このセクションでは、Google Cloud コンソールを使用して保護されたリソースの 2 つのバックアップ モデルについて説明します。
一元管理モデル: 一元管理モデルでは、組織は指定された中央管理者プロジェクト内にバックアップ Vault とプランを作成することで、バックアップ管理を効率化します。この中央リポジトリには、複数のサービス プロジェクトで実行されている Compute Engine VM などのさまざまなリソースのバックアップが統合されます。組織は、これらの集中管理されたバックアップ プランを使用して、異なるサービス プロジェクトに存在する Compute Engine VM を保護します。
バックアップ管理者は、IAM 権限を使用して、サービス プロジェクト内のアプリケーション オーナーまたはプラットフォーム オーナーにバックアップ プランへのアクセス権を付与することもできます。アクセス権を付与すると、プラットフォーム オーナーはアプリケーションのバックアップの所有権を取得できます。
分散モデル: 分散モデルでは、組織の特定のニーズと必要な分離レベルに基づいて、さまざまなプロジェクトにバックアップ ボルトが作成されます。つまり、Compute Engine VM などのさまざまなリソースを含む各プロジェクトに対して、Backup Vault とバックアップ プランが作成されます。このアプローチは、VM のバックアップの責任が各アプリケーション チームにある分散型組織にとって重要です。
管理コンソールを使用して保護されたリソースのバックアップ モデル
このセクションでは、管理コンソールを使用して保護されたリソースの 2 つのバックアップ モデルについて説明します。
一元化されたモデル: 一元化されたモデルでは、組織はバックアップ 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 |
ラスベガス | ||
northamerica-south1 * |
ケレタロ | ||
| 南アメリカ | |||
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 コンソールのバックアップ プランは、移行元ワークロードと同じリージョンに作成する必要があります。
| ワークロード | バックアップ 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 つの別々のゾーンに冗長的に保存されます。
マルチリージョン ロケーションに作成されたバックアップ ボルトは、単一リージョンの停止に対する復元力を提供します。バックアップ データは、少なくとも 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 日午前 12 時（UTC）までは、強制適用される最小保持期間を増減できます。その後は、適用する最短保持期間を延長することしかできません。
バックアップ Vault のアクセス制限
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 コンソールでバックアップを管理する