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 : 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 : Formation Snowflake
J’ai regroupé tous mes articles Snowflake dans un parcours complet.
👉 Accéder à la Formation Snowflake
Vous voulez que je vous accompagne sur votre projet data (Snowflake, ingestion, modélisation, performance, coûts, gouvernance) ?
👉 Réserver un appel de 30 minutes
