Spanner のバックアップを使用すると、Spanner データベースのバックアップをオンデマンドで作成し、論理データの破損の原因となる演算子とアプリケーション エラーから保護できます。バックアップは可用性が高く、暗号化され、作成後の最大 1 年間保持できます。バックアップを作成すると、そのバックアップは、ソース データベースと同じインスタンス、リージョン、プロジェクトに配置されます。コンプライアンスやビジネス継続性の理由から、別のリージョンやプロジェクトでバックアップを復元する必要がある場合は、バックアップを別のリージョンまたはプロジェクトのインスタンスにコピーできます。バックアップを 1 年を超える期間保持するには、データベースをエクスポートすることをおすすめします。論理データの破損から保護するために、Spanner はポイントインタイム リカバリも備えています。データベースの削除からの保護を有効にして、データベースの誤削除を防止することもできます。
主な機能
データの整合性: バックアップとは、バックアップの
version_time
にある Spanner データベースのトランザクションの一貫性と外部一貫性を備えたコピーのことです。レプリケーション: バックアップはソース データベースと同じインスタンスに存在し、同じ地理的な場所に複製されます。 リージョン インスタンスの場合、バックアップは 3 つの読み取り / 書き込みゾーンのそれぞれに保存されます。マルチリージョン インスタンスの場合、バックアップは読み取り / 書き込みレプリカまたは読み取り専用レプリカが含まれるすべてのゾーンに保存されます。データベースのバックアップを別のリージョンまたはプロジェクトに保存する必要がある場合は、完了したバックアップをソース インスタンスから別のリージョンまたはプロジェクトにある宛先インスタンスにコピーできます。詳細については、バックアップをコピーするをご覧ください。
自動有効期限: すべてのバックアップには、バックアップが自動的に削除される日を定める、ユーザー指定の有効期限があります。 期限切れのバックアップは、Spanner により非同期に削除されます。そのため、バックアップの期限が切れてから実際に削除されるまでには、時間差が生じることがあります。
バックアップに推奨される方法
次の表に、いくつかのバックアップ戦略、プランの実装に推奨される方法、推奨される方法の最大保持期間を示します。
バックアップ戦略 | おすすめの方法 | 推奨される方法の最大保持期間 |
---|---|---|
ソース データベースと同じインスタンス、リージョン、プロジェクトにデータベースのバックアップを保存する | バックアップの作成。 | 1 年 |
ソース データベースから別のインスタンス、リージョン、またはプロジェクトにデータベースのバックアップを保存する(クロスリージョン バックアップまたはクロス プロジェクト バックアップなど) | バックアップを作成し、別のリージョンまたはプロジェクトのインスタンスにコピーします。 | 1 年 |
Cloud Storage にバックアップを保存する | データベースを Cloud Storage バケットにエクスポートします。バックアップと復元の詳細な比較については、バックアップと復元、インポートとエクスポートのいずれかを選択するをご覧ください。 | 無制限(削除されるまで保持) |
ポイントインタイム リカバリ(PITR) | 過去のポイントインタイムからデータを復元するには、[PITR] を選択します。データベース version_retention_period は、デフォルトの 1 時間から最大 7 日間に変更できます。 |
7 日 |
Identity and Access Management(IAM)を使用したアクセス制御
IAM では、バックアップを含む Spanner リソースへのアクセスを制御できます。IAM、ロール、権限を初めて使用する場合は、IAM の概要で概要を確認してください。
バックアップ リソースは、Spanner リソース階層でインスタンスごとにまとめられます。プロジェクト レベルまたはインスタンス レベルで IAM ポリシーを適用することをおすすめします。より細かく制御する必要がある場合は、バックアップ レベルとデータベース レベルでも IAM ポリシーを適用できますが、これは複雑であるため、おすすめしません。 バックアップには IAM ポリシーなどのデータベース メタデータは含まれないため、データベースを復元すると、データベースは最初に親インスタンスからポリシーを継承します。
このセクションでは、バックアップと復元にアクセスできる事前定義ロールについて説明します。
以下のロールは、バックアップ専用に設計されています。
spanner.backupAdmin
: バックアップの作成、表示、更新、コピー、削除のためのアクセス権があります。このロールでは、バックアップの IAM ポリシーの表示と管理も可能です。このロールはバックアップからデータベースを復元できません。spanner.backupWriter
: バックアップの作成とコピーを行うためのアクセス権がありますが、更新や削除はできません。このロールは、バックアップの作成を自動化するスクリプトで使用されます。
次のロールでも Spanner のバックアップにアクセスできます。
spanner.admin
: バックアップへの完全アクセス権があります。このロールには、すべての Spanner リソースへの完全アクセス権があります。owner
: バックアップへの完全アクセス権があります。editor
: バックアップへの完全アクセス権があります。viewer
: バックアップとバックアップ オペレーションを表示するためのアクセス権があります。このロールでは、バックアップの作成、更新、削除、コピーを行うことはできません。
詳細については、Spanner IAM をご覧ください。
バックアップ作成の仕組み
任意の Spanner データベースのバックアップを作成できます。これらのバックアップは、version_time
時点でのバックアップに、すべてのデータを含むデータベース(スキーマとセカンダリ インデックスを含む)があるという意味で完全です。バックアップには、version_time
より後に行われたデータやスキーマの変更は含まれません。バックアップには、ALTER DATABASE SET OPTIONS
コマンドで設定したデータベース オプションがすべて含まれますが、Identity and Access Management(IAM)ポリシーは含まれません。バックアップを作成すると、そのバックアップは、ソース データベースと同じインスタンス、リージョン、プロジェクトに配置されます。
バックアップは次の方法で作成できます。
- Google Cloud コンソールの場合:
- Google Cloud CLI の使用
- クライアント ライブラリの使用
- REST または RPC API の使用
バックアップを作成する際に、ソース データベース、バックアップ リソースの名前、有効期限(バックアップの作成時から最長 1 年)を指定する必要があります。必要に応じて、version_time
を指定することもできます。これを使用して、前の時点でのデータベースをバックアップできます。version_time
フィールドは通常、複数のデータベースのバックアップを同期させる、またはポイントインタイム リカバリを使用してデータを復元する目的に使用されます。version_time
が指定されていない場合、バックアップの create_time
に設定されます。バックアップの進行状況を追跡するために、バックアップ リソースと長時間実行バックアップ オペレーションが作成されます。新しく作成されたバックアップは、ソース データベースと同じインスタンス、リージョン、プロジェクトに配置されます。
バックアップの外部整合性を確保するために、Spanner によって、データベースのコンテンツが create_time
に固定されます。これにより、バックアップ オペレーションの実行中は、ガベージ コレクション システムによって関連するデータ値が削除されることが回避されます。その後、インスタンス内のすべての読み取り/書き込みゾーンと読み取り専用ゾーンで同時にデータのコピーが開始されます。ゾーンが一時的に使用不可になっている場合、そのゾーンがオンラインに戻って完了するまでバックアップは完了しません。オペレーションが完了したら、すぐにバックアップを復元できます。マルチリージョン インスタンスの場合、すべてのリージョンのすべての読み取り/書き込みゾーンと読み取り専用ゾーンは、バックアップが復元可能としてマークされる前にバックアップ レプリカを完了する必要があります。
バックアップには、データベースの変更ストリームのスキーマも含まれますが、既存の変更レコードは含まれません。変更ストリーム データは、それが説明する変更とほぼ同時にストリーミングして使用されます。そのため、Spanner ではこのデータがバックアップから除外されます。
バックアップのコピーの仕組み
Spanner のバックアップと復元を使用すると、Spanner データベースのバックアップを、あるインスタンスから別のリージョンまたはプロジェクトの別のインスタンスにコピーして、データ保護機能とコンプライアンス機能を強化できます。コピーされたバックアップには、元のバックアップと同じ主要機能が含まれます。また、コピーしたバックアップと同じインスタンスにコピーしたバックアップを復元して、クロスリージョンとクロスプロジェクトのバックアップと復元のユースケースをサポートできます。
一般的なクロスリージョンのユースケース
バックアップをコピーするための一般的なクロスリージョンのユースケースには、次のようなものがあります。
コンプライアンス要件や規制要件のために、別のリージョンでバックアップを維持する。
たとえば、コンプライアンス要件を満たすために、本番環境データから最も近いリージョンのインスタンスにデータベースのバックアップをコピーできます。
障害復旧や事業継続のために、別のリージョンでバックアップを維持する。
たとえば、障害復旧以外の目的で、ゼロ以外のリカバリ時間目標(RTO)とリカバリ ポイント目標(RPO)を使用してバックアップ データベースを宛先インスタンスにコピーできます。 その後、必要に応じて宛先インスタンスにコピーしたバックアップからデータベースを復元できます(アプリケーションの RTO と RPO の要件がゼロの場合は、障害復旧計画には Spanner のマルチリージョン構成をおすすめします)。
一般的なクロスプロジェクトのユースケース
バックアップをコピーするための一般的なクロスプロジェクトのユースケースには、次のようなものがあります。
- 運用、セキュリティ、コンプライアンスのいずれかの要件を満たすために、別のプロジェクトでバックアップ コピーを維持する。
開発プロジェクト、テスト プロジェクト、本番環境プロジェクトの間でデータをコピーして移動する。
たとえば、本番環境プロジェクトからテスト プロジェクトにデータを移動する場合は、本番環境データのバックアップを作成してから、バックアップをテスト プロジェクトにコピーします。コピー オペレーションが完了したら、コピーしたバックアップをテスト プロジェクトのインスタンスに復元できます。
データベースをプロジェクト間で移動する(移行中にダウンタイムが発生する場合がある)。
ソース バックアップ、宛先バックアップ、ソース バックアップの作成時点から 1 年以内の有効期限を指定することで、別のリージョンまたはプロジェクトの宛先インスタンスにバックアップをコピーできます。つまり、expiration_date
の値は現在のコピー リクエストが処理されてから 6 時間以上経過しており、ソース バックアップの create_time
から 366 日以内であることが必要です。
Spanner は、コピー バックアップ リクエストの開始時に、バックアップの進行状況を追跡するためにバックアップ リソースと長時間実行バックアップ オペレーションを作成します。バックアップは、宛先インスタンスのすべての読み取り / 書き込みゾーンと読み取り専用ゾーンにコピーされます。ゾーンが一時的に使用不可になっている場合、ゾーンがオンラインに戻るまでバックアップ コピーは完了しません。コピー中に宛先インスタンスを削除することはできません。コピー バックアップ オペレーションの進行状況と完了ステータスを追跡するには、バックアップの進行状況の表示の手順を行います。コピーが完了したら、不要になったソース バックアップを削除できます。コピーが完了したら、コピーしたバックアップで GetBackup
、UpdateBackup
、DeleteBackup
などのオペレーションを使用できます。
バックアップのコピーを開始するための前提条件
別のリージョンまたはプロジェクトのインスタンスにバックアップをコピーする場合は、まず宛先インスタンスを設定して構成する必要があります。宛先インスタンスは、バックアップのコピーが置かれるインスタンスです。100 処理単位まで小さく、ソース インスタンス(ソース バックアップが存在するインスタンス)と同じインスタンス構成にする必要はありません。復元を行う前に、宛先インスタンスに、ノードあたり 4 TB のストレージ上限に従ってデータベース サイズをサポートするのに十分なノードまたは処理ユニットがプロビジョニングされていることを確認します(たとえば、8 TB バックアップを復元するには少なくとも 2 つのノードが必要です)。新しい宛先インスタンスを作成するには、インスタンスを作成、管理するをご覧ください。
その他の考慮事項
追加の決定事項には以下が含まれます。
- ソース インスタンスから宛先インスタンスにバックアップをコピーすると、コピーされたバックアップはソース バックアップとは独立して存在します。コピー オペレーションが完了すると、ソース インスタンスに 1 つのバックアップ、宛先インスタンスに 1 つのバックアップが存在します。ソース インスタンスのバックアップが不要になった場合は、削除できます。
- リージョン インスタンスにバックアップをコピーすると、バックアップ データは、宛先インスタンスの 3 つの読み取り / 書き込みゾーンのそれぞれにコピーされます。
- マルチリージョン インスタンスにバックアップをコピーすると、バックアップ データは読み取り / 書き込みレプリカまたは読み取り専用レプリカを含むインスタンス内の各ゾーンにコピーされます。
- 複数のバックアップを同時にコピーできます。
- 宛先のバックアップは、コピープロセスがまだ進行中であっても更新や削除が可能です。宛先のバックアップを削除すると、結果的に進行中のコピー オペレーションがキャンセルされます。
- コピー オペレーションの進行中に、ソース インスタンスでバックアップを復元できます。
- コピー オペレーションは、完了する前にキャンセルできます。
コピー処理中は、次のオペレーションは許可されません。
- コピー オペレーションの進行中は、ソース バックアップを削除できません。
- コピーの進行中は、宛先のコピーしたバックアップで新しいコピーや復元を開始できません。コピーが完了すると再びコピーができるようになり、復元もできます。
Spanner バックアップが保存される場所
バックアップは Spanner のリソースです。各バックアップ リソースは、リソース階層内のソース データベースと同じインスタンスごとにまとめられ、リソースパスは projects/<project>/instances/<instance>/backups/<backup>
形式になります。ソース データベースが削除された後もバックアップは存在し続けますが、親インスタンスより長く存続することはできません。バックアップがある場合は、バックアップが誤って削除されないようにするために、Spanner インスタンスを削除できません。インスタンスを削除する場合は、バックアップとインスタンスを削除する前に、バックアップを復元し、復元したデータベースをエクスポートすることをおすすめします。
暗号化
Spanner バックアップ(データベースなど)は、Google マネージドまたは顧客管理の暗号化によって暗号化されます。バックアップには、デフォルトでデータベースと同じ暗号化構成が使用されますが、バックアップの作成時に別の暗号化構成を指定することで、この動作をオーバーライドできます。バックアップが CMEK 対応の場合は、バックアップの作成時に KMS 鍵のプライマリ バージョンを使用して暗号化されます。一旦バックアップが作成されると、KMS 鍵がローテーションされても、その鍵と鍵バージョンを変更することはできません。詳細については、CMEK を有効化したバックアップの作成をご覧ください。
デフォルトでは、コピーされたバックアップは、ソース バックアップ暗号化と同じ暗号化構成(Google 管理または顧客管理(CMEK))を使用します。この動作は、バックアップのコピー時に別の暗号化構成を指定することでオーバーライドできます。リージョン間でコピーするときに、コピーしたバックアップが CMEK で暗号化されるようにするには、宛先のリージョンに対応する KMS 鍵を指定します。
パフォーマンス
このセクションでは、Spanner での最適なバックアップ パフォーマンスについて説明します。
バックアップ時のパフォーマンス
バックアップを実行すると、Spanner はデータベースからバックアップ ストレージにデータを直接コピーするバックアップ ジョブを作成し、このジョブのサイズをデータベースのサイズに基づいて設定します。このバックアップ ジョブは、データベースのインスタンスに割り当てられた CPU リソースを使用しないため、インスタンスのパフォーマンスには影響しません。 また、データベースのインスタンスのコンピューティング負荷はバックアップ オペレーションの速度には影響しません。バックアップ オペレーションの進行状況と完了を追跡するには、バックアップの進捗状況の表示をご覧ください。
通常、ほとんどのバックアップには 1~4 時間かかります。バックアップのサイズが大きい場合や、リソースの内部キューがある場合は、バックアップに時間を要する可能性があります。他の要素が変更されていない状態でバックアップの時間が通常よりかかる場合は、ゾーン内のバックアップ タスクのスケジューリングが遅れている可能性があります。この処理には、最大で 30 分かかる場合があります。新しいバックアップでも同じスケジューリングの遅れが発生する可能性があるため、バックアップのキャンセルと再起動はしないことをおすすめします。
バックアップのコピー時のパフォーマンス
バックアップのコピーにかかる時間は、ソース バックアップのサイズやコピーされたバックアップに選択された宛先のリージョンなどの要因によって異なります。通常、ほとんどのコピーは 1~4 時間で完了します。バックアップのサイズと宛先のリージョンによっては、コピーにもっと時間がかかることがあります。バックアップをコピーしても、ソース インスタンスやデータベースにパフォーマンス上の影響はありません。パフォーマンスに影響を及ぼすことなく、別のリージョンのインスタンスにソース バックアップの複数のコピーを同時に作成できます。
料金
料金は、単位時間あたりのバックアップで使用されるストレージの量に基づいて課金されます。バックアップ オペレーションが完了すると課金が開始され、バックアップが削除されるまで継続されます。作成が完了したバックアップには、最低でも 24 時間分の料金が発生します。バックアップを作成し、完了してから 1 分後に削除した場合でも、24 時間分の料金が請求されます。
バックアップのコピーには、元のバックアップと同じストレージ費用が適用されます。異なるリージョンを占有する 2 つのインスタンス間でコピーを作成すると、アウトバウンド データ転送の費用が適用されます。
たとえば、ソースのマルチリージョン インスタンス構成 nam7
から宛先のマルチリージョン インスタンス構成 nam-eur-asia3
にデータベースをコピーする場合は、次の料金が適用されます。
us-central1
リージョンの重複は無料- 監視
us-central2
リージョンは無料 - 大陸間データ転送は、新しい大陸(ヨーロッパとアジア)ごとに 1 回ずつ、2 回適用されます。
- 同じ大陸内のリージョン間のデータ転送料金は
us-east1
に 1 回適用されます - 同じ大陸内のリージョン間のデータ転送料金はヨーロッパで 1 回適用されます
Spanner は、コピープロセスを最適化して、リージョン間転送の回数を最小限に抑えます。これにより、データ転送のコストを最小限に抑えながら、高速なコピー バックアップを実現できます。
バックアップは保存され、料金は別途請求されます。バックアップ ストレージは、データベース ストレージの料金やデータベースのストレージ制限には影響しません。詳細については、ストレージ使用率の指標をご覧ください。
バックアップ コストの詳細については、Spanner の料金をご覧ください。
次のステップ
バックアップと復元またはインポートとエクスポートの選択について学習する。
バックアップを作成して構成する方法について、バックアップを作成および管理するで確認する。