Dans l'article sur l'architecture Snowflake, on a surtout regardé comment Snowflake stocke la donnée (micro-partitions immuables, séparation storage / compute, etc.).
Ici, on va zoomer sur une fonctionnalité qui change vraiment la vie au quotidien et qui, à mon sens, est assez révolutionnaire dans le monde de la data et c'est le Time Travel et Fail-safe.
Rappel : Snowflake ne 'modifie' pas les données
Point important à savoir dans Snowflake, il ne réécrit pas la donnée en l'écrasant.
Techniquement, quand tu fais un INSERT, UPDATE ou DELETE, Snowflake ne va pas éditer les lignes une par une. Il va créer de nouvelles versions de ses micro-partitions et marquer les anciennes comme obsolètes.
Une table à un instant T, c'est :
Une vue construite à partir des versions de micro-partitions valides à ce moment-là.
Comme Snowflake garde un historique de ces versions, il peut te remontrer la table telle qu'elle était hier ou la semaine dernière (jusqu'à 90 jours selon l'édition), te permettre de restaurer une table, un schéma ou une base de données supprimée en une seule ligne, ou encore te laisser cloner une table à un instant donné.
C'est quoi concrètement le time travel
Comme dans les précédents articles, rien de mieux qu'un exemple pour comprendre le concept, avec Time Travel, on remonte le temps et on peux interroger une table dans l'état où elle était à un moment précis.
SELECT *
FROM ma_table
AT (TIMESTAMP => '2025-02-10 14:30:00');
Ou “juste avant” un instant donné :
SELECT *
FROM ma_table
BEFORE (TIMESTAMP => TO_TIMESTAMP('2025-02-10 14:30:00'));
C'est très pratique, même en dehors d'une procédure de backup comme par exemple, comparer l'état d’une table avant et après d'un pipeline, ou encore restaurer une table ou un schéma supprimé par erreur, tant que la période de Time Travel le permet.
Restaurer une table supprimée
Ça t'est peut-être déjà arrivé, un DROP TABLE lancé sur la mauvaise base.
Tant que tu es encore dans la fenêtre de Time Travel, tu peux simplement faire :
UNDROP TABLE ma_table;
Et la table revient, comme si rien ne s'était passé.
Même idée pour d'autres objets (UNDROP SCHEMA, UNDROP DATABASE...), tant que la rétention n'est pas expirée.
Cloner une table, un schéma ou une base de donnée à un instant T
Autre usage très pratique et de créer une copie daté de ta table pour tester, rejouer des scénarios, ou auditer.
CREATE OR REPLACE TABLE ma_table_sandbox CLONE ma_table
AT (TIMESTAMP => '2025-02-10 00:00:00');
Snowflake ne recopie pas physiquement toutes les données mais il utilise le zero-copy clone, puisque les micro-partitions sont partagées, et seules les nouvelles versions créent du stockage en plus. Ça permet d'avoir un clone très rapide, pas cher, parfait pour un environnement de test propre.
Lien avec les types de tables Snowflake
Dans l'article sur les types de tables, on a vu que toutes les tables ne sont pas logées à la même enseigne côté protection.
| Type de table | Time Travel (rétention) | Fail-safe | Remarques utiles |
|---|---|---|---|
| Permanent | Par défaut : 1 jour • Plage : 0 à 90 jours (si édition Enterprise/BC, sinon limité à 0–1 jour en Standard) | Oui : 7 jours (fixe, non configurable) | C'est là que tu mets tes tables de prod critiques. Plus tu montes la rétention Time Travel, plus tu gardes longtemps l'historique, donc plus tu payes en stockage. |
| Transient | Par défaut : 1 jour • Plage : 0 à 1 jour | Non | Pensé pour le staging. Tu as un petit filet de sécurité avec Time Travel court, mais pas de Fail-safe. |
| Temporary | Par défaut : 1 jour (selon config) • Plage : 0 à 1 jour | Non | Pensé pour des tables très éphémères. |
| External tables | Pas de Time Travel Snowflake (l'historique dépend de ton storage S3/GCS/Azure) | Non | Snowflake lit les fichiers, mais ne gère pas leur historique. Si tu veux revenir en arrière, c'est côté data lake que ça se joue (versioning S3, etc.). |
Fail-safe : le filet de dernier recours, pas un bouton “Undo”
Fail-safe est souvent mis dans le même sac que Time Travel, alors que ça n'a pas du tout le même usage.
Time Travel, c'est ce que tu peux utiliser au quotidien avec les requêtes dans le passé, UNDROP, clones à un instant T, etc...
Fail-safe, c'est autre chose car après la fin de la durée de rétention du Time Travel, Snowflake garde encore les données quelques jours dans une zone spéciale appelée Fail-safe.
Cette zone n'est pas accessible en SQL ni via l'interface. Elle est gérée uniquement par le support Snowflake, principalement pour des besoins internes (restauration après un incident grave, corruption, problème côté infra...).
Du coup, il ne faut surtout pas partir du principe que « au pire, Fail-safe nous sauvera » car même si c'est une sécurité de dernier recours, il faut passer par le support et ça peut prendre plusieurs jours. Donc pour restaurer vos données ou rattraper une erreur humaine ce qui compte vraiment, c'est le Time Travel et rien d'autre.
Aller plus loin : préparer la SnowPro Core
Time Travel et Fail-safe sont des sujets récurrents à l'examen SnowPro Core, particulièrement les pièges sur les types de tables (transient et temporary n'ont jamais de Fail-safe) et les durées par édition (90 jours uniquement en Enterprise/BC). Sur DataCertification.fr, le module SnowPro Core couvre ces sujets avec 700 questions scenario-based au format de l'examen officiel.
👉 Préparer la SnowPro Core sur DataCertification.fr
Pour aller plus loin sur Snowflake en général, j'ai regroupé tous mes articles dans un parcours complet.
👉 Accéder à la Formation Snowflake
Tu veux que je t'accompagne sur ton projet data (Snowflake, restauration d'incidents, stratégie de rétention, gouvernance) ?
👉 Réserver un appel de 30 minutes
Questions
Quelle est la différence entre Time Travel et Fail-safe dans Snowflake ?
Time Travel permet de remonter dans le temps sur les données via des requêtes dans le passé avec SELECT AT, restauration avec UNDROP, clones à un instant T. La durée est configurable de 0 à 90 jours selon l'édition. Fail-safe est un filet de sécurité de 7 jours fixes qui commence après la fin du Time Travel. Il n'est pas accessible en SQL et nécessite de contacter le support Snowflake. Ne compte jamais sur Fail-safe pour récupérer une erreur humaine.
Combien de temps dure le Time Travel dans Snowflake ?
Par défaut, la rétention Time Travel est de 1 jour sur les tables permanentes. Tu peux la configurer entre 0 et 90 jours sur les éditions Enterprise et Business Critical (DATA_RETENTION_TIME_IN_DAYS). Sur l'édition Standard, la rétention est limitée à 0 ou 1 jour. Les tables transient et temporary sont limitées à 0-1 jour quelle que soit l'édition.
Comment restaurer une table supprimée dans Snowflake ?
Utilise la commande UNDROP TABLE nom_table tant que tu es dans la fenêtre de rétention Time Travel. Pour les schemas et databases, UNDROP SCHEMA et UNDROP DATABASE fonctionnent de la même manière. Si la rétention Time Travel est expirée, il faut contacter le support Snowflake pour une restauration depuis Fail-safe (uniquement disponible sur les tables permanentes, 7 jours après la fin du Time Travel).
Comment interroger une table dans le passé en SQL Snowflake ?
Utilise la clause AT ou BEFORE après le nom de la table : SELECT * FROM ma_table AT(TIMESTAMP => '2025-02-10 14:30:00') pour interroger à un instant précis, ou AT(OFFSET => -3600) pour il y a 1 heure. La clause BEFORE permet de remonter juste avant un statement précis avec BEFORE(STATEMENT => 'query_id').
Qu'est-ce que le zero-copy clone dans Snowflake ?
Le zero-copy clone crée un clone d'une table, d'un schéma ou d'une base de données qui pointe vers les mêmes micro-partitions que la source. Tant que tu ne modifies pas les données du clone, il ne consomme pas de stockage supplémentaire et c'est instantané. La syntaxe est CREATE TABLE clone_table CLONE source_table. On peut aussi cloner à un instant T avec CLONE source_table AT(TIMESTAMP => '...') via Time Travel.
Les tables transient et temporary ont-elles du Fail-safe ?
Non. Les tables transient et temporary n'ont jamais de Fail-safe, quelle que soit l'édition Snowflake. Leur Time Travel est aussi limité à 0 ou 1 jour maximum. C'est un piège fréquent à la certification SnowPro Core. C'est pour cette raison que les tables transient sont préférées pour le staging et les données rejouables depuis la source.
Le Time Travel impacte-t-il la facture Snowflake ?
Oui. Plus tu augmentes la rétention Time Travel (jusqu'à 90 jours), plus Snowflake garde de versions de micro-partitions, et plus tu paies en stockage. Sur des tables très mouvementées (UPDATE et DELETE fréquents), le surcoût peut être significatif. La bonne pratique est d'adapter la rétention au type de table : 7 jours sur les marts critiques, 1 jour sur les tables intermédiaires, 0 sur les tables d'audit append-only
Peut-on accéder au Fail-safe en SQL ?
Non. Le Fail-safe n'est accessible ni en SQL, ni via l'interface Snowflake. Il est géré uniquement par le support Snowflake et utilisé en dernier recours pour des restaurations après incident grave (corruption de données, problème côté infrastructure). La récupération via Fail-safe peut prendre plusieurs jours, ce qui en fait une option de secours, pas une solution opérationnelle.
Peut-on cloner une table à un instant précis avec Time Travel ?
Oui. Combine CLONE et AT(TIMESTAMP =>) pour cloner une table à un instant précis : CREATE TABLE backup_table CLONE source_table AT(TIMESTAMP => '2025-02-10 00:00:00'). C'est très utile pour créer un environnement de test isolé qui reflète l'état de production à une date donnée. Le clone est instantané et ne consomme du stockage que sur les divergences ultérieures.
Que se passe-t-il si je dépasse la fenêtre Time Travel ?
Une fois la fenêtre Time Travel dépassée, les données entrent en Fail-safe pendant 7 jours (uniquement pour les tables permanentes). Tu ne peux plus les récupérer en SQL ni avec UNDROP. La seule option restante est de contacter le support Snowflake pour une restauration depuis Fail-safe, ce qui peut prendre plusieurs jours et n'est pas garanti dans tous les cas. Après les 7 jours de Fail-safe, les données sont définitivement perdues.