Snowflakeのデータ保持と復旧｜Time Travel・Fail-safe・保持期間設計

Snowflakeのデータ保持と復旧は、Time TravelとFail-safeの2つの仕組みで構成されています。Time Travelはユーザーが過去のデータに直接アクセスできる機能で、Fail-safeはTime Travel期間終了後の最終防衛ラインとしてSnowflakeが内部的に保持するデータ保護です。

この記事では、2つの仕組みのタイムライン・エディション別の保持期間・テーブル種類ごとの違い・ストレージコストへの影響を整理します。SnowPro Core試験のDomain 6（Data Protection & Data Sharing / 配点10〜15%）で頻出するトピックです。

データ保持のタイムライン

データの変更（UPDATE/DELETE/DROP）が発生した時点を起点として、以下のタイムラインでデータが保持されます。

データ変更発生
  │
  ├── Time Travel期間（0〜90日）──────┐
  │   ユーザーがAT/BEFORE句で        │
  │   過去データに直接アクセス可能     │
  │   UNDROP TABLE/SCHEMA/DATABASE   │
  │   で復元可能                     │
  │                                  │
  ├── Fail-safe期間（7日間）─────────┐
  │   Snowflakeサポートによる        │
  │   データ復旧のみ可能             │
  │   ユーザーは直接アクセス不可      │
  │                                  │
  └── データ完全消去                  │
      復旧不可能

Enterprise Edition（Time Travel 90日）の場合、データ変更から最大97日間（90日 + 7日）のデータ保護期間があることになります。Standard Edition（Time Travel 最大1日）では最大8日間（1日 + 7日）です。

Time Travel の詳細

アクセス構文

UNDROP による復元

Time Travel期間内であれば、DROP TABLEで削除したテーブル・スキーマ・データベースをUNDROPで復元できます。

-- テーブルの復元
UNDROP TABLE sales;

-- スキーマの復元
UNDROP SCHEMA analytics;

-- データベースの復元
UNDROP DATABASE production;

同名のオブジェクトがすでに存在する場合はUNDROPが失敗するため、事前にALTER TABLE ... RENAMEで既存オブジェクトをリネームする必要があります。

エディション別保持期間の比較

Standard EditionではDATA_RETENTION_TIME_IN_DAYSの最大値が1日に制限されており、90日のTime Travelを利用するにはEnterprise以上へのアップグレードが必要です。

テーブル種類別のデータ保持

Snowflakeには3種類のテーブル（Permanent / Transient / Temporary）があり、それぞれデータ保持の仕様が異なります。試験では3種類の違いが頻出します。

テーブル種類の選択基準

• Permanent：ビジネスクリティカルなデータ。誤操作からの復元が必要なマスターテーブル・ファクトテーブルに使用。Time TravelとFail-safeの両方で保護される。
• Transient：再作成可能なデータ。ETLのステージングテーブル・中間集計テーブルなど、ソースから再生成できるデータに使用。Fail-safeが不要なためストレージコストを削減できる。
• Temporary：セッション限定のデータ。セッションが終了するとテーブルが自動的に削除される。他のユーザーからは見えない。分析の作業テーブルに使用。

ストレージコストへの影響

Time TravelとFail-safeのデータ保持はストレージコストに直接影響します。保持期間中のデータは変更前の状態（差分データ）として保持されるため、変更が多いテーブルほどストレージコストが増加します。

頻繁にUPDATE/DELETEが実行されるテーブルでTime Travel 90日を設定すると、ストレージコストが大幅に増加する可能性があります。テーブルの重要度と更新頻度に応じてDATA_RETENTION_TIME_IN_DAYSを適切に設定してください。

保持期間の設計指針

階層的な設定戦略

DATA_RETENTION_TIME_IN_DAYSはアカウント・データベース・スキーマ・テーブルの各レベルで設定でき、下位レベルが上位レベルを上書きします。

-- アカウントレベル（デフォルト30日）
ALTER ACCOUNT SET DATA_RETENTION_TIME_IN_DAYS = 30;

-- ステージングスキーマ（0日 = Time Travel無効）
ALTER SCHEMA staging SET DATA_RETENTION_TIME_IN_DAYS = 0;

-- 重要テーブル（90日 = 最大保持）
ALTER TABLE master_customers SET DATA_RETENTION_TIME_IN_DAYS = 90;

推奨設定パターン

Fail-safe の運用上の注意点

• Fail-safeのデータ復旧はSnowflakeサポートへの問い合わせが必要で、復旧には数時間〜数日を要します。即座の復旧はできません。
• Fail-safeはPermanentテーブルにのみ適用され、TransientテーブルとTemporaryテーブルには適用されません。
• Fail-safe期間中のストレージコストはユーザーに課金されます。コストを削減したい場合はTransientテーブルの活用を検討してください。
• Fail-safeの期間（7日間）はユーザーが変更することはできません。固定値です。
• Fail-safeはデータの「最終保険」であり、通常の運用ではTime TravelとUNDROPで復元を完結させることが前提です。

問題で確認

よくある質問（FAQ）