Bigtable のバックアップの概要

このページでは、Bigtable のバックアップの概要について説明します。このページの内容は、Bigtable の管理者とデベロッパーを対象としています。

Bigtable バックアップを使用すると、テーブルのスキーマとデータのコピーを保存しておいて、後でバックアップから新しいテーブルに復元できます。バックアップは手動で作成することも、自動バックアップを有効にして、Bigtable で日次バックアップを作成することもできます。バックアップのコピーを作成することもできます。

このページを読む前に、Bigtable の概要とテーブルの管理について理解しておく必要があります。

機能

  • 完全統合: バックアップは、Bigtable サービスですべて処理されます。インポートやエクスポートは必要ありません。
  • 増分: バックアップは、ソーステーブルおよびテーブルの他のバックアップと物理ストレージを共有します。
  • 費用対効果の改善: Bigtable のバックアップを使用すると、他のサービスを使用したデータのエクスポート、保存、インポートに関連するコストを削減できます。
  • 自動有効期限: 各バックアップには、バックアップ作成後 90 日までの、ユーザー定義の有効期限があります。バックアップのコピーは最大 30 日間保存できます。
  • 柔軟な復元オプション: バックアップを作成した場所ではなく、別のインスタンスのテーブルにバックアップを復元できます。
  • 自動バックアップ: 自動バックアップを有効にして、Bigtable で日次バックアップを作成できます。

ユースケース

バックアップは、次のユースケースに役立ちます。

  • ビジネスの継続性
  • 規制コンプライアンス
  • テストと開発
  • 障害復旧

次の障害復旧シナリオを検討してください。

目標 バックアップ戦略 回復戦略
人的ミスからの保護: 誤って削除または破損した場合に備えて、常にデータの最新のバックアップを用意してください。 毎日実行するなど、ビジネスニーズに適したバックアップ作成スケジュールを決定します。必要に応じて、バックアップの定期的なコピーを作成し、別のプロジェクトまたはリージョンに保存して、分離と保護を強化します。保護を強化するには、アクセス権が制限されたプロジェクトまたはインスタンスにバックアップ コピーを保存します。 バックアップまたはコピーから新しいテーブルに復元してから、新しいテーブルにリクエストを再ルーティングします。
ゾーンが利用できない場合: 万が一 Google Cloud ゾーンが使用不能になった場合でも、データの可用性を確保する必要があります。 バックアップは定期的に作成します（毎日など）。最新のバックアップのコピーを定期的に作成し、複数のゾーン（必要に応じて別のインスタンスやプロジェクト）の 1 つ以上のクラスタに保存します。 サービス クラスタのゾーンが使用不能になった場合は、リモート バックアップ コピーから新しいテーブルに復元して、新しいテーブルにリクエストを再ルーティングします。
データの破損: ソーステーブルの一部が破損した場合などは、バックアップを使用してテーブルのデータの一部を復元します。 データのバックアップを定期的に作成します。 バックアップから新しいインスタンスの新しいテーブルに復元します。次に、Bigtable クライアント ライブラリまたは Datafalow を使用して、新しいテーブルからデータを読み取り、ソーステーブルに書き込むアプリケーションを作成します。データが元のテーブルにコピーされたら、新しいテーブルを削除します。

Bigtable のバックアップの操作

Bigtable のバックアップでは、次の操作を行うことができます。いずれの場合も、宛先のプロジェクト、インスタンス、クラスタがすでに存在している必要があります。バックアップ オペレーションの一部として、これらのリソースを作成することはできません。バックアップ コピーのコピーは作成できません。

アクション 宛先オプション
バックアップを作成する
  • ソーステーブルと同じインスタンスにあるクラスタ
バックアップから新しいテーブルに復元する
  • 任意のインスタンス
  • すべての Bigtable リージョン
  • すべてのプロジェクト
バックアップをコピーする
  • 任意のインスタンス
  • すべての Bigtable リージョン
  • すべてのプロジェクト

これらの操作と、バックアップの更新や削除などの操作については、バックアップを管理するで具体的な手順をご覧ください。

Bigtable のバックアップを操作するには、次のものを使用します。

Cloud Bigtable Admin API に直接アクセスすることもできますが、これは API に対してバックアップ呼び出しを行う Cloud Bigtable クライアント ライブラリを使用できない場合にのみ使用することを強くおすすめします。

Bigtable のバックアップの仕組み

バックアップを作成するには、Bigtable でのバックアップの保存と保持について理解しておく必要があります。

バックアップ ストレージ

テーブル バックアップは手動で作成できます。また、自動バックアップを有効にして、Bigtable で日次バックアップを取ることもできます。テーブル バックアップは、インスタンスのクラスタに保存されます。手動バックアップの場合、テーブル バックアップは、選択したインスタンスの 1 つのクラスタに保存されます。自動バックアップを有効にすると、テーブル バックアップがインスタンスの各クラスタに保存されます。

テーブルのバックアップには、バックアップが作成されたクラスタで、バックアップが作成された時点でそのテーブル内に存在していたすべてのデータが含まれます。バックアップは、バックアップが作成された時点におけるソーステーブルのサイズを超えることはありません。

Bigtable のバックアップは増分です。バックアップによって消費されるストレージの量は、テーブルのサイズや、変更されていないデータのストレージを元のテーブルまたは同じテーブルの他のバックアップと共有できる範囲に依存します。そのため、バックアップのサイズは、前回のバックアップから変更されたデータの量に依存します。

1 つのクラスタでテーブル 1 つあたり最大 150 個のバックアップを作成できます。

バックアップがあるテーブルは削除できます。バックアップを保護するため、バックアップを含むクラスタは削除できません。また、いずれかのクラスタ内に 1 つ以上のバックアップがあるインスタンスは削除できません。

新しいテーブルにバックアップを復元した後も、バックアップは残ります。不要になった場合は削除するか、期限切れにすることができます。バックアップ ストレージは、プロジェクトのノード ストレージの上限にはカウントされません。

バックアップのデータは暗号化されます。

保持期間

バックアップの保持期間は最大 90 日まで指定できます。バックアップのコピーを作成した場合、コピーの最大保持期間はコピーの作成から 30 日間です。

自動バックアップが有効になっているテーブルの場合、デフォルトの保持期間は 3 日間です。バックアップの保持期間は、バックアップの作成時から最大 90 日間まで変更できます。

復元後のストレージ

バックアップから復元された新しいテーブルのストレージ料金は、他のテーブルの場合と同じです。

バックアップから復元されたテーブルは、元のテーブルと同じ量のストレージを消費しない可能性があります。また、復元後にサイズが小さくなることもあります。サイズの違いは、ソースクラスタと宛先クラスタで最近コンパクションが発生したかどうかによります。

コンパクションはローリング レベルで行われるため、テーブルの作成後すぐにコンパクションが発生する可能性があります。ただし、コンパクションは最長で 1 週間かかることがあります。

バックアップから復元された新しいテーブルは、ソーステーブルのガベージ コレクション ポリシーを継承しません。テーブルへの新しいデータの書き込みを開始する前に、新しいテーブルでガベージ コレクション ポリシーを構成します。詳細については、ガベージ コレクションの構成をご覧ください。

費用

バックアップを使用する場合は、標準のネットワーク費用が適用されます。バックアップの作成、コピー、復元など、バックアップ オペレーションは課金されません。

ストレージの費用

バックアップまたはバックアップのコピーを保存すると、バックアップまたはバックアップ コピーを含むクラスタが存在するリージョンの標準バックアップ ストレージ料金が適用されます。

バックアップはテーブルの完全論理コピーです。Bigtable はバックグラウンドでバックアップ ストレージの使用を最適化します。この最適化により、バックアップは増分になります。可能な限り、元のテーブルまたはテーブルの他のバックアップと物理ストレージを共有します。Bigtable の組み込みのストレージ最適化機能により、バックアップまたはバックアップのコピーを保存するための費用が、テーブル バックアップの完全な物理コピーよりも低くなる場合があります。

自動バックアップが有効になっているレプリケートされたインスタンスでは、各クラスタでバックアップが毎日作成されるため、ストレージ費用が上がる可能性があります。

バックアップのコピー時の費用

ソース バックアップと異なるリージョンにバックアップのコピーを作成すると、宛先クラスタへのデータのコピーに関する標準のネットワーク料金が発生します。ソース バックアップと同じリージョンにコピーを作成した場合、ネットワーク トラフィックに対する課金は発生しません。

復元時の費用

バックアップから新しいテーブルを復元すると、レプリケーションのネットワーク費用が発生します。新しいテーブルがレプリケーションを使用するインスタンスにある場合、インスタンス内のすべてのクラスタにコピーされるデータに対して 1 回限りのレプリケーション費用が発生します。

バックアップの作成元とは別のインスタンスに復元するときに、バックアップのインスタンスと宛先インスタンスに同じリージョンのクラスタがない場合は、宛先クラスタへの最初のデータのコピーに対して、標準のネットワーク料金で 1 回限りの料金が発生します。

CMEK

顧客管理の暗号鍵（CMEK）で保護されたクラスタでバックアップを作成すると、バックアップはその時点におけるクラスタの CMEK 鍵のメイン バージョンに固定されます。バックアップを作成すると、KMS 鍵がローテーションされても、その鍵と鍵バージョンの変更はできません。

バックアップから復元する場合、バックアップの復号プロセスを正常に行うため、バックアップが固定されている鍵バージョンを有効にする必要があります。新しいテーブルは、宛先インスタンスにある各クラスタ用 CMEK 鍵の最新のプライマリ バージョンで保護されます。CMEK で保護されたバックアップから別のインスタンスに復元する場合、復元先インスタンスも CMEK で保護されている必要がありますが、ソース インスタンスと同じ CMEK 構成は必要ありません。

レプリケーションに関する考慮事項

このセクションでは、レプリケーションを使用するインスタンスのテーブルのバックアップと復元を行う際に理解しておくべきその他のコンセプトについて説明します。

レプリケーションとバックアップ

レプリケートされたインスタンスで手動でテーブルのバックアップを取る際、バックアップを作成して保存するクラスタを選択します。自動バックアップが有効になっているテーブルでは、インスタンスの各クラスタで日次バックアップが取られます。

バックアップを含むクラスタへの書き込みを停止する必要はありませんが、クラスタに対するレプリケートされた書き込みの処理方法を理解しておく必要があります。

バックアップは、バックアップが作成された時点の、バックアップが保存されているクラスタ上の状態にあるテーブルのコピーです。インスタンスの別のクラスタからまだレプリケートされていないテーブルデータは、バックアップに含まれません。

各バックアップには、開始時刻と終了時刻があります。バックアップ オペレーションの直前または最中にクラスタに送信された書き込みは、バックアップに含まれないことがあります。この不確実性には、次の 2 つの要因が関係しています。

  • すでにバックアップでコピーしたテーブルのセクションに、書き込みが送信されることがあります。
  • 別のクラスタへの書き込みが、バックアップを含むクラスタにレプリケートされていないことがあります。

つまり、バックアップより前のタイムスタンプがある書き込みは、バックアップに含まれない場合があります。これは、自動バックアップが有効な場合に作成されるバックアップにも正です。バックアップ時間はクラスタごとに異なるため、インスタンスのバックアップは互いに正確なコピーではありません。

この不整合性がビジネス要件で受け入れられない場合は、書き込みリクエストで整合性トークンを使用して、レプリケートされた書き込みのすべてをバックアップに含めるようにします。

レプリケーションと復元

バックアップを新しいテーブルに復元すると、宛先クラスタで復元オペレーションが完了した直後に、インスタンスの他のクラスタとの間でレプリケーションが開始します。

パフォーマンス

バックアップを作成する際は、次のベスト プラクティスを使用して、パフォーマンスが最適に保たれるようにしてください。

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

バックアップの作成には通常 1 分もかかりませんが、最大で 1 時間かかることもあります。通常の状況では、バックアップの作成はサービス提供のパフォーマンスに影響しません。

最適なパフォーマンスを得るには、1 つのテーブルについてバックアップを 5 分に 1 回を超えて作成しないでください。バックアップを頻繁に作成すると、サービス提供のレイテンシが顕著に増加する可能性があります。

復元時のパフォーマンス

単一クラスタ インスタンスのテーブルにバックアップを復元するには数分かかります。レプリケートされたインスタンスでは、データをすべてのクラスタにコピーする必要があるため、復元にさらに時間がかかります。Bigtable は常に、最も効率的なルートを選択してデータをコピーします。

バックアップの作成元と異なるインスタンスに復元する場合、同じインスタンスに復元する場合よりも復元に時間がかかります。特に、バックアップ作成元のクラスタと同じゾーン内に宛先インスタンスのクラスタがない場合は、復元プロセスの時間が長くなります。

大きなテーブルは、小さなテーブルよりも復元に時間がかかります。

SSD インスタンスの場合、復元が完了した後もテーブルが最適化されるまでは読み取りレイテンシが増加することがあります。復元オペレーション中は、いつでもステータスを確認して最適化が進行中かどうかを確かめられます。

バックアップ作成元と異なるインスタンスに復元する場合は、宛先インスタンスで HDD または SSD ストレージを使用できます。元のインスタンスと同じストレージ タイプにする必要はありません。

アクセス制御

IAM 権限により、バックアップと復元のオペレーションへのアクセスが制御されます。バックアップ権限はインスタンス レベルであり、インスタンスのすべてのバックアップに適用されます。

テーブルのバックアップの作成に使用するアカウントには、テーブルを読み取り、テーブルのあるインスタンス（ソース インスタンス）にバックアップを作成する権限が必要です。

バックアップのコピーに使用するアカウントには、ソース バックアップの読み取り権限と、宛先のインスタンスとプロジェクトのバックアップを作成する権限が必要です。

バックアップから新しいテーブルを復元するアカウントには、復元先のインスタンスにテーブルを作成する権限が必要です。

操作 必要な IAM 権限
バックアップを作成する bigtable.tables.readRows、bigtable.backups.create
バックアップを取得する bigtable.backups.get
バックアップを一覧表示する bigtable.backups.list
バックアップを削除する bigtable.backups.delete
バックアップを更新する bigtable.backups.update
バックアップをコピーする bigtable.backups.read、bigtable.backups.create
バックアップから新しいテーブルに復元する bigtable.tables.create、bigtable.backups.restore
オペレーションを取得する bigtable.instances.get
オペレーションを一覧表示する bigtable.instances.get

おすすめの方法

バックアップ戦略を作成する前に、次のベスト プラクティスを理解しておく必要があります。

バックアップの作成

  • 5 分に 1 回を超えてテーブルをバックアップしないでください。
  • レプリケーションを使用するテーブルをバックアップする場合は、次の要素を考慮してバックアップを保存するクラスタを選択します。
    • 費用。インスタンス内の、あるクラスタは、他のクラスタよりも低コストのリージョンにある可能性があります。
    • アプリケーション サーバーへの近接。バックアップは、できるだけ提供アプリケーションに近い場所に保管することをおすすめします。
    • ストレージの利用率バックアップが累積していくと、バックアップを維持するために十分な保存容量が必要になります。ワークロードに応じて、サイズやディスク使用量の異なるクラスタを作成できます。これはクラスタの選択に影響することがあります。
  • レプリケーションを使用するインスタンスのテーブルをバックアップするときに、レプリケートされたすべての書き込みをバックアップに確実に含める必要がある場合は、書き込みリクエストで整合性トークンを使用します。

バックアップからの復元

  • バックアップから復元する必要がある場合は、事前に新しいテーブルの名前を計画します。重要な点は、問題に対処するときに決めずに済むように前もって準備しておくということです。
  • 誤削除以外の理由でテーブルを復元する場合は、すべての読み取りと書き込みが新しいテーブルに送信されていることを確認した後、元のテーブルを削除してください。
  • 別のインスタンスに復元する場合は、バックアップの復元オペレーションを開始する前に、宛先のインスタンスを作成してください。

割り当てと上限

バックアップと復元のリクエストと、バックアップ ストレージは、Bigtable の割り当てと上限の対象となります。

制限事項

Bigtable のバックアップには、次の制限が適用されます。

全般

  • バックアップから直接読み取ることはできません。
  • バックアップは、特定の時点における単一クラスタ内のテーブルのバージョンです。バックアップは一貫した状態を表すものではありません。異なるクラスタの同じテーブルをバックアップする場合も同様です。
  • 1 回のオペレーションで複数のテーブルをバックアップすることはできません。
  • Bigtable のバックアップを、Cloud Storage などの別のサービスにエクスポート、コピー、移動することはできません。
  • Bigtable のバックアップには Bigtable のデータのみが含まれ、他の Google サービスのバックアップとの統合、または関連はありません。

復元

  • バックアップから既存のテーブルに復元することはできません。
  • 既存のインスタンスにのみ復元できます。バックアップから復元するときに、Bigtable は新しいインスタンスを作成しません。復元リクエストで指定された宛先インスタンスが存在しない場合、復元オペレーションは失敗します。
  • SSD クラスタ内のテーブルにバックアップを復元してから、新しく復元されたテーブルを削除すると、Bigtable はテーブルの最適化が終わるまで待機するため、削除に時間がかかります。

コピー

  • 有効期限まで 24 時間以内のバックアップのコピーは作成できません。
  • バックアップのコピーは作成できません。

CMEK

  • CMEK で保護されているバックアップは、CMEK で保護されているインスタンスの新しいテーブルに復元する必要があります。
  • CMEK で保護されているバックアップのコピーを作成する場合は、宛先クラスタも CMEK で保護されている必要があります。

次のステップ