Snowflake Time Travel

Time Travelは、Snowflakeのデータ保護の中核機能で、テーブル・スキーマ・データベースの過去の状態にアクセスし、誤操作からの復旧や履歴データの参照を可能にします。AT/BEFORE句による過去時点クエリ、UNDROPによるオブジェクト復元、DATA_RETENTION_TIME_IN_DAYSによる保持期間制御が試験で頻出の3大ポイントです。

保持期間とエディション差分

Time Travelの保持期間はDATA_RETENTION_TIME_IN_DAYSパラメータで制御します。この値はアカウント・データベース・スキーマ・テーブルの各レベルで設定でき、下位レベルの設定が上位を上書きします。

-- テーブルレベルで保持期間を90日に設定
ALTER TABLE analytics.orders
  SET DATA_RETENTION_TIME_IN_DAYS = 90;

-- スキーマレベルで保持期間を設定（配下テーブルのデフォルト値になる）
ALTER SCHEMA analytics
  SET DATA_RETENTION_TIME_IN_DAYS = 30;

-- 現在の設定を確認
SHOW PARAMETERS LIKE 'DATA_RETENTION_TIME_IN_DAYS'
  IN TABLE analytics.orders;

AT/BEFORE句による過去時点クエリ

AT句は指定した時点の状態を返し、BEFORE句は指定した時点の直前の状態を返します。タイムスタンプ指定・オフセット指定・Statement ID指定の3パターンがあります。

タイムスタンプ指定

-- AT: 指定時刻の状態を取得
SELECT *
FROM analytics.orders
  AT (TIMESTAMP => '2026-03-27 09:00:00'::TIMESTAMP_NTZ);

-- BEFORE: 指定時刻の直前の状態を取得
SELECT *
FROM analytics.orders
  BEFORE (TIMESTAMP => '2026-03-27 09:00:00'::TIMESTAMP_NTZ);

オフセット指定

-- 30分前の状態を取得
SELECT *
FROM analytics.orders
  AT (OFFSET => -60 * 30);

-- 2時間前の状態を取得
SELECT COUNT(*) AS row_count_2h_ago
FROM analytics.orders
  AT (OFFSET => -60 * 60 * 2);

Statement ID指定

-- 特定のDML実行直前の状態を取得（誤操作復旧に最適）
SELECT *
FROM analytics.orders
  BEFORE (STATEMENT => '01b12345-0600-1234-0000-abcdef012345');

Statement IDはQUERY_HISTORYビューから取得できます。誤ったUPDATE/DELETEを実行してしまった場合、そのStatement IDをBEFORE句に指定することで、まさにその操作の直前の状態に戻せます。

Time Travelを使ったデータ復旧パターン

-- パターン1: 誤UPDATEの復旧（CLONE + SWAP）
CREATE TABLE analytics.orders_restored
  CLONE analytics.orders
  BEFORE (STATEMENT => '01b12345-0600-1234-0000-abcdef012345');

-- 復元テーブルの内容を確認後、テーブルを入れ替え
ALTER TABLE analytics.orders RENAME TO analytics.orders_backup;
ALTER TABLE analytics.orders_restored RENAME TO analytics.orders;

-- パターン2: 特定行だけ復旧（部分復旧）
INSERT INTO analytics.orders
SELECT * FROM analytics.orders
  BEFORE (STATEMENT => '01b12345-0600-1234-0000-abcdef012345')
WHERE order_id IN (1001, 1002, 1003);

UNDROP TABLE / SCHEMA / DATABASE

DROPされたオブジェクトを保持期間内であればUNDROPで復元できます。テーブル・スキーマ・データベースの3レベルで利用可能です。

-- テーブルの復元
DROP TABLE analytics.orders;
UNDROP TABLE analytics.orders;

-- スキーマの復元（配下の全テーブルも復元）
DROP SCHEMA analytics;
UNDROP SCHEMA analytics;

-- データベースの復元（配下の全スキーマ・テーブルも復元）
DROP DATABASE sales_db;
UNDROP DATABASE sales_db;

同名のオブジェクトが既に再作成されている場合、UNDROPは失敗します。この場合は先に既存オブジェクトをリネームしてからUNDROPを実行します。

-- 同名テーブルが既に存在する場合の復元手順
ALTER TABLE analytics.orders RENAME TO analytics.orders_new;
UNDROP TABLE analytics.orders;

Fail-safeとの関係

Fail-safeはTime Travel期間終了後の追加7日間にわたるデータ保護レイヤーです。Time Travelとは根本的に異なり、ユーザーが直接操作することはできません。

データ保護タイムライン

|<── Time Travel (0〜90日) ──>|<── Fail-safe (7日) ──>|
|  ユーザーが自由に参照・復元  | Snowflakeサポートのみ |

例: Enterprise Edition / DATA_RETENTION = 90日 / Permanent Table
  → 最大97日間のデータ保護（90日 + 7日）

例: Standard Edition / DATA_RETENTION = 1日 / Permanent Table
  → 最大8日間のデータ保護（1日 + 7日）

例: Transient Table（全エディション共通）
  → 最大1日のTime Travel、Fail-safeなし

テーブル種類別のデータ保護まとめ

ストレージコスト管理

• TABLE_STORAGE_METRICS：ACCOUNT_USAGE.TABLE_STORAGE_METRICSビューでテーブルごとのACTIVE_BYTES / TIME_TRAVEL_BYTES / FAILSAFE_BYTESを確認
• 保持期間の最適化：重要度の低いテーブルはDATA_RETENTION_TIME_IN_DAYSを短く設定し、ストレージコストを削減
• Transient Tableの活用：ETLの中間テーブルなど再生成可能なデータにはTransient Tableを使い、Fail-safeコストを回避

問題で確認

よくある質問