Backup and DR サービスは、 Google Cloud コンソールからの Cloud SQL インスタンス、Compute Engine インスタンス、個々のディスクのバックアップをサポートしています。これらのリソースのバックアップと復元の手順については、 Google Cloud コンソールのドキュメントをご覧ください。すべてのワークロードがこれらのカテゴリに該当する場合は、バックアップ/復元アプライアンスは必要ありません。
Backup and DR Service は、Compute Engine インスタンス内で実行される VMware VM、SAP HANA、IBM Db2、Oracle、Microsoft SQL Server データベースのバックアップもサポートしています。これらのバックアップには、バックアップと DR の管理コンソールと 1 つ以上のバックアップ/リカバリ アプライアンスが必要です。この設定を使用する場合は、バックアップするアプリケーションに合わせてバックアップ/リカバリ アプライアンスのサイズを選択する必要があります。この設定のフローでは、管理サーバーの作成、アプライアンスのデプロイを行い、Backup and DR 管理コンソールを使用してバックアップ スケジュールを構成し、バックアップ対象とバックアップ先を定義します。
このページでは、Backup and DR Service の初回有効化を行い、プロジェクトの構成を設定する方法について説明します。
始める前に
バックアップ/リカバリ アプライアンスのデプロイ方法を計画する前に、バックアップ/リカバリ アプライアンスのデプロイに関する考慮事項を確認することをおすすめします。
バックアップ/リカバリ アプライアンス アーキテクチャのコンポーネント
Backup and DR サービスのアーキテクチャは、次のコンポーネントで提供されます。
Google Cloud コンソール: Google Cloud Google Cloud コンソールには、Persistent Disk の Vaulted バックアップ、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 コンソールに移動して、Backup and DR Service API を有効にし、アカウントの権限を設定します。
Google Cloud Backup and DR を有効にする
バックアップ/リカバリ アプライアンスのタイプ
Backup and DR Service には、さまざまなワークロード（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 インスタンス、バックアップに Persistent Disk を使用するデータリソース（Persistent Disk を使用するように構成された IBM Db2 データベースと SAP HANA データベース）のバックアップに最適です。このアプライアンス タイプには、最小 10 GB の永続ディスク容量があります。このアプライアンスは、最大 5,000 個の Compute Engine インスタンスと Cloud SQL インスタンス、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 容量が追加されます。
アプライアンスをデプロイすると、アプライアンスのタイプに関係なく、サービス アカウントが自動的に作成されます。サービス アカウントは、[サービス アカウント] ページで確認できます。
サービス アカウントの名前は、メールアドレスの形式 my-service-account@my-project.iam.gserviceaccount.com で表示されます。ここで、appliance-name はアプライアンスの名前、projectid は Google Cloud プロジェクトの ID です。
長期の保持が必要なバックアップは、データへのアクセスが必要になる可能性に応じて、 Google Cloud Standard、Nearline、Coldline ストレージに移動できます。
ファイアウォールの構成
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 を使用する 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 |
ワルシャワ | ||
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 |
ミラノ | ||
europe-west9 |
パリ |
低 CO2
|
|
europe-west10 |
ベルリン | ||
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 リージョンを制限できます。