このページの一部またはすべての情報は、S3NS の Trusted Cloud に適用されない場合があります。

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

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

タイムトラベルとデータ保持

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

タイムトラベル期間の長さは、2～7 日の範囲で設定できます。タイムトラベル期間が長いと、更新または削除されたデータを復元できることが重要な場合に便利です。タイムトラベル期間を短くすると、物理ストレージの課金モデルを使用する場合にストレージ費用を節約できます。ただし、論理ストレージの料金モデルを使用する場合は、この費用削減は適用されません。ストレージの課金モデルが費用に与える影響については、課金をご覧ください。

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

タイムトラベル期間は、データセットレベルまたはプロジェクトレベルで設定します。これらの設定は、データセットまたはプロジェクトに関連付けられているすべてのテーブルに適用されます。

プロジェクトレベルのタイムトラベル期間を設定する

プロジェクトレベルのデフォルトのタイムトラベル期間を指定するには、データ定義言語（DDL）ステートメントを使用します。プロジェクトレベルのタイムトラベル期間を設定する方法については、構成設定を管理するをご覧ください。

データセットレベルのタイムトラベル期間を設定する

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

新しいデータセットのデフォルトのタイムトラベル期間を指定するには、データセットの作成をご覧ください。
既存のデータセットのタイムトラベル期間を変更または更新するには、タイムトラベル期間を更新するをご覧ください。

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

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

タイムトラベルの仕組み

BigQuery はカラム型ストレージ形式を使用します。つまり、データは行ではなく列で整理され、保存されます。複数の列を含むテーブルがある場合、すべての行の各列の値はストレージブロックにまとめて保存されます。

BigQuery テーブルのセルを変更すると、特定の行と特定の列内の特定の値が変更されます。BigQuery は列をまとめて保存するため、列内の 1 つのセルを変更する場合でも、通常はその列のデータを含むストレージブロック全体を読み取り、変更を適用してから、そのストレージブロックの新しいバージョンを書き込む必要があります。

タイムトラベル機能は、テーブルを構成するストレージブロックのバージョンを追跡することで機能します。データを更新する場合、BigQuery は既存のストレージブロックをその場で変更するだけではありません。代わりに、更新されたデータを含む影響を受けるストレージブロックの新しいバージョンが作成されます。以前のバージョンは、タイムトラベルの目的で保持されます。

BigQuery は、アダプティブファイルサイズとストレージブロックを使用します。ストレージブロックのサイズは固定されておらず、テーブルのサイズやデータ分布などの要因によって異なります。ストレージブロック内の 1 つのセルを変更すると、その列のデータが変更され、多くの行に影響する可能性があります。そのため、バージョン管理されてタイムトラベルに送信されるデータの単位は、多くの場合、単一のセルではなく、その列の変更されたデータを含むストレージブロック全体になります。

そのため、1 つのセルを変更すると、変更のサイズだけでなく、より多くのデータがタイムトラベルに送信されることがあります。

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

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

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

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

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

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

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

次の 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

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

制限事項

タイムトラベルによるデータ取得には、次の制限があります。

タイムトラベルは、タイムトラベル期間中の履歴データにのみアクセスできます。緊急でない目的のためにテーブルデータをタイムトラベル期間より長く保持するには、テーブルスナップショットを使用します。
テーブルに行レベルでアクセスポリシーが設定されている（または、すでに設定されていた）場合は、テーブル管理者のみがタイムトラベルを使用できます。詳細については、タイムトラベルと行レベルのアクセスをご覧ください。
タイムトラベルではテーブルのメタデータは復元されません。
タイムトラベルは、次のテーブルタイプではサポートされていません。
- 外部テーブル
- 一時キャッシュのクエリ結果テーブル
- 一時セッションテーブル
- 一時的なマルチステートメントテーブル
- 外部データセットにリストされているテーブル

次のステップ

タイムトラベルデータをクエリして復元する方法を学習する。
テーブルスナップショットの詳細を確認する。