このページでは、Backup and DR Service の初回有効化を行い、プロジェクトの構成を設定する方法について説明します。
バックアップと DR のアーキテクチャのコンポーネント
Backup and DR サービスのアーキテクチャは、次のコンポーネントで提供されます。
管理コンソール: 管理コンソールは、バックアップ/復元アプライアンスの管理プレーンとして機能します。各バックアップと DR のデプロイには、任意の数のバックアップ/リカバリ アプライアンスを管理する単一の管理コンソールが含まれています。管理コンソールはバックアップ管理プロジェクトにデプロイされ、デプロイされたリージョン内で高可用性を実現し、ゾーンの停止に対する復元力を提供します。
バックアップ/リカバリ アプライアンス: バックアップ/リカバリ アプライアンスは、企業内のバックアップ データのライフサイクルを効率的にキャプチャ、移動、管理するデータムーバーです。バックアップ/リカバリ アプライアンスは、クラウド ワークロードのワークロード エンティティにデプロイされます。
バックアップと DR エージェント: バックアップと DR エージェントは、アプリケーション ネイティブ API を呼び出して、永久増分方式で本番環境アプリケーションからデータを効率的にキャプチャし、復元時にアプリケーション認識を提供します。エージェントは、保護対象のアプリケーションが存在するアプリケーション ホストにインストールされます。VM 全体またはディスクのサブセットのみを保護する場合は、Backup and DR エージェントは必要ありません。
管理コンソールがサービス プロデューサー VPC ネットワークで有効になっている。このサービス プロデューサー VPC は、限定公開の Google アクセスを使用してプロジェクトと通信します。
管理サーバーとアプライアンス間、アプライアンス間、アプライアンスとホスト エージェント間の通信は、相互 TLS 認証によって保護されます。
実装に関する注意事項
バックアップと DR サービスのデプロイ方法に影響する重要な考慮事項は次のとおりです。
組織の目標復旧時間（RTO）の要件を教えてください。RTO は、データが利用できない状態が許容される最大時間です。たとえば、RTO が 4 時間の場合、障害発生から 4 時間以内にデータにアクセスできる必要があります。
バックアップ管理を一元化する必要がありますか？バックアップを一元管理するかどうかを決定する必要があります。
- 一元化されたバックアップ管理とは、すべてのビジネス部門のすべてのワークロードのバックアップを管理するための単一の管理コンソールがあることを意味します。これにより、単一の管理コンソールを管理するだけで済むため、バックアップをより効率的に管理できます。
- バックアップ管理が分散化されている場合、各ビジネス部門に個別の管理コンソールがあります。運用モードは組織によって異なります。
バックアップのユースケースは何ですか？本番環境リージョンで障害が発生した場合に備えて障害復旧用のバックアップが必要ですか。それとも、データをローカルで保護するだけで十分ですか？障害復旧機能が必要な場合は、クロスリージョン バックアップを検討する必要があります。つまり、バックアップを複数の場所に保存することで、1 つの場所が災害の影響を受けても、データにアクセスできるようになります。
ワークロードが単一のリージョンにある
リージョン内の最適なバックアップ戦略は、ニーズによって異なります。
障害復旧（DR）が不要な場合
パフォーマンスを最大化してコストを削減するには、ワークロードが実行されているリージョンと同じリージョンに管理コンソールとバックアップ/復元アプライアンスをデプロイします。バックアップ イメージをワークロードと同じリージョンに保存します。
バックアップ コピーをオフサイトに保存する場合は、バックアップを別のリージョンに保存するか、デュアルリージョン ストレージまたはマルチリージョン ストレージを使用します。バックアップを別のリージョンに保存すると、ネットワーク料金とストレージ料金が発生します。
バックアップと DR の両方が必要な場合
パフォーマンスを最大化し、コストを削減するには、本番環境のワークロード リージョンと同じリージョンに管理コンソールをデプロイし、障害復旧に使用できるリージョンに 2 つ目の管理コンソールをデプロイします。
バックアップ/リカバリ アプライアンスを本番環境のワークロード リージョンと DR リージョンの両方にデプロイして、リカバリ時間目標（RTO）を最小限に抑えます。これにより、災害発生時に DR 環境が完全に事前プロビジョニングされ、使用可能になります。
バックアップ イメージを本番環境リージョンに保存し、コピーを障害復旧 DR リージョンに保存するか、デュアルリージョン ストレージまたはマルチリージョン ストレージを使用します。本番環境リージョンのバックアップ コピーは、高速なパフォーマンスでルーティン バックアップのニーズを満たすことができます。DR リージョンにコピーされたデータは、本番環境リージョンがダウンした場合にワークロードを復元するために使用できます。
ワークロードが複数のリージョンにある
リージョン間の最適なバックアップ戦略は、ニーズによって異なります。
障害復旧（DR）が不要な場合
パフォーマンスを最大化してコストを削減するには、ワークロードが実行されているリージョンのいずれかに管理コンソールをデプロイします。これにより、すべてのワークロードとリージョンで一元管理が可能になります。
ワークロードが実行されている各リージョンに 1 つ以上のバックアップ/復元アプライアンスをデプロイします。バックアップはワークロードと同じリージョンに保存します。
バックアップ コピーをオフサイトに保存する場合は、バックアップを別のリージョンに保存するか、デュアルリージョン ストレージまたはマルチリージョン ストレージを使用します。バックアップを別のリージョンまたはマルチリージョンに保存すると、ネットワーク料金とストレージ料金が発生します。
バックアップと DR の両方が必要な場合
本番環境のワークロード リージョンごとに管理コンソールをデプロイし、DR リージョンにも別の管理コンソールをデプロイします。
バックアップ/リカバリ アプライアンスを本番環境のワークロード リージョンと DR リージョンの両方にデプロイして、復旧時間目標（RTO）を最小限に抑えます。これにより、障害発生時に DR 環境が完全に事前プロビジョニングされ、使用可能になります。
バックアップを本番環境のワークロード リージョンに保存し、コピーを DR リージョンに保存するか、デュアルリージョンまたはマルチリージョン ストレージを使用します。本番環境リージョンのバックアップ コピーは、バックアップのニーズを満たすために使用できます。
本番環境リージョンがダウンした場合、DR のバックアップ イメージを使用してワークロードを復元できます。
Google Cloud コンソールで Backup and DR サービスを設定する
Google Cloud コンソールに移動して、Backup and DR Service API を有効にし、アカウントの権限を設定します。
Google Cloud のバックアップと DR を有効にする
バックアップ/リカバリ アプライアンスのタイプ
Backup and DR Service には、さまざまなワークロード（Compute Engine VM、VMware VM、データベース、ファイル システム）用に最適化されたアプライアンス タイプが用意されています。ニーズに最適なアプライアンス タイプを選択できます。ワークロードに最適なアプライアンス タイプを選択することが重要です。バックアップ/リカバリ アプライアンスがサービスを開始すると、永続的に実行され、バックアップ、復元、その他のジョブをいつでも実行して再実行できます。
Backup and DR サービスには、次のアプライアンス タイプがあります。
- Compute Engine VM または SAP HANA データベースの標準: Persistent Disk を使用して Compute Engine インスタンスまたは SAP HANA データベースのみをバックアップする場合は、このオプションを選択します。デフォルトでは、このアプライアンスは、最小 Persistent Disk 容量が 10 GB の e2-standard-4 マシンタイプを追加します。このアプライアンスは、最大 5,000 台の Compute Engine VM を管理できます。
- VMware VM およびその他のデータベースまたはリソース向けの標準: データベース、VMware VM、その他のリソースのバックアップに最適なパフォーマンスをサポートする標準構成が必要な場合は、このオプションを選択します。デフォルトでは、このアプライアンスは n2-standard-16 マシンタイプを追加します。これにより、最小ディスク容量として 4 TB のバランス ディスク容量が追加されます。このアプライアンスは最大 1,500 個のアプリケーションを管理できます。
VMware VM およびその他のデータベースまたはリソース用の基本: データベース、VMware VM、その他のリソースのバックアップに中程度のパフォーマンスをサポートする基本構成が必要な場合は、このオプションを選択します。デフォルトでは、このアプライアンスは e2-standard-16 マシンタイプを追加します。このアプライアンスは最大 1,500 個のアプリケーションを管理できます。次のいずれかのディスクタイプを選択してデータを保存できます。
- 最小容量の Persistent Disk: このオプションでは、最小ディスク容量が 10 GB になります。このストレージ タイプでは、バックアップは Persistent Disk スナップショットとして保存され、バックアップ/リカバリ アプライアンスのローカル ストレージを使用しません。
- 標準永続ディスク: 効率的なブロック ストレージが必要な場合は、このストレージ タイプを選択します。Compute Engine VM のほか、I/O 負荷が中～高度の Google Cloud VMware Engine VM、データベース、ファイル システムのアプリケーションにおすすめします。これにより、最小ディスク容量として 4 TB の Persistent Disk 容量が追加されます。
- SSD 永続ディスク: 高速ブロック ストレージが必要な場合は、このストレージ タイプを選択します。Compute Engine VM のほか、I/O 負荷が非常に高い Google Cloud VMware Engine、データベース、ファイル システムのアプリケーションにおすすめします。これにより、最小ディスク容量として 4 TB の Persistent Disk 容量が追加されます。
アプライアンスをデプロイすると、アプライアンスのタイプに関係なく、サービス アカウントが自動的に作成されます。サービス アカウントは、[サービス アカウント] ページで確認できます。
サービス アカウントの名前は、メールアドレスの形式（my-service-account@my-project.iam.gserviceaccount.com）で表示されます。ここで、appliance-name はアプライアンスの名前、projectid は Google Cloud プロジェクトの ID です。
ストレージの種類を選択する
バックアップ/リカバリ アプライアンスは、バックアップ データをローカル アプライアンスのスナップショット プールに保存します。長期保存のためにオブジェクト ストレージにコピーできます。Google Cloud には、次の 3 種類のローカル オブジェクト ストレージがあります。
最小容量の Persistent Disk: バックアップ イメージは、バックアップ/リカバリ アプライアンスのローカル ストレージを使用しない Persistent Disk スナップショットとして保存されます。
標準永続ディスク: このストレージ タイプは、4 TB の永続ディスクをはじめとする効率的なブロック ストレージを提供します。I/O 負荷が中～高度の VMware Engine や、データベースまたはファイル システムのアプリケーションにおすすめします。
SSD 永続ディスク: このストレージ タイプは、4 TB の永続ディスクをはじめとする高速ブロック ストレージを提供します。これは、I/O 負荷が非常に高い Google CloudVMware Engine VM やデータベースまたはファイル システムのアプリケーションにおすすめします。
ディスクプールの容量は後で拡張できます。
長期の保持が必要なバックアップは、データへのアクセス頻度に応じて Google Cloud Standard、Nearline、Coldline ストレージに移動できます。
バックアップと DR サービスに推奨されるネットワーク トポロジ
Google Cloud は、Backup and DR Service のデプロイ時に共有 VPC を使用することをおすすめします。共有 VPC を使用すると、組織は複数のプロジェクトから共通の VPC（VPC）ネットワークにリソースを接続できるため、そのネットワークの内部 IP を使用して、安全で効率的な相互通信を行うことができます。共有 VPC を使用する場合、プロジェクトをホスト プロジェクトとして指定し、他のサービス プロジェクトをホスト プロジェクトに接続します。ホスト プロジェクトの VPC ネットワークは、共有 VPC ネットワークと呼ばれます。サービス プロジェクトの適格リソースは、共有 VPC ネットワーク内のサブネットを使用できます。
共有 VPC を使用すると、組織管理者は、サブネット、ルート、ファイアウォールなどのネットワーク リソースを一元管理しながら、インスタンスの作成や管理などの管理責任をサービス プロジェクト管理者に委任できます。
管理コンソールは、サービス プロデューサー VPC ネットワークの VPC にアクティブ化されます。このサービス プロデューサー VPC は、限定公開の Google アクセスを使用してプロジェクトと通信します。この接続の主な目的は、管理コンソールとバックアップ/復元アプライアンスがメタデータを交換することです。バックアップ トラフィックはこのリンクを通過しません。ただし、管理コンソールは、任意のネットワークにデプロイされたすべてのバックアップ/リカバリ アプライアンスと通信する必要があります。
共有 VPC のベスト プラクティス
次のベスト プラクティスをおすすめします。
管理コンソールへの接続: サービス プロバイダ ネットワークをネットワーク内の共有 VPC に接続することをおすすめします。管理コンソールからのトラフィックはすべてこの VPC を通過するため、ホスト プロジェクトを通過します。共有 VPC を介して Backup and DR Service への接続をプロビジョニングすると、ワークロードが実行されているプロジェクト（サービス プロジェクト）と Backup and DR Service 間のシームレスな接続も可能になります。
バックアップ/リカバリ アプライアンスの場所: バックアップ/リカバリ アプライアンスは、管理コンソールへの接続用に限定公開の Google アクセスが有効になっているサブネットにデプロイする必要があります。バックアップ/リカバリ アプライアンスのプロジェクトを選択する戦略として、次の 2 つをおすすめします。
中央ホスト プロジェクトの場合: この戦略では、Backup and DR サービスは IT 部門の中央サービスとして扱われます。中央のバックアップ チームがサービスのプロビジョニングを管理します。そのため、すべてのバックアップ/復元アプライアンスはホスト プロジェクトにプロビジョニングされ、中央管理者はすべてのバックアップ リソースを中央プロジェクトに統合できます。このアプローチには、バックアップ関連のすべてのリソースとその課金を 1 つのプロジェクトに統合できるというメリットがあります。
サービス プロジェクト内: この戦略は、サービス プロジェクトが作成され、その管理が分散チームに委任される、より分散型のチームに適しています。このシナリオでは、ダウンストリーム サービス プロジェクトに VPC をプロビジョニングすることをおすすめします。バックアップ/リカバリ アプライアンスは、これらの VPC 内のサービス プロジェクトにインストールされます。これにより、単一のプロジェクト内でワークロードとバックアップ/リカバリ アプライアンスをコロケーションできます。
限定公開の Google アクセス: バックアップ/復元アプライアンスをインストールするサブネットごとに限定公開の Google アクセスを有効にすることをおすすめします。これにより、バックアップ/復元アプライアンスが Compute Engine、Cloud Storage、Cloud Logging などの API と通信できるようになります。これは、モニタリングとアラートが機能するために重要です。 Google Cloud API への接続を簡素化して強化するには、構成オプションの概要セクションで説明されているように、
private.googleapis.comの DNS 解決を構成することを検討してください。また、バックアップ/復元アプライアンスから、TCP ポート443の CIDR 範囲199.36.153.8/30への接続を許可するようにファイアウォール ルールを構成します。
ファイアウォールの構成
Backup and DR Service への上り（内向き）に必要な次のファイアウォール ルールが自動的に追加されます。
| 目的 | ソース | ターゲット | ポート（TCP） |
|---|---|---|---|
| サポート トラフィック（アプライアンスへのサポート） | SSH クライアントを実行しているホスト | バックアップ / リカバリ アプライアンス | 26 |
| iSCSI バックアップ（ホストからアプライアンス） | Backup and DR エージェントを実行しているホスト | バックアップ / リカバリ アプライアンス | 3260 |
| StreamSnap トラフィック（アプライアンス間） | バックアップ / リカバリ アプライアンス | バックアップ / リカバリ アプライアンス | 5107 |
| バックアップ/リカバリ アプライアンスと管理コンソールの接続 | バックアップ/リカバリ アプライアンスの IP またはサブネット | *.backupdr.googleusercontent.com | 443 |
このルールの構成方法の詳細については、Backup and DR サービスのデプロイを準備するをご覧ください。
Backup and DR エージェントを実行しているホストについては、上り（内向き）ファイアウォール ルールを使用して接続を許可するために、次の TCP ポートを手動で追加する必要があります。
| 目的 | ソース | ターゲット | ポート（TCP） |
|---|---|---|---|
| エージェント トラフィック（アプライアンスからホスト） | バックアップ / リカバリ アプライアンス | Backup and DR エージェントを実行しているホスト | 5106 |
バックアップ トラフィックに NFS を使用するホスト、またはマウントに NFS を使用する VMware Engine で実行されている ESX ホストの場合は、次の TCP ポートと UDP ポートを手動で追加して、上り（内向き）ファイアウォール ルールで接続を許可する必要があります。
| 目的 | ソース | ターゲット | ポート（TCP/UDP） |
|---|---|---|---|
| NFS バックアップまたはマウント | エージェントを実行しているホストまたはマウントを実行している ESXi ホスト | バックアップ / リカバリ アプライアンス | 111、756、2049、4001、4045 |
このオペレーションで使用される権限の一覧については、Backup and DR のインストール権限のリファレンスをご覧ください。
サポートされるリージョン
次のセクションでは、管理コンソールとバックアップ/リカバリ アプライアンスでサポートされているリージョンの一覧を示します。
管理コンソールでサポートされているリージョン
Backup and DR サービスを使用して、任意のGoogle Cloud リージョンでサポートされているワークロードをバックアップできますが、管理コンソールを有効にできるのは次のリージョンのみです。
| 地域 | リージョン名 | リージョンの説明 | |
|---|---|---|---|
| 北米 | |||
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 つのゾーンがあります。まれに発生する災害の場合、これらのリージョンに保存されているデータが失われる可能性があります。
バックアップ/リカバリ アプライアンスでサポートされているリージョン
バックアップ/リカバリ アプライアンスは、任意の Google Cloud ゾーンにデプロイできます。
バックアップ/リカバリ アプライアンスのデプロイを実行するワークフロー サービスは、リストされているリージョンでサポートされています。バックアップ/復元アプライアンスがデプロイされているリージョンで Workflow サービスが利用できない場合、Backup and DR Service はデフォルトで us-central1 リージョンでワークフローを実行します（アプライアンス自体は選択したリージョンに作成されます）。他のリージョンでのリソースの作成を禁止するように設定された組織のポリシーがある場合は、us-central1 リージョンでのリソースの作成を許可するように組織のポリシーを一時的に更新する必要があります。バックアップ/リカバリ アプライアンスのデプロイ後に、us-central1 リージョンを制限できます。