Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

変更不可・削除不可のバックアップ用の Backup Vault

Backup Vault は、バックアップ用に隔離された、変更不可で消去不能なストレージを提供する Google マネージドのリージョンリソースです。データを Vault、データソース、バックアップの階層に整理し、保持期間の適用とプロジェクトレベルの ID 分離により、偶発的な削除や悪意のある削除からデータを保護します。

このドキュメントでは、階層型リソースモデル、サポートされているワークロード、バックアップモデル、ロケーションの互換性、可用性、命名要件など、Backup Vault の仕組みについて説明します。

リソース階層

Backup and DR 内のデータは、Backup Vault 内の 3 階層の階層に編成されます。

Backup Vault: グローバルな最小保持ポリシーを適用する最上位コンテナ。
データソース: 特定の保護対象エンティティ（Compute Engine インスタンスなど）を表す子リソース。このバケットは、最初のバックアップ時にシステムによって自動的に作成されます。
バックアップ: 特定のポイントインタイムリカバリポイントを持つ個別のバックアップを表すデータソースの子リソース。

次の図は、Backup Vault リソースモデルを示しています。

Backup Vault のリソースモデル。 — Backup Vault リソースモデル。

制限事項

このページでは、Google Cloud コンソールで管理されるリソース（Compute Engine や Cloud SQL など）の Backup Vault について説明します。Oracle や Google Cloud VMware Engine などのワークロードにアプライアンス管理コンソールを使用している場合は、アプライアンス管理コンソールから管理される Backup Vault の概要をご覧ください。
Backup Vault の 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 など）を保護します。	プロジェクトまたは事業部門ごとに個別の管理コンソールと Backup Vault をデプロイして、バックアップ管理を分離します。このアプローチは、バックアップ管理の責任が複数のチームに分散されている分散型の組織に最適です。

Backup Vault でサポートされているロケーション

Backup Vault は、ソースワークロードと同じリージョン（リージョン）、ソースワークロードとは異なるリージョン（クロスリージョン）、または複数のリージョン（マルチリージョン）に作成できます。

サポート対象の地域とクロスリージョン

Backup Vault は、次のリージョンとクロスリージョンに作成できます。

地域	リージョン名	リージョンの説明
北米
	`northamerica-northeast1` ^*	モントリオール	低 CO₂
	`northamerica-northeast2`	トロント	低 CO₂
	`us-central1`	アイオワ	低 CO₂
	`us-east1`	サウスカロライナ
	`us-east4`	北バージニア
	`us-east5`	コロンバス
	`us-south1`	ダラス	低 CO₂
	`us-west1`	オレゴン	低 CO₂
	`us-west2`	ロサンゼルス
	`us-west3`	ソルトレイクシティ
	`us-west4`	ラスベガス
	`northamerica-south1` ^*	ケレタロ
南アメリカ
	`southamerica-east1`	サンパウロ	低 CO₂
	`southamerica-west1`	サンチアゴ	低 CO₂
ヨーロッパ
	`europe-central2`	ワルシャワ	低 CO₂
	`europe-north1`	フィンランド	低 CO₂
	`europe-north2`	ストックホルム	低 CO₂
	`europe-southwest1`	マドリッド	低 CO₂
	`europe-west1`	ベルギー	低 CO₂
	`europe-west2`	ロンドン	低 CO₂
	`europe-west3`	フランクフルト
	`europe-west4`	オランダ	低 CO₂
	`europe-west6`	チューリッヒ	低 CO₂
	`europe-west8`	Milan	低 CO₂
	`europe-west9`	パリ	低 CO₂
	`europe-west10`	ベルリン
	`europe-west12`	トリノ	低 CO₂
中東
	`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）は、ゾーン分割をサポートしていません。つまり、これらのリージョン内の複数のゾーンが、物理的に分離されたデータセンターキャンパスに配置されていない可能性があります。そのため、局所的な物理的災害が 1 つ発生すると、同じリージョン内の複数のゾーンに影響が及ぶ可能性があり、ゾーン分割をサポートするリージョンと比較してデータ損失のリスクが高まります。

サポートされているマルチリージョン

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 つの別々のゾーンに冗長的に保存されます。

マルチリージョンロケーションに作成された Backup Vault は、単一リージョンの停止に対する復元力を備えています。バックアップデータは、少なくとも 2 つのリージョンに冗長的に保存されます。

マルチリージョン Backup Vault とクロスリージョン Backup Vault の比較

条件	マルチリージョンのバックアップ	リージョン間でのバックアップ
バックアップの作成	Google によって、大陸内の 2 つのリージョン間で自動的に行われます。	バックアップを作成するリージョンを明示的に定義する自律性。
ユースケース	高可用性とシンプルな運用	厳格なコンプライアンス、データ所在地に関する法律、またはソースリージョンの境界の内外にあるターゲット障害復旧サイト。
管理	オーバーヘッドが少ない。単一の Vault、自動バランス調整	オーバーヘッドは中程度です。特定のターゲットペアリングを設定する必要があります。
顧客管理の暗号鍵（CMEK）	マルチリージョン Backup Vault は、Backup Vault と同じリージョンの CMEK を使用する必要があります。	クロスリージョン Backup Vault は、Backup Vault と同じリージョンの CMEK を使用する必要があります。
費用への影響	マルチリージョンのアップロードとダウンロードの料金（該当する場合）。マルチリージョン Vault のバックアップストレージ料金。管理手数料。	リージョン間のデータ転送料金。バックアップストレージ料金。管理手数料。
対応しているワークロード	Compute Engine インスタンス Compute Engine ディスク Cloud SQL インスタンス	Compute Engine インスタンス Compute Engine ディスク Filestore インスタンス

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 の作成時に有効にする必要があります。

Vault の最小保持期間が 3 日で、バックアッププランの保持期間が 7 日の場合、バックアップは 7 日間ロックされます。結果: 手動での削除が完全に防止されます。バックアップは、バックアッププランの特定の期間が終了した後にのみ自動的に削除されます。
適用される保持期間をロックする: 厳格なコンプライアンス要件に対応するため、適用される最短保持期間の構成を永続的にロックできます。

ロックを設定する際に、発効日を選択します。発効日前であれば、最短保持期間を調整して誤りを修正できます。発効日を過ぎると、プロジェクトオーナーであっても保持期間を短縮することはできません。増やすことのみが可能です。

Backup Vault のアクセス制限

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）をご覧ください。