Checkpoint zpool ZFS : le bouton d’annulation d’urgence (aux bords tranchants)

octobre 18, 2025 • février 3, 2026 • Lecture : 28 min • Views: 7

Cet article vous a aidé ?

Il existe deux types d’ingénieurs de stockage : ceux qui ont déjà eu besoin d’un rapport d’urgence pour revenir en arrière, et ceux qui n’en ont pas encore eu besoin. ZFS zpool checkpoint est ce rapport d’urgence : un point d’annulation au niveau du pool qui peut ramener l’état sur disque du pool à un instant précis. Ce n’est pas une sauvegarde. Ce n’est pas un snapshot. Ce n’est même pas particulièrement indulgent. Mais dans la bonne fenêtre, il peut transformer une erreur critique de carrière en un simple ticket embarrassant.

Si vous traitez les checkpoints comme une « sécurité gratuite », vous finirez par découvrir leur tour favori : faire disparaître de l’espace au moment précis où vous en avez le plus besoin. C’est un outil opérationnel, pas une couverture de confort. Parlons de son fonctionnement, de ses usages, des risques, et de la manière de l’utiliser en production sans devenir une anecdote.

Ce qu’est un checkpoint zpool (et ce qu’il n’est pas)

Un checkpoint de pool ZFS est un marqueur spécial stocké dans les métadonnées du pool qui vous permet de ramener l’ensemble du pool à l’état exact sur disque au moment où le checkpoint a été pris. Ce n’est pas « restaurer quelques fichiers ». Ce n’est pas « revenir sur un dataset ». C’est tout le pool : datasets, snapshots, pointeurs de blocs, allocations — tout.

Les checkpoints se comprennent mieux comme un « bouton rembobiner au niveau du pool » qui s’appuie sur la nature copy-on-write (CoW) de ZFS. Après avoir créé un checkpoint, ZFS doit préserver l’ancien état pour pouvoir le reconstruire. Cela signifie que des blocs auparavant libres ne peuvent plus être réutilisés s’ils sont nécessaires pour maintenir la cohérence du checkpoint. La conséquence pratique est brutale : un checkpoint peut bloquer de l’espace. Sur un pool actif, cet espace bloqué peut croître rapidement, et il croît de la pire manière possible : silencieusement, jusqu’à ce que ça ne soit plus silencieux.

Ce que c’est

Un point de retour au niveau du pool pour les métadonnées et les données de l’ensemble du pool.
Un seul checkpoint à la fois (par pool), pas une pile illimitée.
Un outil tactique pour les opérations risquées : mises à niveau de pool, remplacement d’appareils en chorégraphie, modifications des fonctionnalités sur disque, refontes majeures.

Ce que ce n’est pas

Ce n’est pas une sauvegarde. Si le pool meurt, le checkpoint meurt avec lui.
Ce n’est pas un snapshot de dataset. Les snapshots sont par dataset et peuvent être envoyés/reçus ; les checkpoints ne le peuvent pas.
Ce n’est pas sélectif. Vous ne pouvez pas revenir en arrière sur un dataset et laisser les autres « tels quels ».

Première blague (comme promis, courte) : Un checkpoint, c’est comme « annuler » dans un éditeur de texte — sauf qu’il annule aussi les changements de votre collègue, ceux du pipeline CI, et vos deux dernières heures de bon sens.

Pourquoi les checkpoints existent : bref historique et faits

Les checkpoints semblent être une commodité moderne, mais ils trouvent leurs racines dans des vérités anciennes de ZFS : les métadonnées sont sacrées, et le CoW est à la fois un super-pouvoir et une responsabilité. Voici quelques faits et points de contexte qui expliquent pourquoi les checkpoints existent et pourquoi ils sont conçus ainsi.

La promesse originale de ZFS (milieu des années 2000) était « intégrité des données de bout en bout », et le CoW est un mécanisme central : les nouvelles écritures n’écrasent pas les anciens blocs ; elles allouent de nouveaux blocs puis basculent les pointeurs de façon atomique.
Les flags de fonctionnalité du pool ont évolué au fur et à mesure que ZFS a quitté son écosystème d’origine et s’est diffusé. Certaines fonctionnalités ne sont « actives » qu’une fois utilisées ; d’autres changent la manière dont les structures sur disque se comportent. Revenir en arrière après activation ou utilisation de fonctionnalités peut être compliqué.
zpool upgrade faisait davantage peur quand l’activation des fonctionnalités était moins transparente pour les opérateurs. Les checkpoints sont arrivés comme filet de sécurité pour les moments « j’ai mis à jour et je le regrette maintenant ».
Les snapshots sont bon marché jusqu’à un certain point : à mesure que les snapshots se multiplient, les opérateurs apprennent que « bon marché » se réfère aux métadonnées, pas aux blocs épinglés à vie sur un dataset à fort turnover. Les checkpoints suivent la même physique — mais à l’échelle du pool.
La comptabilité d’espace dans ZFS est subtile. « df indique beaucoup de libre » n’est pas équivalent à « ZFS peut allouer ». Les checkpoints ajoutent une autre raison pour laquelle ces chiffres peuvent diverger.
La forte fragmentation est survivable, mais une forte fragmentation quand on est proche du plein est là où les pools deviennent instables en pratique (lent, sujet aux pannes opérationnelles). Les checkpoints peuvent vous pousser plus près de ce précipice.
La limite d’un checkpoint est volontaire : le pool doit déjà préserver l’état antérieur ; empiler plusieurs états historiques à l’échelle du pool amplifierait l’espace épinglé et la complexité.
L’outillage opérationnel s’est développé autour de la réalité que les changements en production sont désordonnés : remplacement d’appareils, désaccords d’ashift, flags de fonctionnalités, commandes destructrices accidentelles. Les checkpoints existent parce que les humains existent.

Comment fonctionnent les checkpoints en interne

Vous pouvez utiliser les checkpoints en toute sécurité sans lire le code source de ZFS, mais vous avez besoin d’un modèle mental. Voici le modèle qui correspond aux symptômes du monde réel.

Le checkpoint est une « racine de pool sauvegardée »

ZFS a le concept d’un état de pool enraciné dans des structures de métadonnées (pensez à un « uberblock » comme l’un des points d’entrée sur « quel est l’état actuel du pool »). Un checkpoint préserve effectivement une racine antérieure pour que ZFS puisse traverser l’ancien arbre de pointeurs de blocs et reconstruire l’ancienne vue.

Pourquoi l’espace disparaît : les blocs deviennent non réutilisables

Parce que ZFS est CoW, le checkpoint n’a pas besoin de copier le pool entier. Il doit simplement rendre les anciens blocs accessibles. Mais si vous modifiez des données après le checkpoint, ZFS écrit de nouveaux blocs. Les anciens blocs restent référencés par le checkpoint et ne peuvent donc pas être libérés. Si vous supprimez des données après le checkpoint, vous vous sentirez floué : « j’ai supprimé 20 To, pourquoi n’ai-je pas récupéré d’espace ? » Parce que, du point de vue du checkpoint, ces données existent toujours et doivent pouvoir être restaurées.

Le rollback n’est pas magique — c’est une détonation contrôlée

Revenir à un checkpoint jette aux orties tout ce qui s’est passé après : toutes les écritures, toutes les suppressions, tous les changements de dataset, et tout progrès opérationnel ayant touché l’état sur disque. Cela peut aussi interagir avec des fonctionnalités et des opérations sur appareils d’une manière qui exige de la préparation. Le pool revient à sa topologie précédente telle qu’enregistrée à l’heure du checkpoint, pas à l’état que vous souhaiteriez.

Les bords tranchants

Pools presque pleins : un checkpoint peut vous basculer en condition « plus d’espace » plus vite que vous ne pouvez réagir.
Pools très actifs : le churn épingle des blocs rapidement ; le « coût » d’un checkpoint peut exploser en quelques heures.
Coordination humaine : il faut traiter une période avec checkpoint comme une fenêtre de gel des changements pour certaines actions, sinon vous créerez des mines anti-personnel pour le rollback.

Deuxième blague (également courte) : Utiliser un checkpoint sans surveillance, c’est comme emprunter un parachute sans vérifier les sangles — techniquement vous êtes plus en sécurité, jusqu’à ce que la physique donne son avis.

Quand utiliser un checkpoint (et quand pas)

Bonnes utilisations

1) Avant un changement risqué global au pool que vous ne pouvez pas facilement annuler. Exemples : activer une fonctionnalité qui change l’utilisation du format sur disque, effectuer une mise à niveau de pool dans un environnement où un rollback pourrait être exigé, ou réaliser une séquence inhabituelle d’opérations sur des dispositifs.

2) Avant une opération chirurgicale où « annuler les 30 dernières minutes » importe. Pensez à une fenêtre de maintenance où vous exécuterez des commandes qui peuvent briquer la config du pool en cas d’erreur de frappe.

3) Avant une expérience sur un pool non répliqué. Parfois vous avez un pool de labo qui se comporte comme la prod, et vous avez besoin d’un seul « rembobinage » sûr.

Mauvaises utilisations

1) En remplacement de sauvegardes ou de réplication. Si le pool est mort, le checkpoint est mort aussi.

2) Comme filet de sécurité de longue durée. Laisser un checkpoint « juste au cas où » pendant une semaine est une manière classique de découvrir que votre pool peut manquer d’espace alors que vos tableaux de bord semblent encore corrects.

3) Sur des pools déjà limités en espace libre. Si vous manquez de marge, un checkpoint transforme « serré » en « fragile ». Vous pouvez quand même le faire, mais votre plan doit inclure une surveillance active, une échéance stricte et un chemin d’abandon rapide (supprimer le checkpoint).

Règle générale

Si vous ne seriez pas à l’aise d’opérer avec effectivement moins d’espace libre que vous en avez maintenant, ne créez pas de checkpoint sans d’abord créer cette marge. Le checkpoint lui-même ne consomme pas forcément beaucoup d’espace immédiatement ; il restreint votre capacité à récupérer de l’espace en libérant des blocs.

Tâches pratiques : commandes, sorties, interprétation

Ci-dessous se trouvent de vraies tâches opérationnelles que vous pouvez exécuter sur un système Linux + OpenZFS typique. Certaines sorties varient selon la version, les fonctionnalités du pool et la plateforme, mais l’intention et l’interprétation restent. Les commandes partent du principe que le pool s’appelle tank.

Tâche 1 : Confirmer l’état du pool avant toute action

cr0x@server:~$ sudo zpool status -xv tank
pool 'tank' is healthy

Interprétation : Si le pool n’est pas sain, n’ajoutez pas la « complexité checkpoint » à une situation déjà instable. Corrigez les défauts, terminez les resilver, et adressez les erreurs d’abord.

Tâche 2 : Enregistrer un état « avant » pour votre ticket de changement

cr0x@server:~$ date -Is
2025-12-25T10:18:44+00:00
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:19 with 0 errors on Thu Dec 19 03:10:14 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0

errors: No known data errors

Interprétation : Sauvegardez cette sortie avec le dossier de changement. En réponse à incident, la différence entre « on pense que tout allait bien » et « voici l’état à 10:18 UTC » représente des heures.

Tâche 3 : Vérifier l’espace libre et les signaux de risque de fragmentation

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,capacity,fragmentation,health tank
NAME  SIZE  ALLOC   FREE  CAP  FRAG  HEALTH
tank  72T   58.2T  13.8T  80%   41%  ONLINE

Interprétation : 80 % d’occupation avec 41 % de fragmentation est gérable, mais ce n’est pas « beaucoup ». Un checkpoint peut faire en sorte que les suppressions ne redonnent pas d’espace. Si vous êtes déjà au-dessus d’environ ~85–90 % de capacité, considérez un checkpoint comme dangereux.

Tâche 4 : Vérifier si un checkpoint existe déjà

cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE       SOURCE
tank  checkpoint  -           -

Interprétation : Une valeur - signifie qu’aucun checkpoint n’est présent. Si vous voyez un horodatage ou une valeur non vide, vous en avez déjà un et vous devez décider de le garder, de le supprimer ou d’y revenir.

Tâche 5 : Créer un checkpoint (et noter précisément l’heure)

cr0x@server:~$ sudo zpool checkpoint tank
cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE                        SOURCE
tank  checkpoint  2025-12-25T10:22:11+00:00    -

Interprétation : Cet horodatage est votre « point de non-retour » pour tout ce qui se passe après. Notez-le là où des humains le verront, pas seulement dans l’historique du shell.

Tâche 6 : Observer le comportement de l’espace bloqué via une libération de données (le test « pourquoi l’espace libre n’a-t-il pas augmenté ? »)

cr0x@server:~$ sudo zfs destroy -r tank/tmp/testdata
cr0x@server:~$ sudo zpool list -o name,alloc,free,capacity tank
NAME  ALLOC   FREE  CAP
tank  58.2T  13.8T  80%

Interprétation : Si alloc/free bougent à peine après une grosse suppression et que vous avez un checkpoint, vous avez appris la vérité opérationnelle : les suppressions n’achètent pas forcément de marge tant que le checkpoint existe.

Tâche 7 : Vérifier la vue d’espace au niveau des datasets pour éviter la « panique df »

cr0x@server:~$ df -h /tank
Filesystem      Size  Used Avail Use% Mounted on
tank            72T   58T   14T  81% /tank

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  58.2T  12.9T   256K  /tank

Interprétation : df et zfs list concordent souvent au niveau supérieur, mais pendant une période de checkpoint vous pouvez rencontrer des situations où le comportement applicatif suggère « manque d’espace » plus tôt que prévu parce que les réalités d’allocation de ZFS deviennent plus serrées que ce que l’espace utilisateur attend.

Tâche 8 : Confirmer que vous n’avez pas accidentellement « activé » quelque chose que vous ne pouvez pas revenir

cr0x@server:~$ sudo zpool get all tank | egrep 'feature@|compatibility|readonly'
tank  readonly                off                    default
tank  compatibility           off                    default
tank  feature@async_destroy   enabled                local
tank  feature@spacemap_histogram  active             local
tank  feature@extensible_dataset  enabled            local

Interprétation : « Enabled » signifie disponible ; « active » signifie utilisé dans l’état sur disque. Un checkpoint peut vous aider à revenir en arrière pour certaines catégories de « je change d’avis », mais l’activation de fonctionnalités peut compliquer l’interopérabilité et les chemins de rétrogradation. N’improvisez pas — inspectez.

Tâche 9 : Simuler la décision de rollback en énumérant « ce qui serait perdu »

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/home@autosnap_2025-12-25_0900  Thu Dec 25 09:00 2025
tank/home@autosnap_2025-12-25_1000  Thu Dec 25 10:00 2025
tank/db@prechange_2025-12-25_1015     Thu Dec 25 10:15 2025
tank/db@postchange_2025-12-25_1030    Thu Dec 25 10:30 2025
tank/logs@hourly_2025-12-25_1100      Thu Dec 25 11:00 2025

Interprétation : Les snapshots créés après le checkpoint seront perdus si vous revenez en arrière. Prenez votre décision de rollback en connaissance de cause et avertissez les parties prenantes : « vous perdrez tout depuis 10:22 ».

Tâche 10 : Revenir au checkpoint (le gros marteau)

cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import tank
cr0x@server:~$ sudo zpool checkpoint -r tank

Interprétation : Le rollback est disruptif et doit être traité comme une opération de maintenance. Export/import n’est pas toujours strictement requis pour un rollback, mais en pratique c’est une manière propre de s’assurer que les services sont arrêtés, que les montages sont quiescents, et que vous ne revenez pas en arrière sous des écritures actives. Après le rollback, le checkpoint est généralement effacé parce que vous y êtes revenu.

Tâche 11 : Supprimer le checkpoint (s’engager dans le nouveau monde et récupérer la réutilisation)

cr0x@server:~$ sudo zpool checkpoint -d tank
cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE  SOURCE
tank  checkpoint  -      -

Interprétation : C’est l’étape « c’est fini, on garde les changements ». Opérationnellement, supprimer le checkpoint est souvent l’action la plus importante — car elle restaure la réutilisation normale de l’espace. Fixez une échéance pour cette étape quand vous créez le checkpoint.

Tâche 12 : Surveiller la pression d’espace tant qu’un checkpoint existe

cr0x@server:~$ watch -n 5 'zpool list -o name,alloc,free,capacity,fragmentation tank; echo; zpool get checkpoint tank'
Every 5.0s: zpool list -o name,alloc,free,capacity,fragmentation tank; echo; zpool get checkpoint tank

NAME  ALLOC   FREE  CAP  FRAG
tank  60.1T  11.9T  83%  44%

NAME  PROPERTY    VALUE                        SOURCE
tank  checkpoint  2025-12-25T10:22:11+00:00    -

Interprétation : Si alloc monte pendant que votre changement est en cours, vous pouvez épingler d’anciens blocs tout en en créant de nouveaux. Une capacité qui augmente durant une fenêtre de checkpoint est normale ; une capacité qui s’approche du précipice est une raison d’abandonner tôt en supprimant le checkpoint ou en limitant le churn.

Tâche 13 : Identifier les gros écrivains pendant la fenêtre de checkpoint

cr0x@server:~$ sudo zpool iostat -v tank 5 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        60.1T  11.9T      5    802  1.20M   210M
  raidz1-0                  60.1T  11.9T      5    802  1.20M   210M
    sda                         -      -      1    270   410K  70.2M
    sdb                         -      -      2    265   420K  69.1M
    sdc                         -      -      2    267   370K  70.7M
--------------------------  -----  -----  -----  -----  -----  -----

Interprétation : Un fort débit d’écriture pendant la fenêtre de checkpoint signifie que vous accumulez des données du « nouveau monde » tout en épinglant l’« ancien monde ». Si vous voulez que le checkpoint reste bon marché, minimisez le churn d’écriture.

Tâche 14 : Valider les points de montage et la santé des datasets après suppression/rollback

cr0x@server:~$ sudo zfs mount -a
cr0x@server:~$ sudo zfs list -o name,mounted,available,used,mountpoint tank | head
NAME       MOUNTED  AVAIL  USED  MOUNTPOINT
tank       yes      12.9T  60.1T /tank
tank/home  yes      12.9T   8.4T /tank/home
tank/db    yes      12.9T  44.0T /tank/db

Interprétation : Après un rollback, ne supposez pas que les services redémarreront proprement. L’état des montages et la disponibilité des datasets sont les premiers contrôles « le stockage est-il sain ? » avant de relancer des bases de données ou des hyperviseurs.

Playbook de diagnostic rapide : quand le pool semble “bizarre”

Ceci est la checklist « il est 02:00 et quelque chose cloche ». L’objectif est d’identifier si le checkpoint contribue au symptôme, et si vous faites face à un goulot d’étranglement d’espace, d’I/O ou de fragmentation.

Première étape : établir si un checkpoint existe et depuis combien de temps

cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE                        SOURCE
tank  checkpoint  2025-12-25T10:22:11+00:00    -

Si vous avez un checkpoint : considérez les anomalies d’espace comme « checkpoint jusqu’à preuve du contraire ». Si vous n’en avez pas, procédez au triage ZFS habituel.

Deuxième étape : vérifier la marge réelle du pool et les signaux d’alerte

cr0x@server:~$ sudo zpool list -o name,alloc,free,capacity,fragmentation,health tank
NAME  ALLOC   FREE  CAP  FRAG  HEALTH
tank  60.1T  11.9T  83%  44%   ONLINE

Ce que vous recherchez : une capacité qui monte vers 90 % pendant qu’un checkpoint existe ; une fragmentation qui augmente ; un état health différent de ONLINE.

Troisième étape : identifier si vous êtes lié par IOPS, bande passante, ou bloqué autrement

cr0x@server:~$ sudo zpool iostat -v tank 2 5
cr0x@server:~$ sudo zpool status -v tank

Interprétation :

Écritures élevées + peu d’espace libre : vous vous dirigez vers une « défaillance d’allocation ». Décidez vite : supprimer le checkpoint, arrêter les écrivains, ou ajouter de l’espace.
Symptômes de latence de lecture : le checkpoint n’est généralement pas la cause directe, mais il corrèle avec des périodes de fort churn et de fragmentation, ce qui peut amplifier la latence.
Erreurs ou resilvering : ne revenez pas en arrière de façon légère pendant une activité de défaillance d’appareil. Stabilisez d’abord, sauf si le rollback est la seule option.

Quatrième étape : vérifier si les suppressions « fonctionnent »

cr0x@server:~$ sudo zpool list -o alloc,free,capacity tank
ALLOC   FREE  CAP
60.1T  11.9T  83%

Interprétation : Si vous supprimez de gros datasets et que free ne bouge pas pendant une fenêtre de checkpoint, n’enchaînez pas les suppressions dans la panique. Vous ne gagnez pas de piste ; vous rendez juste le monde post-checkpoint plus étrange.

Trois mini-récits du monde de l’entreprise

1) L’incident causé par une mauvaise hypothèse

Ils avaient une couche de stockage pour une ferme de virtualisation sur un grand pool ZFS. L’équipe stockage planifiait un changement de flag de fonctionnalité et, pour être prudente, a créé un checkpoint « au cas où ». La fenêtre de maintenance a été calme. Le changement a semblé correct. Tout le monde est rentré chez soi.

Deux jours plus tard, des alertes sont arrivées : des VM échouaient parfois lors des écritures, puis une cascade de comportements en « système de fichiers en lecture seule » chez les invités. L’astreinte voyait « 15 To libre » dans les tableaux de bord et a supposé que ce ne pouvait pas être un problème d’espace. Ils ont pourchassé des fantômes : multipath, firmware HBA, un SSD SLOG suspect. Tout semblait en grande partie normal.

Ce qui s’est réellement passé était plus simple et plus cruel. Pendant ces deux jours, le pool a churné : images de VM, logs, churn de bases de données dans les invités. Le checkpoint a épinglé une quantité croissante d’anciens blocs, et les suppressions/reclaims n’aidaient pas. Le pool n’était pas hors d’espace d’après la métrique naïve « free », mais il devenait hostile pour les allocations : la fragmentation augmentait, les segments libres de metaslab devenaient moins utilisables, et les opérations nécessitant des allocations assez contiguës échouaient sous charge.

La mauvaise hypothèse était que le checkpoint est « gratuit jusqu’à ce que vous reveniez ». Ce n’est pas le cas. C’est une contrainte vivante sur la réutilisation de l’espace. Ils ont supprimé le checkpoint, et le comportement de l’espace est revenu à la normale en moins d’une heure. L’action post-mortem a été claire : les checkpoints doivent avoir un propriétaire et une durée d’expiration, et la surveillance doit alerter sur un « checkpoint plus vieux que X heures » comme elle alerte sur un vdev dégradé.

2) L’optimisation qui s’est retournée contre eux

Une équipe plateforme a décidé de réduire le risque de maintenance en standardisant un flux : « checkpoint avant chaque changement de stockage ». Ça avait l’air mature. Le calendrier de changements s’est intensifié, donc les checkpoints sont devenus fréquents. Quelqu’un l’a même scripté : quand un ticket de changement est approuvé, l’automatisation crée le checkpoint et publie l’horodatage dans le fil de discussion.

Puis la contrepartie est arrivée. Ils utilisaient le même pool pour des bases de données critiques et une grosse charge analytique qui réécrivait des tonnes de données quotidiennement. Lors d’un remplacement d’appareil de routine, le checkpoint a été créé et laissé en place plus longtemps que prévu parce que le fournisseur a expédié le mauvais modèle de disque et ils ont reporté la suite des opérations. Pendant ce temps, l’analytique continuait d’écraser le pool.

Le pool n’a pas planté. Il a fait pire : il a ralenti d’une manière pas immédiatement attribuable. La latence a grimpé, les fenêtres de réplication ont glissé, et l’équipe base de données a commencé à limiter leur propre charge pour garder la latence acceptable. L’équipe stockage a regardé le checkpoint et a pensé : « on n’a pas fait de rollback, donc ça ne devrait pas poser problème ». Mais ça posait problème parce que le checkpoint faisait porter au pool deux réalités à la fois. Les écritures continuaient d’allouer des blocs nouveaux tandis que les anciens restaient épinglés. Les maps d’espace se sont complexifiées, la fragmentation a augmenté, et le pool s’est comporté comme s’il était plus vieux et plus plein qu’il ne l’était réellement.

La solution a été culturelle : les checkpoints sont devenus un outil utilisé uniquement pour les changements où le rollback a une valeur réelle, pas pour chaque opération routinière. Ils ont remplacé « checkpoint partout » par « checkpoint quand le rollback change significativement le risque », et l’ont associé à des snapshots courts pour les changements mineurs. L’optimisation a échoué car elle optimisait pour le mauvais indicateur : la sécurité perçue, pas la stabilité opérationnelle.

3) La pratique ennuyeuse mais correcte qui a sauvé la situation

Un système proche des finances avait un processus de changement strict : chaque modification de stockage exigeait une checklist pré-vol, une fenêtre de maintenance, et un « plan de réversion » rédigé en langage clair. C’était assez ennuyeux pour que les ingénieurs se plaignent — en privé, parce que les systèmes financiers gagnent souvent les discussions en restant en place.

Lors d’une mise à niveau planifiée du pool, ils ont créé un checkpoint et immédiatement ajouté un rappel interne : « Supprimer le checkpoint d’ici la fin de la fenêtre sauf si un rollback est requis ». Ils ont aussi mis un garde-fou dans la surveillance : si un checkpoint existe depuis plus de quatre heures, on appelle l’astreinte et le propriétaire du changement. Ce n’était pas sophistiqué, juste une propriété explicite et un minuteur.

À mi-parcours, un ingénieur stockage a remarqué un service qui se comportait étrangement. Pas de panne, juste « décalé ». Parce que le plan de réversion était déjà écrit, ils n’ont pas improvisé. Ils ont arrêté les services dépendants, exporté le pool, ré-importé proprement, sont revenus au checkpoint, et ont rétabli le service. La revue post-incident a trouvé une interaction de configuration qui aurait été pénible à démêler manuellement.

Le sauvetage n’a pas été dû au checkpoint seul — c’était la discipline autour : mettre les écritures en pause, avoir une échéance, et traiter le rollback comme une opération planifiée plutôt que comme une réaction émotionnelle. La pratique était ennuyeuse parce qu’elle était correcte. L’ennui est sous-estimé en stockage.

Erreurs courantes (avec symptômes et correctifs)

Erreur 1 : Créer un checkpoint sur un pool presque plein

Syndromes : la capacité du pool monte rapidement ; les suppressions ne récupèrent pas d’espace ; les applications lancent ENOSPC ou « disque plein » malgré les attentes ; la fragmentation augmente.

Correctif : si le rollback n’est plus nécessaire, supprimez le checkpoint. Si le rollback pourrait encore être nécessaire, mettez en pause les charges à fort churn et ajoutez de la marge (vdevs supplémentaires ou migration temporaire). En cas de crise, priorisez la réduction du churn plutôt que la suppression de données — les suppressions sont de toute façon épinglées.

Erreur 2 : Laisser un checkpoint « au cas où »

Syndromes : pression d’espace lente et persistante qui ne corrèle pas avec la croissance visible des données ; dégradation de performance à long terme sur les charges d’écritures aléatoires.

Correctif : appliquez une politique d’expiration. Opérationnellement : chaque checkpoint doit avoir un propriétaire humain, une date de suppression, et une surveillance qui alerte sur l’âge.

Erreur 3 : Supposer que les checkpoints se comportent comme des snapshots

Syndromes : quelqu’un s’attend à restaurer un seul dataset ; quelqu’un essaie de « envoyer » un checkpoint ; confusion sur ce qui sera perdu.

Correctif : éduquez avec une règle : les snapshots sont par dataset ; les checkpoints sont globaux au pool. Utilisez des snapshots pour « je veux récupérer mon répertoire ». Utilisez des checkpoints pour « je veux récupérer mon pool ».

Erreur 4 : Revenir en arrière sans mettre les écritures en pause

Syndromes : les services reviennent corrompus au niveau applicatif ; les bases de données nécessitent une recovery ; les VM peuvent avoir des disques incohérents ; blâme confus envers ZFS.

Correctif : traitez le rollback comme une restauration d’image du stockage : stoppez les services, videz les buffers, démontez si possible, exportez/importez pour garantir l’absence d’écrivains. Ensuite faites le rollback. ZFS fera ce que vous lui demandez ; les applications feront ce que la physique permet.

Erreur 5 : Oublier que le rollback supprime le progrès opérationnel

Syndromes : un remplacement de disque « disparaît », un changement de topologie est annulé, ou une migration soigneusement planifiée est inversée.

Correctif : documentez précisément les actions qui ont eu lieu après le checkpoint. Si vous avez remplacé un disque après le checkpoint, revenir en arrière peut restaurer la topologie précédente, ce qui peut semer la confusion lors des opérations ultérieures. Planifiez les étapes de rollback, pas seulement la commande.

Erreur 6 : Interpréter « espace libre » comme « espace allouable » sous pression

Syndromes : « nous avons encore des téraoctets libres » mais les allocations échouent ; la performance chute ; les opérations sur les métadonnées ralenties ; pics de latence étranges.

Correctif : surveillez la capacité du pool et la fragmentation, et conservez plus de marge que vous ne le pensez nécessaire — surtout pendant une fenêtre de checkpoint. Envisagez de limiter temporairement les écrivains et assurez-vous que l’autotrim (là où approprié) ne masque pas un comportement au niveau des dispositifs.

Listes de contrôle / plan étape par étape

Checklist A : Créer un checkpoint en toute sécurité (production)

Confirmer la santé : pool ONLINE, pas de resilver en cours sauf raison très spécifique.
Confirmer la marge : vérifier capacité et fragmentation ; si vous êtes au-dessus des seuils confortables, créez de la marge d’abord.
Définir le périmètre du rollback : ce que le rollback annulera exactement ? Écrivez-le dans le dossier de changement.
Fixer une heure d’expiration : « supprimer d’ici la fin de la fenêtre » est une valeur par défaut raisonnable. Les fenêtres plus longues nécessitent justification et surveillance.
Créer le checkpoint : consigner l’horodatage.
Surveiller pendant la fenêtre : observer alloc/free et les débits d’écriture. Si la pression d’espace monte, décidez tôt.
Terminer la fenêtre avec intention : soit supprimer (commit), soit revenir (revert). Ne laissez pas l’état ambigu.

Checklist B : Supprimer un checkpoint (l’étape la plus oubliée)

Vérifier que les services sont sains et que le changement est accepté.
Confirmer que le checkpoint existe.
Le supprimer.
Vérifier qu’il a disparu.
Surveiller le comportement de l’espace libre du pool durant l’heure suivante : les suppressions devraient de nouveau récupérer de l’espace et la croissance de l’alloc devrait refléter la réalité.

cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE                        SOURCE
tank  checkpoint  2025-12-25T10:22:11+00:00    -

cr0x@server:~$ sudo zpool checkpoint -d tank
cr0x@server:~$ sudo zpool get checkpoint tank
NAME  PROPERTY    VALUE  SOURCE
tank  checkpoint  -      -

Checklist C : Revenir en arrière en toute sécurité (quand vous le pensez vraiment)

Déclarer l’impact : tout ce qui se passe après l’horodatage du checkpoint sera perdu.
Quiescer : arrêter les applications, démonter ou remonter en lecture seule si possible.
Export/import : garantit un état d’import propre et cohérent sans écrivains actifs.
Rollback : exécuter le rollback du checkpoint.
Valider : monter les datasets, vérifier la santé du pool, puis remonter les services dans un ordre contrôlé.

cr0x@server:~$ sudo systemctl stop libvirtd
cr0x@server:~$ sudo systemctl stop postgresql
cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import tank
cr0x@server:~$ sudo zpool checkpoint -r tank
cr0x@server:~$ sudo zpool status -xv tank
pool 'tank' is healthy

FAQ

1) Un checkpoint zpool est-il la même chose qu’un snapshot ZFS ?

Non. Les snapshots sont par dataset et permettent de restaurer ou cloner l’état d’un dataset. Un checkpoint est un point de retour au niveau du pool qui rembobine tout ce qui se trouve sur le pool, y compris tous les datasets et leurs snapshots.

2) Puis-je avoir plusieurs checkpoints ?

Typiquement non : un checkpoint à la fois par pool. La limitation vise en partie à éviter que l’espace épinglé et la complexité ne deviennent ingérables.

3) La création d’un checkpoint consomme-t-elle immédiatement de l’espace ?

En général non, elle n’alloue pas une énorme quantité immédiatement. Le coût apparaît lorsque vous modifiez des données ensuite : les anciens blocs qui seraient normalement libérés restent épinglés pour que le checkpoint puisse être reconstruit.

4) Pourquoi l’espace libre n’a-t-il pas augmenté après que j’ai supprimé des téraoctets ?

Parce que le checkpoint référence encore les anciens blocs. Du point de vue du checkpoint, les données existent toujours. Supprimer le checkpoint lève cette contrainte et permet la réutilisation normale de l’espace.

5) Puis-je « envoyer » un checkpoint vers une autre machine comme un snapshot ?

Non. Si vous avez besoin de portabilité, utilisez des snapshots de dataset avec zfs send/zfs receive, ou répliquez le pool par d’autres moyens. Un checkpoint n’est pas un mécanisme de réplication.

6) Dois-je créer un checkpoint avant `zpool upgrade` ?

Parfois. Si vous êtes dans un environnement où un rollback pourrait être exigé et que vous disposez de suffisamment de marge, cela peut être une précaution raisonnable. Mais la meilleure « sécurité de mise à niveau » reste : tester en staging, comprendre les flags de fonctionnalités, et avoir de vraies sauvegardes/réplication. Un checkpoint est un undo tactique, pas une stratégie.

7) Un checkpoint me protège-t-il contre une défaillance matérielle pendant le changement ?

Non. Un checkpoint ne crée pas une seconde copie de vos données. Si vous perdez le pool ou suffisamment de dispositifs pour le rendre indisponible, le checkpoint tombe avec lui.

8) Est-il sûr de garder un checkpoint pendant des jours ?

Techniquement ZFS le supporte, mais c’est risqué opérationnellement sur des pools actifs. Vous pariez que les blocs épinglés et la fragmentation ne vous pousseront pas en pression d’espace ou en problèmes de performance. Si vous devez le conserver, surveillez agressivement et fixez une expiration ferme.

9) Le rollback corrige-t-il la corruption au niveau applicatif ?

Il peut annuler des changements au niveau stockage, mais il ne garantit pas la cohérence applicative à moins que vous n’ayez quiescé l’application au moment du checkpoint et au moment du rollback. Les bases de données, VM et systèmes distribués se soucient de l’ordre des écritures et des sémantiques de flush, pas seulement des blocs sur disque.

10) Quelle est la politique la plus simple et sûre pour les checkpoints en production ?

Utilisez-les uniquement pour les changements où un rollback global au pool a une valeur réelle, attachez toujours un propriétaire et une échéance, et par défaut supprimez-les à la fin de la fenêtre de maintenance.

Conclusion

zpool checkpoint est une de ces fonctionnalités qui ressemble à un cadeau jusqu’à ce que vous en découvriez le prix. C’est un undo d’urgence au niveau du pool, propulsé par le CoW, et ça marche — souvent de façon spectaculaire — quand vous l’utilisez pour des fenêtres courtes et contrôlées. Les bords tranchants viennent de la même source que son pouvoir : préserver le passé signifie que le pool ne peut pas réutiliser librement le présent.

Si vous ne retenez que trois choses, retenez-les : (1) un checkpoint n’est pas une sauvegarde, (2) il peut épingler de l’espace et réduire sournoisement votre marge, et (3) le checkpoint le plus sûr est celui qui a un propriétaire écrit, un minuteur, et une décision claire en fin de fenêtre : supprimer ou revenir. En stockage, l’ambiguïté est la façon dont le « temporaire » devient « permanent », et dont le « permanent » devient un incident.