タイムトラベルとフェイルセーフによるデータの保持

このドキュメントでは、データセットのタイムトラベルとフェイルセーフのデータ保持ウィンドウについて説明します。タイムトラベル期間とフェイルセーフ期間中は、データセット内のテーブルで変更または削除されたデータは、復元が必要になった場合に備えて引き続き保存されます。

タイムトラベル

デフォルトでは、過去 7 日間のタイムトラベル期間内であれば、どの時点のデータにもアクセスできます。タイムトラベルを使用すると、更新されたデータや削除されたデータのクエリを実行すること、削除されたテーブルやデータセットの復元や、期限切れのテーブルの復元を行うことができます。

タイムトラベル期間を構成する

タイムトラベル期間の長さは、2～7 日の範囲で設定できます。デフォルトは 7 日間です。タイムトラベル期間をデータセット レベルで設定すると、データセット内のすべてのテーブルに適用されます。プロジェクト レベルのデフォルトを構成することもできます。

タイムトラベル期間は、更新または削除されたデータの復元のために長い時間を確保することが重要な場合は長めに構成し、その必要がない場合は短く構成できます。タイムトラベル期間を短くすると、物理ストレージの課金モデルを使用する場合にストレージ費用を節約できます。ただし、論理ストレージの料金モデルを使用する場合は、この費用削減は適用されません。

ストレージの課金モデルが費用に与える影響については、課金をご覧ください。

タイムトラベル期間がテーブルとデータセットの復元に与える影響

削除されたテーブルまたはデータセットは、削除時に有効であったタイムトラベル期間に関連付けられます。

たとえば、タイムトラベル期間を 2 日間から 7 日間に延長した場合、変更前に削除されたテーブルは 2 日間しか復元できません。同様に、タイムトラベル期間が 5 日間で、その時間を 3 日に短縮した場合、変更前に削除されたテーブルは 5 日間復元できます。

タイムトラベル期間はデータセット レベルで設定されるため、削除されたデータセットのタイムトラベル期間は、削除を解除するまで変更できません。

タイムトラベル期間を短縮し、テーブルを削除した後、そのデータに対してより長い復元可能期間が必要であることに気付いた場合、テーブルを削除する前の時点から、そのテーブルのスナップショットを作成できます。 この操作は、削除されたテーブルが復元可能な間に行う必要があります。詳細については、タイムトラベルを使用してテーブル スナップショットを作成するをご覧ください。

タイムトラベル期間を指定する

Google Cloud コンソール、bq コマンドライン ツール、または BigQuery API を使用して、データセットのタイムトラベル期間を指定できます。

新しいデータセットにタイムトラベル期間を指定する方法については、データセットの作成をご覧ください。

既存データセットのタイムトラベル期間を更新する方法については、タイムトラベル期間の更新をご覧ください。

タイムスタンプが、タイムトラベル期間外またはテーブルの作成時刻より前の場合、クエリは失敗し、次のようなエラーが返されます。

Table ID was created at time which is
before its allowed time travel interval timestamp. Creation
time: timestamp

タイムトラベルと行レベルのアクセス

テーブルに行レベルのアクセス ポリシーがあるか、すでに設定されている場合は、テーブル管理者のみがテーブルの過去のデータにアクセスできます。

次の Identity and Access Management（IAM）権限が必要です。

権限 リソース
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions アクセスする過去のデータのテーブル

次の BigQuery ロールは、必要な権限を提供します。

役割 リソース
roles/bigquery.admin アクセスする過去のデータのテーブル

bigquery.rowAccessPolicies.overrideTimeTravelRestrictions 権限を、カスタムロールには追加できません。

  • 次のコマンドを実行して、同等の Unix エポック時刻を取得します。

    date -d '2023-08-04 16:00:34.456789Z' +%s000

  • bq コマンドライン ツールで、上記のコマンドで取得した UNIX エポック時刻 1691164834000 を置き換えます。次のコマンドを実行して、削除されたテーブル deletedTableID のコピーを同じデータセット myDatasetID 内の別のテーブル restoredTable に復元します。

    bq cp myProjectID:myDatasetID.deletedTableID@1691164834000 myProjectID:myDatasetID.restoredTable

フェイルセーフ

BigQuery にはフェイルセーフ期間が用意されています。フェイルセーフ期間中は、削除されたデータがタイムトラベル期間が経過した後、さらに 7 日間自動的に保持されるため、そのデータを緊急復旧に利用できます。データはテーブルレベルで復元できます。データは、テーブルが削除された時点のタイムスタンプで表される時点からテーブルに対して復元されます。フェイルセーフ期間は構成できません。

フェイルセーフ ストレージ内のデータに対するクエリ実行や直接復元はできません。フェイルセーフ ストレージからデータを復元するには、Cloud カスタマーケアにご連絡ください。

課金

物理バイトを使用するようにストレージ課金モデルを設定すると、タイムトラベル ストレージとフェイルセーフ ストレージに使用されるバイト数は別途課金されます。タイムトラベル ストレージとフェイルセーフ ストレージでは、アクティブな物理ストレージに対する費用が発生します。ストレージ費用とデータ保持のニーズのバランスを取るようにタイムトラベル期間を構成できます。

論理バイト数を使用するようにストレージ課金モデルを設定すると、タイムトラベル ストレージとフェイルセーフ ストレージの合計ストレージ費用は、課金される基本料金に含まれます。

次の表に、物理ストレージと論理ストレージの費用の比較を示します。

課金モデル 発生する費用
物理（圧縮）ストレージ
  • アクティブなバイトに対する費用
  • 長期保存に対する費用
  • タイムトラベル ストレージに対する費用
  • フェイルセーフ ストレージに対する費用
論理（非圧縮）ストレージ（デフォルトの設定）
  • アクティブ ストレージに対する費用
  • 長期保存に対する費用
  • タイムトラベル ストレージの費用は発生しません
  • フェイルセーフ ストレージの費用は発生しません

物理ストレージを使用している場合は、タイムトラベルとフェイルセーフで使用されるバイト数を TABLE_STORAGE ビューと TABLE_STORAGE_BY_ORGANIZATION ビューの TIME_TRAVEL_PHYSICAL_BYTES 列と FAIL_SAFE_PHYSICAL_BYTES 列で確認できます。これらのビューのいずれかを使用して費用を見積もる方法の例については、ストレージ料金を予測するをご覧ください。

ストレージ費用は、タイムトラベルとフェイルセーフのデータに適用されますが、課金されるのは、BigQuery の他の場所でデータ ストレージ料金が適用されていない場合のみです。次の詳細が適用されます。

  • テーブルを作成しても、タイムトラベル ストレージやフェイルセーフ ストレージの費用は発生しません。
  • データを変更または削除した場合は、タイムトラベル期間とフェイルセーフ期間中にタイムトラベルによって保存された変更済みデータまたは削除済みデータのストレージに対して課金されます。これは、テーブル スナップショットとクローンに対するストレージ料金と同様です。

データ保持の例

次の表は、削除されたデータまたは変更されたデータがストレージ保持期間間でどのように移動するかを示しています。この例では、アクティブなストレージの合計が 200 GiB で、50 GiB が削除され、タイムトラベル ウィンドウが 7 日間に設定されています。

0 日目 1 日目 2 日目 3 日目 4 日目 5 日目 6 日目 7 日目 8 日目 9 日目 10 日目 11 日目 12 日目 13 日目 14 日目 15 日目
アクティブ ストレージ 200 150 150 150 150 150 150 150 150 150 150 150 150 150 150 150
タイムトラベル ストレージ 50 50 50 50 50 50 50
フェイルセーフ ストレージ 50 50 50 50 50 50 50

長期の物理ストレージからデータを削除する場合も同様です。

制限事項

次のステップ