バックアップの概要

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

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

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

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

各バックアップには createTime と versionTime が関連付けられています。createTime は、Spanner がバックアップの作成を開始したタイムスタンプです。versionTime は、データベースの内容がバックアップにキャプチャされたときのタイムスタンプです。バックアップには、versionTime 時点でのデータベースの一貫性のあるビューが含まれています。

オンデマンド バックアップの場合、createTime と versionTime はデフォルトで同じです。必要に応じて、オンデマンド バックアップの作成時に、データベースのバージョン保持期間内にある古い versionTime を指定できます。

スケジュール設定されたバックアップの場合、versionTime はバックアップ スケジュールの作成時に選択した時間です。Spanner は versionTime から 4 時間以内にバックアップの作成を開始するため、createTime はこの 4 時間の期間内に収まります。これは、Spanner がリクエストを受信したときにバックアップの作成を開始するオンデマンド バックアップとは異なります。

たとえば、頻度が 0 7 * * * UTC または毎日午前 7 時（UTC）のバックアップ スケジュールを作成するとします。つまり、バックアップごとに、versionTime は UTC 午前 7 時に設定され、createTime は UTC 午前 7 時から午前 11 時までの 4 時間の期間内のタイムスタンプになります。

API を使用した createTime と versionTime の使用の詳細については、Backup API リファレンスをご覧ください。

主な機能

  • データの整合性: 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-owned and Google-managed encryption keys を使用した暗号化のみをサポートします。

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

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

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

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

  • バックアップ コピー: 増分バックアップをコピーすると、Spanner はコピーされたバックアップの復元に必要なチェーン内の古いバックアップもすべてコピーします。宛先インスタンスに、同じソースチェーンからコピーされた古いバックアップで終わるバックアップ チェーンがすでに含まれている場合、Spanner は既存のバックアップの冗長なコピーを作成しません。代わりに、Spanner は増分バックアップと、宛先チェーンに存在しない古いバックアップのみをコピーし、これらのバックアップを既存のチェーンに追加します。Spanner では、使用した合計ストレージに基づいて課金されます。

    たとえば、日次増分バックアップ スケジュールを設定して、毎日最新のバックアップをコピーすると、宛先インスタンスはソースチェーンをミラーリングするバックアップ チェーンを維持します。Spanner は、後続のコピー オペレーション中に、チェーン内で以前にコピーされたバックアップを複製しません。

    Spanner は冗長なコピーを回避することを目的としていますが、まれに、以前にコピーされたバックアップが移行先インスタンスにすでに存在する場合でも、チェーン内の古いバックアップをすべてコピーする必要がある場合があります。

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

デフォルトのバックアップ スケジュール

新しい Spanner インスタンスを作成するときに、インスタンス内の新しいデータベースごとに Spanner がデフォルトのバックアップ スケジュールを作成するように指定できます。デフォルトのバックアップ スケジュールでは、24 時間ごとにフル バックアップが作成されます。これらのバックアップの保持期間は 7 日間です。デフォルトのバックアップ スケジュールは、作成後に編集または削除できます。

新しいすべてのインスタンスでは、デフォルトのバックアップ スケジュールが自動的に有効になります。インスタンスのデフォルトのバックアップ スケジュールは、インスタンスの作成時、または後でインスタンスを編集するときに有効または無効にできます。

既存のインスタンスでデフォルトのバックアップ スケジュールを有効にできます。ただし、デフォルトのバックアップ スケジュールは、インスタンス内の既存のデータベースには適用されません。デフォルトのバックアップ スケジュールは、インスタンス内の新しいデータベースにのみ適用されます。

デフォルトのバックアップ スケジュールが有効になってバックアップの作成が開始されるまで、24 時間かかります。

インスタンスを削除する前に、インスタンス内のすべてのバックアップを削除する必要があります。テスト目的でインスタンスを作成して削除する場合は、24 時間以内に新しいインスタンスを削除して、バックアップを手動で削除しないようにできます。

デフォルトのバックアップ スケジュールを有効または無効にする手順については、デフォルトのバックアップ スケジュールのタイプを編集するをご覧ください。

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

各 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 データベースのバックアップをあるインスタンスから別のリージョンまたはプロジェクトの別のインスタンスにコピーして、データ保護とコンプライアンス機能を強化できます。

宛先またはソースの Google Cloud リージョンが停止している場合、バックアップをコピーすることはできません。リージョンが停止した場合にデータを保護するには、影響を受けるリージョン外の場所にバックアップを定期的にコピーする必要があります。

コピーされたバックアップには、元のバックアップと同じ主要機能が含まれます。また、コピーしたバックアップと同じインスタンスにコピーしたバックアップを復元して、クロスリージョンとクロスプロジェクトのバックアップと復元のユースケースをサポートできます。

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

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

projects/PROJECT_ID/instances/INSTANCE_ID/backups/BACKUP_NAME

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

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

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

暗号化

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

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

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

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

パフォーマンス

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

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

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

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

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

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

増分バックアップをコピーすると、コピーされたバックアップの復元に必要なチェーン内の古いバックアップもすべてコピーされます。パフォーマンスを向上させるため、Spanner はすべてのバックアップを順番にではなく同時にコピーします。また、Spanner は、可能であれば、同じチェーン内の古いバックアップのコピーを回避しようとします。詳細については、増分バックアップをご覧ください。

バックアップを削除する

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

料金

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

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

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

  • us-central1 リージョンの重複は無料
  • ウィットネス us-central2 リージョンは無料
  • 大陸間データ転送は 2 回適用: 新しい大陸（ヨーロッパとアジア）ごとに 1 回ずつ
  • 同じ大陸内のリージョン間のデータ転送料金は us-east1 に 1 回適用
  • 同じ大陸内のリージョン間のデータ転送料金はヨーロッパで 1 回適用

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

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

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

次のステップ