Bigtable のバックアップの概要

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

バックアップを使用すると、テーブルのスキーマとデータのコピーを保存しておき、後でバックアップから新しいテーブルに復元できます。Bigtable には、障害復旧（DR）の要件、Bigtable クラスタで使用するストレージのタイプ（HDD または SSD）に応じて、次のタイプのバックアップが用意されています。

  • 標準バックアップは長期保持用に最適化されています。標準バックアップから SSD クラスタに復元する場合、テーブルを本番環境レベルのパフォーマンスにするには、復元操作において Bigtable による追加の最適化が必要です。詳細については、復元時のパフォーマンスをご覧ください。
  • ホット バックアップでは、本番環境レベルのパフォーマンスと低レイテンシで最も効率的に復元する手段が得られます。詳細については、ホット バックアップをご覧ください。

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

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

このページを読む前に、Bigtable の概要とテーブルの管理を確認してください。

機能

Bigtable バックアップには、次の機能と利点があります。

  • 完全統合: Bigtable は、データのインポートやエクスポートを必要とせずにバックアップを処理します。
  • 増分: バックアップは、ソーステーブルおよびテーブルの他のバックアップと物理ストレージを共有します。
  • 費用対効果の改善: Bigtable のバックアップを使用すると、他のサービスを使用したデータのエクスポート、保存、インポートに関連するコストを削減できます。
  • 自動有効期限: 各バックアップには、ユーザー定義の保持期間があります。詳細については、このドキュメントの保持セクションをご覧ください。
  • 柔軟な復元オプション: バックアップを作成した場所ではなく、別のインスタンスのテーブルにバックアップを復元できます。
  • 自動バックアップ: 自動バックアップを有効にして、Bigtable で日次バックアップを作成できます。
  • ホット バックアップ: プロダクション レディなホット バックアップにより、障害復旧を計画できます。

ユースケース

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

  • ビジネスの継続性
  • 規制遵守
  • テストと開発
  • 障害復旧

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

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

ホット バックアップ

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

ホット バックアップは、必要なときにオンデマンドで作成することも、自動バックアップ ポリシーを構成して日次ホット バックアップを作成することもできます。

  • オンデマンド ホット バックアップ: ホットから標準への移行時間の設定は任意です。移行時間を設定しない場合、バックアップは有効期限が切れるまでホットのままになります。バックアップを標準バックアップに自動的に移行するには、バックアップ作成開始時刻から 24 時間以上経過した移行時間を設定します。この時間は後で設定または変更することもできます。詳細については、ホット バックアップを作成するとバックアップまたはバックアップ コピーを変更するをご覧ください。
  • ホット自動バックアップ: ホット保持期間の設定が必要です。SSD インスタンスでホット自動バックアップを有効にするには、ポリシーの保持期間を超えない 24 時間から 10 日までの期間を指定する必要があります。この設定により、各日次バックアップがホット状態を維持する期間が決まります。この期間が経過すると、保持期間の残りの期間は標準バックアップに自動的に移行します。詳細については、ホット自動バックアップを構成するをご覧ください。

最新のバックアップをホットに保つ

迅速な障害復旧とストレージ費用のバランスを取るため、最新のバックアップのみをホット バックアップとして保持し、古いバックアップは標準バックアップとして保存できます。

  • 日次自動バックアップ: Google Cloud コンソールで、ホット保持期間を 24 時間（1 日）に設定して自動バックアップ ポリシーを構成します。Bigtable は 24 時間ごとに自動バックアップを作成するため、各日次バックアップは次の日次バックアップが作成されるまでホット状態のままになり、その後、保持期間の残りの期間は標準バックアップに自動的に移行します。手順については、ホット自動バックアップを構成するをご覧ください。
  • オンデマンド バックアップ: 繰り返しスケジュールでホット バックアップを作成する場合は、各バックアップのホットから標準への移行時間を、次のホット バックアップがスケジュールされている時間（バックアップ作成開始時間の 24 時間以上後）に設定します。この時間に達すると、古いバックアップは自動的に標準バックアップに移行し、最新のバックアップはホットのままになります。手順については、ホット バックアップを作成するをご覧ください。

ホット バックアップの制限事項

ホット バックアップには次の制限があります。

  • ホット バックアップを標準バックアップに変換することはできますが、標準バックアップをホット バックアップに変換することはできません。
  • オンデマンド ホット バックアップを作成し、ホット自動バックアップを構成できるのは、SSD インスタンスのテーブルのみです。HDD インスタンスにホット バックアップを作成することはできません。
  • Bigtable では、階層型ストレージが有効になっているテーブルのホット バックアップはサポートされていません。詳細については、階層型ストレージの概要をご覧ください。
  • ホット バックアップのコピーは常に標準バックアップです。バックアップ コピーは、元のホット バックアップと同じように、本番環境レベルのパフォーマンスと低レイテンシで迅速に復元することはできません。

Bigtable のバックアップの操作

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

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

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

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

バックアップ ストレージ

手動またはプログラムで作成したテーブル バックアップは、指定した単一のクラスタに保存されます。自動バックアップが有効になっている場合、Bigtable はインスタンス内の各クラスタにバックアップを保存します。Enterprise Plus エディションでは、自動バックアップが有効になっているクラスタのロケーションを選択できます。

バックアップの作成時にクラスタが CPU またはストレージの使用率の推奨上限を超えると、バックアップの作成が遅れることがあります。詳細については、CPU とディスクの使用状況を理解するをご覧ください。

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

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

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

バックアップがあるテーブルは削除できます。バックアップを保護するため、次のものは削除できません。

  • 1 つ以上のバックアップを含むクラスタ。クラスタを削除するには、これらのバックアップを削除するか、有効期限が切れるまで待つ必要があります。
  • テーブルの自動バックアップ ポリシーでロケーションとして構成されているクラスタ。クラスタを削除するには、まず自動バックアップ ポリシーを更新してクラスタのロケーションを削除するか、テーブルの自動バックアップを無効にする必要があります。
  • いずれかのクラスタ内に 1 つ以上のバックアップがあるインスタンス。

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

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

保持

Bigtable のバックアップを使用すると、指定した期間データを保持できます。保持期間は、個々のバックアップに対して構成することも、自動バックアップ ポリシーの一部として構成することもできます。

  • 保持期間は、バックアップが作成された時点から開始されます。
  • 自動バックアップが有効になっているテーブルのデフォルトの保持期間は 7 日間です。
  • Enterprise エディションと Enterprise Plus エディションの両方で、自動バックアップ ポリシーのカスタム保持期間を最大 90 日に構成できます。個々のオンデマンド バックアップの場合、または既存のバックアップの保持期間を更新する場合は、Enterprise エディションでは最大 90 日、Enterprise Plus エディションでは最大 365 日を指定できます。
  • バックアップのコピーを作成した場合、コピーの最大保持期間はコピーの作成から 30 日間です。
  • バックアップを作成するときに、保持期間ではなく有効期限を指定できます。有効期限は絶対日時ですが、保持期間は期間を指定します。どちらの方法でも、同じルールと制限に従って有効期限が設定されます。
  • ホット バックアップを標準バックアップに移行しても、保持期間や有効期限は変更されません。オンデマンド ホット バックアップの場合、ホットから標準への移行時間を設定することは任意ですが、ホット自動バックアップではホット保持期間が必要です。

バックアップまたは自動バックアップ ポリシーの保持期間を変更できます。詳細については、バックアップまたはバックアップ コピーを変更すると自動バックアップ ポリシーを更新するをご覧ください。

復元後のストレージ

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

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

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

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

費用

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

ストレージの費用

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

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

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

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

自動バックアップが有効になっているレプリケートされたインスタンスでは、クラスタごとに日次バックアップが作成されるため、ストレージ費用が高くなる可能性があります。Enterprise Plus エディションでは、特定のロケーションのクラスタに対してのみ自動バックアップを有効にすることで、これらの費用を削減できます。

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

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

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

ホット バックアップが標準バックアップに移行すると（ホット自動バックアップのホット保持期間が終了した場合など）、バックアップがホットな間はホット バックアップ ストレージ料金が課金され、移行後は標準バックアップ ストレージ料金が課金されます。移行自体に追加料金はかかりません。テーブルに構成されているホット保持期間を確認するには、自動バックアップ ポリシーを表示するをご覧ください。バックアップ ストレージの料金の詳細については、料金をご覧ください。

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

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

復元時の費用

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

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

CMEK

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

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

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

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

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

レプリケートされたインスタンスで手動でテーブルのバックアップを取る際、バックアップを作成して保存するクラスタを選択します。自動バックアップが有効になっているテーブルでは、インスタンスの各クラスタで日次バックアップが作成されます。Enterprise Plus エディションでは、自動バックアップを特定のロケーションのクラスタのみに制限できます。

バックアップを含むクラスタへの書き込みを停止する必要はありませんが、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

ベスト プラクティス

バックアップ戦略を作成する前に、次のベスト プラクティスを検討してください。災害復旧計画の詳細については、クラウド インフラストラクチャの停止に対する障害復旧の設計の Bigtable のセクションをご覧ください。

バックアップの作成

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

バックアップからの復元

  • バックアップから復元する必要がある場合は、事前に新しいテーブルの名前を計画します。重要なのは、問題に対処するときに決定する必要がないように、事前に準備しておくことです。
  • 誤って削除した以外の理由でテーブルを復元する場合は、元のテーブルを削除する前に、すべての読み取りと書き込みが新しいテーブルに送信されていることを確認してください。
  • 別のインスタンスに復元する場合は、バックアップの復元オペレーションを開始する前に宛先インスタンスを作成します。
  • テーブルの復元が遅くならないようにするには、同じゾーン内の同じソーステーブルに対して別の復元を開始する前に、復元オペレーションが完了するまで待ちます。
  • 標準バックアップから復元する前に、作成後 1 時間以上待ってください。より迅速に復元する必要がある場合は、代わりにホット バックアップを使用します。

割り当てと上限

バックアップと復元のリクエストとバックアップ ストレージには、Bigtable の割り当てと上限が適用されます。

制限事項

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

全般

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

復元

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

コピー

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

CMEK

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

次のステップ