Database branching : cloner la prod sans copier le disque

Le ticket arrive un mardi matin. Un client signale un calcul de facturation faux sur trois dossiers, uniquement en production. Le développeur tente de reproduire sur son environnement local : impossible, ses fixtures contiennent quarante lignes propres et la prod en compte quatorze millions, avec quinze ans de reprises de données, de migrations ratées et de champs remplis à la main par le service compta en 2019.

La suite est toujours la même. Quelqu'un lance un pg_dump de 800 Go, ça tourne pendant six heures, la restauration en prend huit de plus, et pendant ce temps le bug reste ouvert. Une semaine plus tard, l'environnement de test créé pour l'occasion est encore là, jamais nettoyé, avec les vraies adresses des clients dedans.

Le database branching règle la partie technique de ce problème. Il aggrave sérieusement la partie juridique. Les deux méritent d'être traitées ensemble, parce que la seconde est celle qu'on oublie.

L'idée tient en une phrase : une copie de base de données ne devrait pas coûter le prix de la base.

Neon a popularisé le concept sur PostgreSQL et l'a rendu lisible pour les développeurs, avec un vocabulaire emprunté à Git. Leur démonstration publique porte sur un jeu de données de 1 To (1047,48 Go exactement) : la création d'une branche ne recharge rien, elle référence les mêmes pages de données que le parent, et n'écrit de nouvelles pages que pour ce qui est modifié ensuite. La copie est une opération de métadonnées, pas une opération de stockage.

Le marketing parle de branching serverless. Côté ops, c'est du copy-on-write, technique que les systèmes de fichiers font depuis vingt ans. Neon l'a implémenté dans un pageserver maison au niveau de la page Postgres. ZFS et LVM thin le font au niveau du bloc, et ils tournent déjà sur les serveurs qu'on opère.

La conclusion n'est pas « Neon ne sert à rien ». Elle est qu'on peut obtenir le même effet opérationnel sans confier une copie complète de sa base de production à un service tiers, sans dépendance à une API propriétaire, et sans facturation à la branche.

Le prérequis est d'avoir le PGDATA sur un dataset ZFS. Le reste est mécanique.

# 1. Snapshot atomique du répertoire de données
zfs snapshot tank/pgdata@2026-08-05-0400

# 2. Clone inscriptible à partir du snapshot
zfs clone tank/pgdata@2026-08-05-0400 tank/branch-ticket-4471

# 3. Instance Postgres pointée sur le clone, sur un autre port
pg_ctl -D /tank/branch-ticket-4471 -o "-p 5501" start

La documentation OpenZFS est explicite sur le point qui compte : la création d'un clone est quasi instantanée et ne consomme initialement aucun espace supplémentaire. Les blocs ne divergent qu'à la première écriture.

Le projet DBLab, qui industrialise exactement ce schéma pour PostgreSQL sous licence Apache 2.0, annonce le clonage d'une base de 1 TiB en une dizaine de secondes, avec ZFS par défaut et LVM en alternative. C'est l'ordre de grandeur qu'on retrouve sur le terrain : le temps de la commande, plus le temps de démarrage de Postgres, plus le rejeu du WAL si le snapshot a été pris à chaud.

Ce dernier point est le seul vrai piège technique. Un snapshot ZFS pris pendant que Postgres tourne est cohérent au sens crash-consistent : au démarrage, l'instance clonée se comporte comme après une coupure de courant et rejoue son journal. C'est supporté et documenté, à condition que l'intégralité du PGDATA, WAL compris, vive sur le même dataset. Si les WAL sont sur un autre volume, le snapshot n'est plus atomique et le clone démarre corrompu. On voit cette erreur régulièrement chez les audités : la séparation données/WAL a été faite pour des raisons de performance, personne n'a rejoué le raisonnement au moment d'ajouter les snapshots.

Le clone garde une dépendance implicite à son snapshot d'origine : impossible de détruire le snapshot tant qu'un clone en dépend, ZFS liste les dépendances et refuse. zfs promote inverse la relation si on veut vraiment garder la branche et jeter le parent. En pratique, sur une branche de test, on ne promeut jamais : on détruit.

Sur un socle où ZFS n'est pas une option, LVM thin fait le même travail. Les blocs communs à un volume logique fin et à ses snapshots sont partagés dans le pool, et rien n'interdit d'enchaîner les snapshots de snapshots.

lvcreate --snapshot -n branch-ticket-4471 vg_data/lv_pgdata

Pas d'option --size sur un snapshot thin : la taille virtuelle est héritée de l'origine, et préciser une taille bascule LVM sur l'ancien mécanisme de snapshot COW classique, celui qui sature et se casse. Le détail est dans la page de manuel lvmthin(7), il coûte un environnement de test par an à ceux qui ne l'ont pas lue.

Le risque propre à LVM thin est le surprovisionnement. Le pool accepte de créer plus de volume logique que de capacité physique. Quand il se remplit, le comportement par défaut est de mettre les écritures en file d'attente pendant 60 secondes, puis de retourner des erreurs. Une base de données qui prend des erreurs d'écriture en rafale, c'est un incident de production, pas un incident de test, parce que le volume d'origine est dans le même pool.

La règle qu'on applique : surveillance de lvs -o data_percent,metadata_percent avec alerte à 75 % et extension automatique via dmeventd. Les métadonnées comptent autant que les données, et c'est presque toujours par les métadonnées que le pool meurt en premier. Le sujet est traité plus en détail dans notre guide sur le pilotage avancé de LVM, et la logique de rétention des snapshots recoupe celle décrite pour les snapshots et la réplication ZFS.

Le gain le plus évident est la reproduction de bug. Un clone du snapshot de 4 h du matin, sur lequel on rejoue la transaction fautive, ferme un ticket en vingt minutes au lieu de trois jours d'aller-retour.

Le gain le moins évident, et le plus structurant, concerne les tests d'intégration. Une suite qui tourne contre une base clonée peut se permettre d'être destructrice : elle supprime, tronque, migre, et le clone part à la poubelle à la fin. Plus de scripts de nettoyage entre les tests, plus de tests qui échouent parce que le précédent a laissé une ligne. Chaque job de CI démarre sur un état identique et connu, avec la distribution réelle des données.

Cette dernière partie est celle que les fixtures ne rattraperont jamais. Un plan d'exécution Postgres dépend des statistiques de la table. Sur quarante lignes de fixtures, le planificateur choisit un Seq Scan et tout est instantané. Sur quatorze millions de lignes avec une distribution asymétrique, il choisit autre chose, et c'est là que la requête part à trente secondes. Un test de performance contre des fixtures ne teste rien du tout.

Troisième usage, plus rare mais décisif : le test de migration de schéma. Une migration ALTER TABLE sur une grosse table se comporte différemment selon le volume et les index existants. La jouer d'abord sur un clone donne la durée réelle et le verrou réel, avant la fenêtre de maintenance. C'est le seul moyen honnête de chiffrer une migration, et ça vaut aussi pour valider un basculement sur une architecture répliquée comme PostgreSQL en haute disponibilité avec Patroni.

Le discours commercial dit « les branches sont gratuites ». C'est vrai à la création, faux ensuite.

Un clone ne coûte rien tant qu'il ne diverge pas. Dès qu'une écriture touche un bloc partagé, ce bloc est dupliqué. Une suite de tests qui fait un VACUUM FULL ou une migration réécrivant une table entière fait diverger l'intégralité des blocs concernés. Sur une table de 200 Go, la branche « gratuite » vient de coûter 200 Go.

Le coût réel se calcule sur trois variables : le taux d'écriture des tests, la durée de vie du clone, et le nombre de clones simultanés. Le paramètre sur lequel on agit est le deuxième. Un clone de CI qui vit quinze minutes ne coûte presque rien. Un clone de développeur oublié depuis six semaines, sur lequel la base a continué à diverger, coûte une copie complète et bloque en plus la destruction du snapshot parent.

La recommandation actionnable, celle qui fait la différence entre un dispositif propre et une bombe à retardement : imposez une durée de vie aux branches dès le premier jour, par un TTL automatique et non par une convention d'équipe. Un cron qui détruit tout clone de plus de 48 heures, avec exception explicite et nominative. Sans ça, le pool sature en trois mois, et il saturera un vendredi.

Voilà la partie que les articles sur le branching évitent, parce qu'elle n'est pas amusante.

Une branche de production contient les données de production. Vraies adresses, vrais emails, vrais numéros de téléphone, parfois vrais IBAN. Cloner la prod, c'est multiplier par le nombre de développeurs le nombre de copies de données personnelles, en les déplaçant vers des environnements où le contrôle d'accès est plus lâche, les logs plus bavards et les sauvegardes moins pilotées.

Le RGPD ne s'arrête pas à la porte de la préproduction. Et le raccourci habituel ne fonctionne pas : la pseudonymisation n'est pas l'anonymisation. La CNIL est nette là-dessus, l'anonymisation rend la réidentification impossible et irréversible, ce qui fait sortir la donnée du champ du règlement ; la pseudonymisation est réversible, c'est une mesure de sécurité à l'intérieur du règlement, pas une sortie. Remplacer un nom par un identifiant en gardant la table de correspondance quelque part ne vous exonère de rien.

La conséquence architecturale est nette. Le clone brut de la prod n'est jamais l'environnement de développement. Le pipeline correct comporte une étape intermédiaire :

1. Snapshot de la production.
2. Clone technique, isolé, accessible uniquement à l'automate.
3. Traitement d'anonymisation sur ce clone : remplacement des identités, brouillage des identifiants bancaires, réduction des données de santé, tout en conservant les volumétries et les distributions.
4. Snapshot du résultat anonymisé. C'est celui-là, et lui seul, qui sert de parent aux branches des développeurs et de la CI.

L'étape 3 coûte du temps de traitement, une fois par nuit, pas une fois par clone. Le surcoût est marginal comparé au risque. Les principes de tenue des registres et de minimisation applicables ici sont détaillés dans notre article sur la conformité RGPD côté infrastructure.

Un dernier point, purement ops : ce pipeline doit être vérifié par un test automatisé, pas par une revue humaine. Une assertion qui échoue si une colonne email du snapshot public contient encore un domaine réel, dans le même esprit que les contrôles d'infrastructure avec Testinfra. Le jour où quelqu'un ajoute une table contacts_v2 sans la déclarer dans le script d'anonymisation, c'est ce test qui doit hurler, pas un client.

Le database branching n'est pas une technologie neuve, c'est un assemblage de briques matures qu'on avait juste pris l'habitude de ne pas utiliser ensemble. Si vos données sont sur ZFS ou sur LVM thin, vous avez déjà tout ce qu'il faut, et vous n'avez pas besoin de migrer votre base vers un SaaS pour obtenir 90 % du bénéfice.

L'ordre d'implémentation qui marche : d'abord le snapshot nocturne fiable, ensuite l'anonymisation validée par test automatisé, ensuite seulement l'exposition du clonage aux développeurs, et le TTL dès la première branche. Faire l'inverse, c'est-à-dire donner le clonage aux équipes en promettant de traiter l'anonymisation plus tard, se termine invariablement de la même façon : ça ne sera jamais fait.

Et une évidence qui n'en est pas une : le clonage n'est pas de la sauvegarde. Un clone vit dans le même pool que l'original, sur les mêmes disques. Il ne survit ni à une perte de baie ni à un DROP TABLE malheureux propagé par un snapshot trop récent. La stratégie de restauration reste un chantier distinct, avec du PITR outillé par pgBackRest et des restaurations réellement testées.

Monter ce dispositif proprement demande un socle de stockage dimensionné, une politique de rétention pensée et une supervision du pool qui alerte avant la saturation, pas après. C'est le genre de chaîne qu'on installe et qu'on tient sur les infrastructures qu'on opère dans le DC Fullsave de Toulouse et sur le site TDF de Bordeaux. Si vos développeurs travaillent encore sur des fixtures ou sur des dumps de la semaine dernière, on peut cadrer et opérer la mise en place, anonymisation comprise.

• Instantly Copy TB-Size Datasets: The Magic of Copy-on-Write, Neon : démonstration sur un jeu de données de 1 To et explication du référencement de pages sans recopie.
• zfsconcepts(7), documentation OpenZFS : sémantique des clones, dépendance implicite au snapshot parent, absence de consommation d'espace à la création.
• lvmthin(7), page de manuel Linux : partage de blocs entre volumes fins et snapshots, syntaxe de création, comportement et délai de 60 secondes quand le pool est plein.
• Database Lab Engine, dépôt du projet : implémentation open source du thin cloning PostgreSQL sur ZFS ou LVM, avec le chiffre de 1 TiB cloné en une dizaine de secondes.
• L'anonymisation de données personnelles, CNIL : distinction entre anonymisation irréversible et pseudonymisation, et conséquences sur le champ d'application du RGPD.