このドキュメントでは、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 インスタンスを作成するときに、インスタンス内の新しいデータベースごとにデフォルトのバックアップ スケジュールを作成するように 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 データベースのバックアップを、あるインスタンスから別のリージョンまたはプロジェクトの別のインスタンスにコピーして、データ保護機能とコンプライアンス機能を強化できます。コピーされたバックアップには、元のバックアップと同じ主要機能が含まれます。また、コピーしたバックアップと同じインスタンスにコピーしたバックアップを復元して、クロスリージョンとクロスプロジェクトのバックアップと復元のユースケースをサポートできます。
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 は、バックアップのチェーンを 1 つずつコピーするのではなく、すべてのバックアップを同時にコピーしてパフォーマンスを向上させます。
バックアップを削除する
増分バックアップを削除するときに、同じチェーンに新しい増分バックアップが存在する場合、ストレージが復元されないことがあります。新しい増分バックアップは、削除された増分バックアップとチェーン内の古いバックアップに存在するデータに依存します。Spanner はデータを保持し、新しい増分バックアップがすべて期限切れになった場合にのみストレージを解放します。freeableSizeBytes フィールドには、バックアップを削除した場合に回復できるストレージ容量が表示されます。
料金
料金は、単位時間あたりのバックアップで使用されるストレージの量に基づいて課金されます。バックアップ オペレーションが完了すると課金が開始され、バックアップが削除されるまで継続されます。作成が完了したバックアップには、最低でも 24 時間分の料金が発生します。バックアップを作成し、完了後すぐに削除した場合でも、24 時間分の料金が請求されます。
バックアップのコピーには、元のバックアップと同じストレージ費用が適用されます。異なるリージョンを占有する 2 つのインスタンス間でコピーを作成すると、アウトバウンド データ転送の費用が適用されます。
たとえば、ソースのマルチリージョン インスタンス構成 nam7 から宛先のマルチリージョン インスタンス構成 nam-eur-asia3 にデータベースをコピーする場合は、次の料金が適用されます。
us-central1リージョンの重複は無料- ウィットネス
us-central2リージョンは無料 - 大陸間データ転送は、新しい大陸（ヨーロッパとアジア）ごとに 1 回ずつ、2 回適用されます。
- 同じ大陸内のリージョン間のデータ転送料金は
us-east1に 1 回適用されます - 同じ大陸内のリージョン間のデータ転送料金はヨーロッパで 1 回適用されます
Spanner は、コピー プロセスを最適化して、クロスリージョン転送の数を最小限に抑えます。これにより、データ転送のコストを最小限に抑えながら、高速なコピー バックアップを実現できます。
バックアップは保存され、料金は別途請求されます。バックアップ ストレージは、データベース ストレージの料金やデータベースのストレージ制限には影響しません。詳細については、ストレージ使用率の指標をご覧ください。
バックアップ コストの詳細については、Spanner の料金をご覧ください。
次のステップ
バックアップを作成するには、バックアップを作成するをご覧ください。
バックアップを管理するには、バックアップを管理するをご覧ください。