Fail-safeとは？SnowflakeのContinuous Data Protection

Snowflakeは「Continuous Data Protection（CDP）」という包括的なデータ保護の仕組みを持ち、 Time Travel → Fail-safe → データ暗号化の多層防御でデータを保護しています。 本記事では、CDPの全体像とFail-safeの仕組み、Time Travelとの明確な違い、 テーブルタイプ別の保護期間の違いを比較表つきで解説します。

Continuous Data Protection（CDP）の全体像

CDPはSnowflakeのデータ保護フレームワークで、以下の3つの要素で構成されます。

CDPのタイムライン:

 ← データ変更時点 ──────────────────────────────→ 時間経過

 [即時]          [Time Travel期間]      [Fail-safe期間]
   │                │                      │
   │   ユーザー自身で復旧可能    Snowflakeサポート
   │   - UNDROP                  のみ復旧可能
   │   - SELECT ... AT/BEFORE    （ベストエフォート）
   │   - CREATE ... CLONE ... AT/BEFORE
   │                │                      │
   │    1〜90日（設定次第）        7日間（固定）
   ├──────────────────┤──────────────────────┤
                                             │
                                     保護期間終了 → データ完全削除

Time Travel vs Fail-safe 比較表

テーブルタイプ別の保護期間

テーブルタイプによってTime TravelとFail-safeの適用期間が異なります。コスト最適化とデータ保護のバランスを取る上で、適切なテーブルタイプの選択が重要です。

テーブルタイプの特徴

-- Permanentテーブル（デフォルト）
CREATE TABLE production_data (
  id NUMBER,
  data VARIANT
);
-- Time Travel: 最大90日（Enterprise+）、Fail-safe: 7日

-- Transientテーブル
CREATE TRANSIENT TABLE staging_data (
  id NUMBER,
  raw_json VARIANT
);
-- Time Travel: 最大1日、Fail-safe: なし

-- Temporaryテーブル
CREATE TEMPORARY TABLE session_temp (
  key STRING,
  value STRING
);
-- Time Travel: 最大1日、Fail-safe: なし
-- セッション終了時に自動削除

-- Time Travel保持期間の設定
ALTER TABLE production_data
  SET DATA_RETENTION_TIME_IN_DAYS = 90;

-- テーブルの保持期間を確認
SHOW TABLES LIKE 'production_data';
-- → retention_time カラムで確認

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

Time TravelとFail-safeは変更前のデータ（古いマイクロパーティション）を保持するため、追加のストレージ費用が発生します。

ストレージ消費の内訳:

[アクティブストレージ]     ← 現在のテーブルデータ
         +
[Time Travelストレージ]    ← 変更前のマイクロパーティション（設定期間分）
         +
[Fail-safeストレージ]      ← Time Travel期間後のデータ（7日分）
         =
[合計ストレージ費用]

※ 頻繁にUPDATE/DELETEされるテーブルほどTime Travel/Fail-safeのストレージが大きくなる
※ INSERT ONLYのテーブルでは追加ストレージはほとんど発生しない

-- ストレージ使用状況の確認
SELECT
  TABLE_NAME,
  ACTIVE_BYTES / (1024*1024*1024) AS active_gb,
  TIME_TRAVEL_BYTES / (1024*1024*1024) AS time_travel_gb,
  FAILSAFE_BYTES / (1024*1024*1024) AS failsafe_gb,
  (ACTIVE_BYTES + TIME_TRAVEL_BYTES + FAILSAFE_BYTES) / (1024*1024*1024) AS total_gb
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS
WHERE TABLE_CATALOG = 'MY_DB'
ORDER BY total_gb DESC
LIMIT 20;

Time Travelの操作

-- 過去の時点のデータを参照（AT句）
SELECT * FROM sales
  AT(TIMESTAMP => '2026-03-20 10:00:00'::TIMESTAMP);

-- 指定時間前のデータを参照（OFFSET）
SELECT * FROM sales
  AT(OFFSET => -3600);  -- 1時間前

-- 特定のステートメント実行前のデータを参照（BEFORE句）
SELECT * FROM sales
  BEFORE(STATEMENT => '01b2c3d4-0001-a234-0000-00000000beef');

-- ドロップしたテーブルの復元
UNDROP TABLE deleted_sales;

-- 過去時点のクローンを作成
CREATE TABLE sales_backup CLONE sales
  AT(TIMESTAMP => '2026-03-20 10:00:00'::TIMESTAMP);

UNDROP動作の仕組み

UNDROPはTime Travel期間内でのみ有効です。同名のテーブルが既に存在する場合はUNDROPは失敗します。

• UNDROP TABLE: ドロップしたテーブルを復元
• UNDROP SCHEMA: ドロップしたスキーマを復元（配下のテーブルも復元）
• UNDROP DATABASE: ドロップしたデータベースを復元
• 同名オブジェクトが存在する場合は先にRENAMEが必要

データ暗号化

CDPの第3の柱として、SnowflakeはすべてのデータをAES-256で自動暗号化します。

試験対策のポイント

• Fail-safeは7日間固定で変更不可、復旧はSnowflakeサポート経由のベストエフォート
• Time Travelはユーザーが自身で復旧可能（UNDROP/AT/BEFORE/CLONE）
• TransientテーブルとTemporaryテーブルにはFail-safeが適用されない（0日）
• Enterprise Edition以上ではPermanentテーブルのTime Travelを最大90日に設定可能
• Standard EditionのTime Travelは最大1日
• 同名テーブルが存在する場合、UNDROPは失敗する
• Fail-safe期間はTime Travel期間の終了後に開始する

サンプル問題

よくある質問