Bigtable のバックアップの概要

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

バックアップを使用すると、テーブルのスキーマとデータのコピーを保存しておき、後でバックアップから新しいテーブルに復元できます。Bigtable には 2 種類のバックアップがあります。作成するバックアップの種類は、障害復旧（DR）要件と、Bigtable クラスタで使用するストレージの種類（HDD または SSD）によって異なります。

標準バックアップは、長期保持用に最適化されています。標準バックアップから SSD クラスタに復元する場合、復元オペレーションで Bigtable による追加の最適化が必要になり、テーブルを本番環境レベルのパフォーマンスに引き上げることができます。詳細については、復元時のパフォーマンスをご覧ください。
ホットバックアップは、本番環境レベルのパフォーマンスと低レイテンシのサービングへの最も効率的な復元を提供します。詳細については、ホットバックアップをご覧ください。

次の方法でバックアップを作成できます。

自動バックアップを有効にして、Bigtable で日次バックアップを作成できるようにします。
Google Cloud コンソール、gcloud CLI、または Bigtable クライアントライブラリを使用して、オンデマンドでバックアップを作成します。
バックアップのコピーを作成する

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

機能

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

ユースケース

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

ビジネスの継続性
法令遵守
テストと開発
障害復旧

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

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

ホットバックアップ

ホットバックアップは、迅速な復元のために最適化された本番環境対応のバックアップです。復元直後に新しいテーブルから読み取る際のレイテンシが低くなります。ホットバックアップから本番環境のパフォーマンスに復元する方が、標準バックアップから復元するよりも高速です。

ホットバックアップを標準バックアップに変換することはできますが、標準バックアップをホットバックアップに変換することはできません。

自動バックアップを使用してホットバックアップを作成することはできません。また、HDD クラスタにホットバックアップを作成することもできません。

Bigtable のバックアップの操作

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

操作	宛先オプション
バックアップのコピーは作成できません。バックアップのコピーは、ソースがホットバックアップであっても、常に標準バックアップです。
標準バックアップを作成する	ソーステーブルと同じインスタンスにあるクラスタ
ホットバックアップを作成する	ソーステーブルと同じインスタンスにあるクラスタです。インスタンスで SSD ストレージを使用する必要があります。
標準バックアップまたはホットバックアップから新しいテーブルに復元する	任意のインスタンスすべての Bigtable リージョンすべてのプロジェクト
バックアップをコピーする^{1, 2}	任意のインスタンスすべての Bigtable リージョンすべてのプロジェクト

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

バックアップストレージ

オンデマンドで作成するテーブルバックアップは、指定した単一のクラスタに保存されます。自動バックアップが有効になっている場合、バックアップが作成され、インスタンス内のすべてのクラスタに保存されます。

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

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

一方、ホットバックアップは完全なコピーであり、ソーステーブルがどれだけ変更されても、バックアップ時のストレージ量は同じです。ストレージが最適化されているため、このバックアップはホットと見なされます。これにより、本番環境のパフォーマンスレベルに効率的に復元できます。

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

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

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

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

リテンション

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

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

復元後のストレージ

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

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

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

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

費用

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

ストレージの費用

ストレージ費用は、標準バックアップとホットバックアップで異なります。

標準バックアップストレージの費用

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

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

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

ホットバックアップストレージの費用

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

ホットバックアップは、迅速な復元用に最適化された準備状態に保存されるため、標準バックアップの場合のように増分部分ではなく、テーブルの論理コピー全体のストレージに対して課金されます。

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

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

復元時の費用

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

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

CMEK

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

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

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

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

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

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

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

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

各バックアップには、開始時刻と終了時刻があります。バックアップオペレーションの直前または最中にクラスタに送信された書き込みは、バックアップに含まれないことがあります。この不確実性には、次の 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 で保護されている必要があります。