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

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

タイムトラベル

デフォルトでは、過去 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 列で確認できます。これらのビューのいずれかを使用して費用を見積もる方法の例については、ストレージ料金を予測するをご覧ください。

物理ストレージの例

次の表は、物理ストレージを使用している場合に、削除されたデータに対して発生する料金を示しています。この例では、アクティブな物理ストレージの合計が 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

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

制限事項

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

次のステップ

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