バックアップの概要

このドキュメントでは、Spanner のバックアップとバックアップ スケジュールの概要について説明します。

Spanner では、データベースのフル バックアップをオンデマンドで作成できます。また、バックアップ スケジュールを使用してフル バックアップまたは増分バックアップを作成することもできます。フル バックアップはデータベースのデータをすべて保存しますが、増分バックアップには前回のバックアップ以降に変更されたデータのみが含まれます。

オペレーター エラーやアプリケーション エラーが原因で論理データが破損した場合は、バックアップを復元できます。

バックアップには高可用性が備わっており、暗号化されていて、作成後の最大 1 年間保持できます。バックアップを作成すると、そのバックアップは、ソース データベースと同じインスタンス、リージョン、プロジェクトに配置されます。コンプライアンス上またはビジネス継続性の理由から、別のリージョンまたはプロジェクトのバックアップから復元する必要がある場合は、別のリージョンまたはプロジェクトのインスタンスにバックアップをコピーできます。

主な機能

  • データの整合性: Spanner データベースのバックアップは、バックアップの versionTime でトランザクションと外部一貫性を備えています。

  • レプリケーション: バックアップはソース データベースと同じインスタンスに存在し、同じ地理的な場所に複製されます。 リージョン インスタンスの場合、バックアップは 3 つの読み取り / 書き込みゾーンのそれぞれに保存されます。デュアルリージョン インスタンスとマルチリージョン インスタンスの場合、バックアップは読み取り / 書き込みレプリカまたは読み取り専用レプリカが含まれるすべてのゾーンに保存されます。データベースのバックアップを別のリージョンまたはプロジェクトに保存する必要がある場合は、完了したバックアップをソース インスタンスから別のリージョンまたはプロジェクトにある宛先インスタンスにコピーできます。詳細については、バックアップのコピーをご覧ください。

  • 自動有効期限: すべてのバックアップには、バックアップが自動的に削除される日を定める、ユーザー指定の有効期限があります。期限切れのバックアップは、Spanner により非同期に削除されます。そのため、バックアップの期限が切れてから実際に削除されるまでには、時間差が生じることがあります。

バックアップの作成

バックアップを作成すると、そのバックアップは、ソース データベースと同じインスタンス、リージョン、プロジェクトに配置されます。 バックアップには、バックアップの versionTime にあるデータベースの次の情報が含まれます。

  • フル バックアップにはすべてのデータが含まれます。増分バックアップには、前回のバックアップ以降に変更されたデータのみが含まれます。
  • スキーマ情報（テーブル名、フィールド、データ型、セカンダリ インデックス、変更ストリーム、これらのエンティティ間の関係など）。
  • ALTER DATABASE SET OPTIONS コマンドで設定されたすべてのデータベース オプション。

Spanner バックアップには、次の情報が含まれません。

  • versionTime より後に行われたデータやスキーマの変更。
  • Identity and Access Management（IAM）ポリシー
  • 変更ストリームのデータレコード。変更ストリーム スキーマは保存されますが、変更ストリーム データは、それが説明する変更とほぼ同時にストリーミングされ、使用されます。

バックアップの外部整合性を確保するために、Spanner によって、データベースのコンテンツが versionTime に固定されます。これにより、バックアップ オペレーションの実行中は、ガベージ コレクション システムによって関連するデータ値が削除されることが回避されます。その後、インスタンス内のすべての読み取り/書き込みゾーンと読み取り専用ゾーンで同時にデータのコピーが開始されます。ゾーンが一時的に使用不可になっている場合、そのゾーンがオンラインに戻るまでバックアップは完了しません。オペレーションが完了したら、すぐにバックアップを復元できます。マルチリージョン インスタンスの場合、すべてのリージョンのすべての読み取り/書き込みゾーンと読み取り専用ゾーンは、バックアップが復元可能としてマークされる前にバックアップ レプリカを完了する必要があります。

バックアップ スケジュール

Spanner では、データベースの完全バックアップまたは増分バックアップをスケジュールできます。増分バックアップには、前回のバックアップ以降に変更されたデータのみが含まれますが、フル バックアップにはデータベースのコンテンツ全体が保存されます。Spanner がバックアップを作成するバックアップ スケジュールのタイプ（フル バックアップまたは増分バックアップ）と頻度を指定できます。

フル バックアップ スケジュールでは、12 時間以上ごとにバックアップを作成できます。増分バックアップ スケジュールでは、4 時間以上ごとにバックアップを作成できます。

Spanner は、バックアップ スケジュールを使用してデータベースの増分バックアップを提供します。増分バックアップはオンデマンドで作成できません。

バックアップの作成は、スケジュールされた時刻から 4 時間以内に開始されます。データベースごとに最大 4 つのバックアップ スケジュールを設定できます。

増分バックアップ

増分バックアップは、フル バックアップ間のチェーンを形成します。増分バックアップ スケジュールによって作成される最初のバックアップはフル バックアップです。チェーンで作成される連続バックアップは増分バックアップであり、チェーン内の前回のバックアップ以降に変更されたデータのみが含まれます。

Spanner では、最初のフル バックアップに加えて、チェーンごとに最大 13 個の増分バックアップを許可します。チェーンは、対応する incrementalBackupChainId 値で識別されます。チェーンが最大長に達すると、Spanner は最初のフル バックアップから新しいチェーンを作成します。

シナリオによっては、チェーンの最大長に達する前に Spanner が新しいチェーンを作成することがあります。シナリオの例を次に示します。

  • 最も古いフル バックアップが 28 日以上前のものである。
  • チェーン内の最新のバックアップが削除されている。
  • 増分バックアップ スケジュールが変更されている。

増分バックアップの使用を決定する際に考慮すべき要素は次のとおりです。

  • 暗号化: 増分バックアップは、データベースが顧客管理の暗号鍵（CMEK）で暗号化されている場合でも、Google が管理する鍵を使用した暗号化のみをサポートします。

  • 復元: 増分バックアップの復元には、同じデータを含むフル バックアップの復元よりも時間がかかる場合があります。

  • 削除: チェーン内のバックアップを削除するか、期限切れになった場合、Spanner はチェーン内に存在する新しいバックアップ（存在する場合）をサポートするためにバックアップを保持することがあります。増分バックアップを復元するために、Spanner はチェーン内の古いバックアップをすべて必要とします。期限切れまたは削除されたバックアップのデータを含む、バックアップのチェーン内のすべてのデータを削除するには、チェーン内のすべてのバックアップを削除します。

  • 保持: 各バックアップ スケジュールには、スケジュールに関する情報を提供する次の用語があります。

    • creation_interval: バックアップ スケジュールに指定されたスケジュール頻度を表します。
    • retention_duration: スケジュールによって作成されたバックアップの保持期間。特定のチェーンでは、チェーン内の新しいバックアップのサポートに必要な場合は、最も古いフル バックアップが元の有効期限を過ぎても保持されます。フル バックアップの保持期間の合計は、次の値のうち短い方になります。
      • retention_duration + 28 日
      • retention_duration + (creation_interval*14)

  • バックアップ コピー: 増分バックアップをコピーすると、Spanner は最初のフル バックアップからコピーする特定の増分バックアップまで、バックアップのチェーンをコピーします。Spanner では、使用した合計ストレージに基づいて課金されます。

増分バックアップの作成の詳細については、バックアップ スケジュールの作成と管理をご覧ください。

フル バックアップと増分バックアップのストレージ費用

各 Spanner バックアップには、ストレージ使用量に関する情報を提供する次のフィールドがあります。

  • exclusiveSizeBytes: バックアップに必要なバイト数が表示されます。このサイズは、バックアップの課金対象となるサイズを表します。
  • freeableSizeBytes: バックアップを削除した場合に解放されるバイト数が表示されます。
  • oldestVersionTime: チェーン内の最も古いフルバックアップの versionTime が表示されます（そのバックアップが期限切れの場合でも表示されます）。このフィールドを使用して、保存されているデータを確認できます。

増分バックアップを使用すると、ストレージ費用を節約できます。増分バックアップは、チェーン内の前回のバックアップ以降の変更のみを保存する必要があるため、フル バックアップよりも exclusiveSizeBytes フィールドが大幅に小さくなる場合があります。チェーン内の各バックアップにこのフィールド値を追加すると、チェーン内のバックアップで使用された合計バイト数が反映されます。

増分バックアップは、復元の際に同じチェーン内の古いバックアップに依存します。つまり、新しい増分バックアップが存在する場合、チェーン内の古いバックアップのデータはすべてシステムから削除できず、同じチェーン内の古いバックアップの freeableSizeBytes フィールドはすべてゼロになります。

サイズが 100 GB で、毎日 10 GB ずつ増加するデータベースにフル バックアップ スケジュールと増分バックアップ スケジュールを作成したとします。次の表に、これらのバックアップ スケジュールで発生するストレージ費用を示します。

日 フル スケジュール バックアップのサイズ 増分スケジュール バックアップのサイズ
1 100 GB 100 GB
2 110 GB 10 GB
3 120 GB 10 GB
4 130 GB 10 GB
5 140 GB 10 GB

5 日間では、フル バックアップ スケジュールで 600 GB のストレージが使用され、増分バックアップ スケジュールで約 140 GB のストレージが使用されます。増分バックアップ スケジュールの場合、フル バックアップのサイズは、そのバックアップまでのチェーン内のすべてのバックアップのサイズの合計であり、sizeBytes フィールドに反映されます。

バックアップのコピーの仕組み

Spanner のバックアップと復元を使用すると、Spanner データベースのバックアップを、あるインスタンスから別のリージョンまたはプロジェクトの別のインスタンスにコピーして、データ保護機能とコンプライアンス機能を強化できます。コピーされたバックアップには、元のバックアップと同じ主要機能が含まれます。また、コピーしたバックアップと同じインスタンスにコピーしたバックアップをrestoreして、クロスリージョンとクロスプロジェクトのバックアップと復元のユースケースをサポートできます。

Spanner バックアップが保存される場所

バックアップは Spanner のリソースです。各バックアップ リソースは、リソース階層内のソース データベースと同じインスタンスごとにまとめられ、リソースパスは次の形式を使用します。

projects/PROJECT_ID/instances/INSTANCE_ID/backups/BACKUP_NAME

次のように置き換えます。

  • PROJECT_ID: プロジェクト ID。
  • INSTANCE_ID: インスタンス ID。
  • BACKUP_NAME: バックアップ名。

ソース データベースが削除された後もバックアップは存在し続けますが、親インスタンスより長く存続することはできません。バックアップがある場合は、バックアップが誤って削除されないようにするために、Spanner インスタンスを削除できません。インスタンスを削除する場合は、バックアップとインスタンスを削除する前に、バックアップを復元し、復元したデータベースをエクスポートすることをおすすめします。

暗号化

Spanner バックアップ（データベースなど）は、Google 管理の暗号鍵または顧客管理の暗号鍵（CMEK）によって暗号化されます。バックアップには、デフォルトでデータベースと同じ暗号化構成が使用されますが、バックアップの作成時に別の暗号化構成を指定することで、この動作をオーバーライドできます。バックアップが CMEK 対応の場合は、バックアップの作成時に KMS 鍵のプライマリ バージョンを使用して暗号化されます。バックアップを作成すると、KMS 鍵がローテーションされても、その鍵と鍵バージョンを変更できません。詳細については、CMEK を有効化したバックアップの作成をご覧ください。

コピーされたバックアップは、ソース バックアップ暗号化と同じ暗号化構成（Google 管理または顧客管理（CMEK））を使用します。この動作は、バックアップのコピー時に別の暗号化構成を指定することでオーバーライドできます。リージョン間でコピーするときに、コピーしたバックアップが CMEK で暗号化されるようにするには、宛先のリージョンに対応する Cloud KMS 鍵を指定します。

バックアップ スケジュールの作成または変更時に、暗号化構成を指定できます。バックアップ スケジュールで CMEK 鍵で暗号化されたバックアップを作成する場合は、鍵パスを指定する必要があります。

増分バックアップは、データベースが CMEK 鍵で暗号化されている場合でも、Google が管理する鍵のみを使用した暗号化をサポートしています。

パフォーマンス

このセクションでは、Spanner での最適なバックアップ パフォーマンスについて説明します。

バックアップ時のパフォーマンス

バックアップを実行すると、Spanner はデータベースからバックアップ ストレージにデータを直接コピーするバックアップ ジョブを作成し、このジョブのサイズをデータベースのサイズに基づいて設定します。このバックアップ ジョブは、データベースのインスタンスに割り当てられた CPU リソースを使用しないため、インスタンスのパフォーマンスには影響しません。 また、データベースのインスタンスのコンピューティング負荷はバックアップ オペレーションの速度には影響しません。バックアップ オペレーションの進行状況と完了を追跡するには、バックアップの進捗状況の表示をご覧ください。

通常、ほとんどのバックアップには 1～4 時間かかります。バックアップのサイズが大きい場合や、リソースの内部キューがある場合は、バックアップに時間を要する可能性があります。他の要素が変更されていない状態でバックアップの時間が通常よりかかる場合は、ゾーン内のバックアップ タスクのスケジューリングが遅れている可能性があります。この処理には、最大で 30 分かかる場合があります。新しいバックアップでも同じスケジューリングの遅れが発生する可能性があるため、バックアップのキャンセルと再起動はしないことをおすすめします。

バックアップのコピー時のパフォーマンス

バックアップのコピーにかかる時間は、ソース バックアップのサイズやコピーされたバックアップに選択された宛先のリージョンなどの要因によって異なります。通常、ほとんどのコピーは 1～4 時間で完了します。バックアップのサイズと宛先のリージョンによっては、コピーにもっと時間がかかることがあります。バックアップをコピーしても、ソース インスタンスやデータベースにパフォーマンス上の影響はありません。パフォーマンスに影響を及ぼすことなく、別のリージョンのインスタンスにソース バックアップの複数のコピーを同時に作成できます。

増分バックアップをコピーすると、Spanner はチェーン内の新しいバックアップをすべてコピーします。Spanner は、バックアップのチェーンを 1 つずつコピーするのではなく、すべてのバックアップを同時にコピーしてパフォーマンスを向上させます。

バックアップを削除する

増分バックアップを削除するときに、同じチェーンに新しい増分バックアップが存在する場合、ストレージが復元されないことがあります。新しい増分バックアップは、削除された増分バックアップとチェーン内の古いバックアップに存在するデータに依存します。Spanner はデータを保持し、新しい増分バックアップがすべて期限切れになった場合にのみストレージを解放します。freeableSizeBytes フィールドには、バックアップを削除した場合に回復できる保存容量が表示されます。

料金

料金は、単位時間あたりのバックアップで使用されるストレージの量に基づいて課金されます。バックアップ オペレーションが完了すると課金が開始され、バックアップが削除されるまで継続されます。作成が完了したバックアップには、最低でも 24 時間分の料金が発生します。バックアップを作成し、完了後すぐに削除した場合でも、24 時間分の料金が請求されます。

バックアップのコピーには、元のバックアップと同じストレージ費用が適用されます。異なるリージョンを占有する 2 つのインスタンス間でコピーを作成すると、アウトバウンド データ転送の費用が適用されます。

たとえば、ソースのマルチリージョン インスタンス構成 nam7 から宛先のマルチリージョン インスタンス構成 nam-eur-asia3 にデータベースをコピーする場合は、次の料金が適用されます。

  • us-central1 リージョンの重複は無料
  • 監視 us-central2 リージョンは無料
  • 大陸間データ転送は、新しい大陸（ヨーロッパとアジア）ごとに 1 回ずつ、2 回適用されます。
  • 同じ大陸内のリージョン間のデータ転送料金は us-east1 に 1 回適用されます
  • 同じ大陸内のリージョン間のデータ転送料金はヨーロッパで 1 回適用されます

Spanner は、コピープロセスを最適化して、リージョン間転送の回数を最小限に抑えます。これにより、データ転送のコストを最小限に抑えながら、高速なコピー バックアップを実現できます。

バックアップは保存され、料金は別途請求されます。バックアップ ストレージは、データベース ストレージの料金やデータベースのストレージ制限には影響しません。詳細については、ストレージ使用率の指標をご覧ください。

バックアップ コストの詳細については、Spanner の料金をご覧ください。

次のステップ