Backup and DR は、Google Cloud コンソールからの Cloud SQL インスタンス、AlloyDB クラスタ、Compute Engine インスタンス、個々のディスクのバックアップをサポートしています。これらのリソースのバックアップと復元の手順については、ドキュメントをご覧ください。すべてのワークロードがこれらのカテゴリに該当する場合は、バックアップ / 復元アプライアンスは必要ありません。
Compute Engine インスタンス内で実行される VMware VM、SAP HANA、IBM Db2、Oracle、Microsoft SQL Server データベースのバックアップと DR には、Backup and DR アプライアンス管理コンソールと 1 つ以上のバックアップ / 復元アプライアンスが必要です。この設定を使用する場合は、バックアップするアプリケーションに合わせてバックアップ / リカバリ アプライアンスのサイズを選択する必要があります。この設定のフローでは、管理サーバーを作成し、アプライアンスをデプロイします。その後、アプライアンス管理コンソールを使用してバックアップ スケジュールを構成し、バックアップ対象とバックアップ先を定義します。
バックアップ / リカバリ アプライアンスを最も効果的に使用するための戦略の概要については、バックアップ / リカバリ アプライアンスのデプロイに関する考慮事項をご覧ください。
このページでは、Backup and DR の初期有効化を行い、プロジェクトの構成を設定する方法について説明します。
バックアップ / リカバリ アプライアンス アーキテクチャのコンポーネント
Backup and DR アーキテクチャは、次のコンポーネントを介して提供されます。
Google Cloud コンソール: Google Cloud コンソールには、Persistent Disk のボールト バックアップ、Compute Engine インスタンスのバックアップ プラン、Cloud SQL の拡張バックアップを一元管理するための Backup and DR プロダクトが含まれています。
アプライアンス管理コンソール: アプライアンス管理コンソールは、バックアップ / 復元アプライアンスの管理プレーンとして機能します。各 Backup and DR のデプロイには、任意の数のバックアップ / リカバリ アプライアンスを管理する単一のアプライアンス管理コンソールが含まれています。アプライアンス管理コンソールはバックアップ管理プロジェクトにデプロイされ、デプロイされたリージョン内で高可用性を実現し、ゾーンの停止に対する復元力を提供します。
バックアップ / リカバリ アプライアンス: バックアップ / リカバリ アプライアンスは、企業内のバックアップ データのライフサイクルを効率的にキャプチャ、移動、管理するデータムーバーです。バックアップ / リカバリ アプライアンスは、クラウド ワークロードのワークロード エンティティにデプロイされます。複数のバックアップ / リカバリ アプライアンスをデプロイする場合は、各アプライアンスを一意のサービス アカウントに関連付ける必要があります。
バックアップと DR エージェント: バックアップと DR エージェントは、アプリケーション ネイティブの API を呼び出して、本番環境アプリケーションから永久増分方式でデータを効率的にキャプチャし、復旧時にアプリケーション認識を提供します。エージェントは、保護対象のアプリケーションが存在するアプリケーション ホストにインストールされます。VM 全体またはディスクのサブセットのみを保護する場合は、Backup and DR エージェントは必要ありません。
アプライアンス管理コンソールは、サービス プロデューサーの VPC ネットワークで有効になります。このサービス プロデューサー VPC は、プライベート Google アクセスを使用してプロジェクトと通信します。
管理サーバーとアプライアンス間、アプライアンス間、アプライアンスとホスト エージェント間の通信は、相互 TLS 認証によって保護されます。
Google Cloud コンソールで Backup and DR を設定する
Google Cloud コンソールに移動して、backupdr API を有効にし、アカウントの権限を設定します。
Google Cloud Backup and DR を有効にする
バックアップ / リカバリ アプライアンス タイプ
Backup and DR には、Compute Engine VM、VMware VM、データベース、ファイル システムなど、さまざまなワークロードに最適化されたアプライアンス タイプが用意されています。ニーズに最適なアプライアンス タイプを選択できます。ワークロードに最適なアプライアンス タイプを選択することが重要です。バックアップ / リカバリ アプライアンスは、サービスを開始すると、常に実行され、バックアップ、復元、その他のジョブをいつでも実行および再実行できます。
Backup and DR には、次のアプライアンス タイプがあります。
- VMware VM とその他のデータベースまたはリソース向けの標準: この n2-standard-16 マシンタイプは、本番環境データベース、VMware VM、その他のリソースをバックアップするための最適なパフォーマンスをサポートします。このアプライアンスは、デプロイ時に 4 TB のバランスディスク容量を追加します。また、4 TB のディスクを 63 個追加できます。このアプライアンスでは、最大 1,500 個のアプリケーションと 5,000 個の日次スナップショットを管理できます。
- Compute Engine VM または SAP HANA データベースの標準: この e2-standard-4 マシンタイプは、Compute Engine インスタンス、Cloud SQL インスタンス、AlloyDB クラスタ、バックアップに Persistent Disk を使用するデータリソース（Persistent Disk を使用するように構成された IBM Db2 データベースと SAP HANA データベース）のバックアップに最適です。このアプライアンス タイプの Persistent Disk の最小容量は 10 GB です。このアプライアンスは、最大 5,000 個の Compute Engine インスタンスと Cloud SQL インスタンス、AlloyDB クラスタ、Persistent Disk ベースのデータ アプリケーションを管理できます。
VMware VM とその他のデータベースまたはリソース用の基本: この e2-standard-16 マシンタイプは、データベース、VMware VM、その他のリソースをバックアップするための適度なパフォーマンスをサポートします。このアプライアンスでは、最大 1,500 個のアプリケーションと 5,000 個の日次スナップショットを管理できます。このアプライアンスは、デプロイ時に 4 TB の標準ディスク容量を追加します。次のタイプの 4 TB ディスクを 63 個追加できます。
- 最小容量の 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 容量が追加されます。
アプライアンスをデプロイすると、アプライアンスの種類に関係なく、サービス アカウントが自動的に作成されます。サービス アカウントは、[サービス アカウント] ページで確認できます。
サービス アカウントの名前は、次のメールアドレス形式で表示されます。
APPLIANCE_NAME@PROJECT_ID.iam.gserviceaccount.com
次のように置き換えます。
- APPLIANCE_NAME: バックアップ / リカバリ アプライアンスの名前。
- PROJECT_ID: Google Cloud プロジェクト（ソース）の ID。
長期の保持が必要なバックアップは、データへのアクセス頻度に応じて、Standard、Nearline、Coldline Storage に移動できます。
ファイアウォール構成
Backup and DR への上り（内向き）に必要な次のファイアウォール ルールが自動的に追加されます。
| 目的 | ソース | ターゲット | ポート（TCP） |
|---|---|---|---|
| サポート トラフィック（アプライアンスへのサポート） | SSH_CLIENT_IP | バックアップ / リカバリ アプライアンス | 26 |
| iSCSI バックアップ（ホストからアプライアンス） | AGENT_HOST_IP | バックアップ / リカバリ アプライアンス | 3260 |
| StreamSnap トラフィック（アプライアンス間） | SOURCE_APPLIANCE_IP | バックアップ / リカバリ アプライアンス | 5107 |
| バックアップ / リカバリ アプライアンスからアプライアンス管理コンソールへの接続 | APPLIANCE_IP | *.backupdr.googleusercontent.com | 443 |
次のように置き換えます。
- SSH_CLIENT_IP: SSH クライアントを実行しているホストの IP アドレス。
- AGENT_HOST_IP: Backup and DR エージェントを実行しているホストの IP アドレス。
- SOURCE_APPLIANCE_IP: 移行元アプライアンスの IP アドレス。
- APPLIANCE_IP: Backup/Recovery アプライアンスの IP アドレスまたはサブネット。
このルールの構成方法の詳細については、Backup and DR のデプロイを準備するをご覧ください。
Backup and DR エージェントを実行しているホストの場合は、次の TCP ポートを手動で追加して、上り（内向き）ファイアウォール ルールとの接続を許可する必要があります。
| 目的 | ソース | ターゲット | ポート（TCP） |
|---|---|---|---|
| エージェントのトラフィック（アプライアンスからホスト） | バックアップ / リカバリ アプライアンス | Backup and DR エージェントを実行しているホスト | 5106 |
バックアップ トラフィックに NFS を使用するホスト、またはマウントに NFS を使用する Google Cloud 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 |
ワルシャワ |
低 CO2
|
|
europe-north1 |
フィンランド |
低 CO2
|
|
europe-north2 |
ストックホルム |
低 CO2
|
|
europe-southwest1 |
マドリッド |
低 CO2
|
|
europe-west1 |
ベルギー |
低 CO2
|
|
europe-west2 |
ロンドン |
低 CO2
|
|
europe-west3 |
フランクフルト | ||
europe-west4 |
オランダ |
低 CO2
|
|
europe-west6 |
チューリッヒ |
低 CO2
|
|
europe-west8 |
Milan |
低 CO2
|
|
europe-west9 |
パリ |
低 CO2
|
|
europe-west10 |
ベルリン | ||
europe-west12 |
トリノ |
低 CO2 |
|
| 中東 | |||
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 つ発生すると、同じリージョン内の複数のゾーンに影響が及ぶ可能性があり、ゾーン分割をサポートするリージョンと比較してデータ損失のリスクが高まります。
バックアップ / リカバリ アプライアンスがサポート対象の地域
バックアップ / リカバリ アプライアンスは、任意の Google Cloud ゾーンにデプロイできます。
バックアップ / リカバリ アプライアンスのデプロイを実行するワークフロー サービスは、記載されているリージョンでサポートされています。バックアップ / リカバリ アプライアンスがデプロイされているリージョンで Workflow サービスが利用できない場合、Backup and DR はデフォルトで us-central1 リージョンでワークフローを実行します（アプライアンス自体は、選択したリージョンに作成されます）。他のリージョンにリソースを作成できないように設定されている組織のポリシーがある場合は、us-central1 リージョンにリソースを作成できるように、組織のポリシーを一時的に更新する必要があります。バックアップ / リカバリ アプライアンスのデプロイ後に us-central1 リージョンを制限できます。