データ基盤

Snowflake Time Travel（タイムトラベル）とは？保持期間と復元

2026/10/28 （更新: 2026/11/3） シリーズ「Snowflake 入門」 第6回 / 全13回

🤖 AIを使用して執筆

SELECT * FROM tt1 AT(TIMESTAMP => '2024-06-05 15:29:00'::TIMESTAMP_LTZ);

+----+----+
| C1 | C2 |
|----+----|
|  1 |  2 |
|  2 |  3 |
+----+----+

過去を残せるのは、ファイルを書き換えないから

Snowflake の創業者らによる 2016 年の論文（データベースの国際会議 SIGMOD で発表）は、その仕組みを次のように説明している³。

• 表のファイルは書き換えない。保存にクラウドのオブジェクトストレージ（Amazon S3）を使うことから来た設計である。
• 行を足す、変える、消すといった書き込みは、ファイルを丸ごと足したり外したりして、表の新しい版を作る。
• 新しい版で外れたファイルは、決めた期間（論文の時点で最大 90 日）消さずに残す。
• 残したファイルを読めば、前の版の表を効率よく読める。これが Time Travel である。

今の Snowflake では、表のデータを小さく分けて持つファイルを、マイクロパーティションという。変更があると、影響を受けたマイクロパーティションが作り直され、前のものは履歴として保持期間のあいだ保たれる⁴。どの版の表がどのマイクロパーティションでできているかは、データとは別の管理用の記録（メタデータ）に残される⁵。

保持期間：既定は 1 日、最大 90 日

履歴を残す期間を、保持期間という。保持期間は既定で 1 日で、どのアカウントでも自動で有効になっている¹。

• 1 日より長くするには、Snowflake の契約の種類（エディション）が Enterprise Edition 以上である必要がある。永続の表（ふつうの表）なら、0 から 90 日まで決められる¹。
• Standard Edition では、0 日か 1 日である¹。
• 0 日にすると、その表の Time Travel は事実上止まる¹。アカウントの最低保持期間（後で述べる）も含めて、実際の保持期間が 0 日の表を消すと、UNDROP でも戻せない¹。Snowflake は、どの表も少なくとも 1 日は保つよう勧めている¹。

保持期間は、パラメータ DATA_RETENTION_TIME_IN_DAYS で、アカウント、データベース、スキーマ、表の単位で決める⁶。上の単位で期間を変えると、期間を明示していない下のデータベース、スキーマ、表は、すでにあるものも新しい期間を引き継ぐ¹。Snowflake は、予期しない結果になりうると注意し、とくにアカウントの単位で期間を 0 にすることは勧めていない¹。

アカウントに MIN_DATA_RETENTION_TIME_IN_DAYS を決めておくと、表ごとの値がそれより短くても、長いほうが使われる¹。利用者が表の保持期間を 0 日にしても、アカウントで決めた最低の期間は保たれる。

期間を数え始めるのは、表を作ったときではなく、そのデータが変わったり消されたりしたときである¹。期間を延ばすと、いま Time Travel にある履歴も長く保たれる。ただし、すでに Fail-safe に移った履歴は戻らない¹。

データベースを消すと、その中の表に別の保持期間を決めていても、表はデータベースの保持期間に従う¹。表ごとの期間を守りたいなら、先に表を消してからデータベースを消す。

過去を読む、消した表を戻す、過去の時点を写す

保持期間の間は、次の三つができる¹。

過去を読む（AT と BEFORE）： SELECT の表の名前の後に、AT か BEFORE で時点を指定する。時点の指定は三つある²。

AT は、指定した時点の変更を含む。BEFORE は、指定した時点の直前を指す²。BEFORE で STATEMENT を指定したときは、文が始まる前ではなく、文が終わる直前を指す²。文が動いている間に、ほかのクエリが確定させた変更は、結果に含まれる²。

クエリ ID で指定できるのは、14 日以内に実行した文だけである。それより前の文は、その文の時刻で指定する²。保持期間の外の時点を指定すると、エラーが返る²。過去の中身は、今の表の定義（列や既定の値）で返る²。

消した表を戻す（UNDROP）： UNDROP TABLE は、消した表の最も新しい版を、消したときのデータベースとスキーマに戻す⁷。スキーマとデータベースにも UNDROP がある¹。

同じ名前の表を作り直していると、UNDROP は失敗する。今の表の名前を変えてから UNDROP すると、前の版が戻る¹。同じ名前で消すことと作ることを繰り返していれば、UNDROP は、最も新しく消した版から順に戻す¹。

過去の時点を写す（クローン）： CREATE TABLE … CLONE に AT か BEFORE を付けると、過去の時点の表の写しを作れる。データベースやスキーマごとでも作れる⁸。

Snowflake の Well-Architected Framework は、誤った UPDATE や DELETE のようなデータの論理的な破損に対して、Time Travel を「最初の、最も速い守り」と位置付けている⁹。戻し方を手順書にして、定期的に試しておくよう勧めている⁹。同じ文書は、誤ってデータを変えた文のクエリ ID をクエリの履歴から探し、その文の直前の時点を BEFORE で読んで、正しいデータを表へ入れ直す手順も示している⁹。

CREATE TABLE … CLONE と ALTER TABLE … SWAP WITH を組み合わせる次の戻し方は、Snowflake のドキュメントに手順としては載っていない。誤った文の直前の時点のクローンを作り、中身を確かめてから、元の表と名前を入れ替える。

-- 誤った UPDATE の直前の表を写す。COPY GRANTS で元の表の権限も写す
CREATE TABLE my_table_restored CLONE my_table
  BEFORE (STATEMENT => '<誤った UPDATE のクエリ ID>')
  COPY GRANTS;
-- 中身を確かめてから、二つの表の名前を入れ替える
ALTER TABLE my_table SWAP WITH my_table_restored;

CLONE の後に AT か BEFORE、その後に COPY GRANTS を書く¹⁰。SWAP WITH は、二つの表の名前を一つのトランザクションで入れ替える¹¹。

入れ替えた後の表は、元の表とは別の表なので、次の点が変わる。

• COPY GRANTS で写るのは明示的に与えた権限で、所有権（OWNERSHIP）と、スキーマ内に新しく作る表などへ自動で与える権限（future grants）は写らない¹²⁸。
• 自動クラスタリングは止まった状態で作られ、ストレージのライフサイクルポリシーも付かない⁸。
• Time Travel の履歴はクローンを作った時点から始まる。それより前の履歴は、名前を入れ替えたほうの表が持つ¹²。

Fail-safe：保持期間の後の 7 日は、Snowflake だけが戻せる

永続の表では、保持期間を過ぎた履歴は Fail-safe に移る¹。消すまで残る TRANSIENT の表と、セッションが終わると消える TEMPORARY の表には Fail-safe がない¹³。Fail-safe の期間は 7 日で、変えられない¹⁴。

• Fail-safe の履歴は、利用者は読めない。戻すには Snowflake のサポートに依頼する¹⁴。
• 戻すのはベストエフォートで、ほかの戻し方をすべて試した後に使うためのものである。戻すのに数時間から数日かかる¹⁴。
• 目的は、システムの障害やセキュリティの侵害のような、極端な事態で失われたデータを Snowflake が戻すことである¹⁴。

Snowflake の Well-Architected Framework も、Fail-safe はふだんの戻し方に組み込まず、最後の守りとして扱うよう勧めている⁹。

保存の料金：履歴も料金の対象になる

Time Travel と Fail-safe の履歴は、保存の料金の対象になる¹⁵。履歴は、今の表、Time Travel、Fail-safe の順に移り、Fail-safe を出るまで料金がかかる⁴。行を足すだけの表でも、INSERT や COPY で読み込むと、小さなマイクロパーティションをまとめ直す処理で古いものが消され、その分が Time Travel と Fail-safe の料金の対象になる⁴。

よく書き換わる表では、履歴が今の表よりずっと大きくなることがある⁴。Snowflake のドキュメントは、極端な例として、200 GB の表のすべての行を 1 日に 20 回書き換える場合を示している。今の表 200 GB に対して、Time Travel が 4 TB、Fail-safe が 28 TB で、合わせて 32.2 TB になる⁴。

それでも Snowflake は、ほとんどの場合は永続の表にして、Time Travel と Fail-safe で守るのがよいとしている。保存の料金は安く、よく書き換わる表の多くは、保存するデータ全体のうち小さい割合だからである⁴。保存するデータが大きくなりすぎる表に限って、保持期間 0 日の TRANSIENT の表にし、定期的に永続の表へ写す方法を挙げている。1 日 1 回写すなら、合わせて 2 TB になる⁴。

表の種類ごとの期間は、次のとおりである¹³。

TRANSIENT の表の履歴は、保持期間を過ぎると Snowflake にも戻せない。Snowflake は、TRANSIENT の表は Snowflake の外で作り直せるデータにだけ使い、ファクトテーブルのように長く使う表は常に永続にするよう書いている¹⁵。使う期間が 1 日に満たない ETL（Extract-Transform-Load、抽出・変換・読み込み）の作業用の表は、TRANSIENT にしてよいとしている¹⁵。ただし、消えたデータを読み込み直す時間や、そのあいだ業務が止まる時間を考えると、Fail-safe の料金を払っても永続の表のほうがよいこともあるとしている¹⁵。

どの表がどれだけ履歴を持っているかは、TABLE_STORAGE_METRICS で見られる¹⁶。

数字が更新されるまでに、1〜2 時間かかることがある¹⁶。FAILSAFE_BYTES を ACTIVE_BYTES で割った比が大きい表が、よく書き換わる表である⁴。

ゼロコピークローニング：ファイルの記録だけを写す

Snowflake では、ファイルを写さずに表やスキーマ、データベースの写しを作ることを、ゼロコピークローニングという⁸。

論文によれば、クローンは元の表のメタデータを写すだけである。作った直後は、二つの表が同じファイルを参照し、その後はそれぞれ別に変えられる³。今のドキュメントでも、クローンは書き込みができ、元の表とは独立している⁸。

• クローンは、中身を変えたり足したりするまで、保存するデータを増やさない⁸。
• クローンを変えると、新しいマイクロパーティションができ、それはクローンだけのものになる⁴。
• 元の表で消したマイクロパーティションも、クローンが参照していれば保たれ、TABLE_STORAGE_METRICS の RETAINED_FOR_CLONE_BYTES に出る¹⁶。

クローンに引き継がれないものもある⁸¹²。

• 元の表の読み込みの履歴。元の表に読み込んだファイルを、クローンにもう一度読み込める。
• 元の表に与えた権限（COPY GRANTS を付けない場合）。
• データベースやスキーマのクローンでの、外部テーブル。
• 表のステージにあるファイル。
• クローンの Time Travel の履歴。クローンの履歴は、クローンを作った時点から始まる。

データベースやスキーマのクローンに入るタスクは、止まった状態で作られる¹²。ただし、時刻（TIMESTAMP）で過去の時点を指定したクローンには、データベースやスキーマの中のタスクは入らない⁸。クローンを作るのは速いが、大きな表では一瞬ではない¹²。

もっと長く、消せない形で残すなら

Time Travel と Fail-safe は短い期間の守りで、規則によってはもっと長く、変えられない形で残す必要がある⁹。Snowflake では、そのための機能を Backups という。2025 年 8 月にプレビューとして出て（当時の名前は WORM snapshots。WORM は Write Once, Read Many の略で、一度書いたら変えられないことを指す）、2025 年 12 月に一般提供になった¹⁷。

• バックアップは、ある時点の表、スキーマ、データベースの写しで、変えられない¹⁸。クローンと同じく、ファイルを写さない¹⁸。
• バックアップに保持ロックを付けると、期限まではどのロールでもそのバックアップを消せない。付けると外せず、Snowflake のサポートも外せない。保持ロックは Business Critical Edition 以上で使える¹⁸。
• バックアップ自体はどのエディションでも使えるが、TRANSIENT の表は対象にならない¹⁸。
• Time Travel の保持期間は 0 日まで縮められるが、保持ロック付きのバックアップの期限は縮められない¹⁸。

Snowflake の Well-Architected Framework は、別のリージョンへの複製は、リージョンの障害には要るが、人の誤りやデータの破損への備えの代わりにはならないとしている⁹。同じ文書は、複製に加えて、重要なデータベースのゼロコピークローンを定期的に自動で作るか、変えられないバックアップを Snapshots（いまの Backups）で定期的に作るよう勧めている⁹。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。