zfs release : Comment supprimer réellement les instantanés « indestructibles »

novembre 23, 2025 • février 3, 2026 • Lecture : 26 min • Views: 9

Cet article vous a aidé ?

Dans ZFS, « instantané impossible à supprimer » signifie généralement « instantané avec une dépendance que vous n’aviez pas remarquée ». ZFS est impitoyablement cohérent : il ne supprimera pas un historique dont quelque chose d’autre a encore besoin — que ce « quelque chose » soit un clone, un tag hold d’un pipeline de sauvegarde, une politique de réplication, ou votre propre décision antérieure de traiter les instantanés comme une poubelle.

Voici un guide de terrain pratique pour faire disparaître ces instantanés en toute sécurité. Nous couvrirons ce qui bloque réellement la suppression, comment le prouver avec des commandes, et comment nettoyer sans transformer un pool sain en catastrophe professionnelle. Je m’appuierai sur les deux vérités ZFS que l’on apprend en production : les données ont toujours un propriétaire, et la facture finit toujours par arriver.

Ce que « impossible à supprimer » signifie réellement dans ZFS

Quand des gens disent qu’ils « ne peuvent pas supprimer un instantané ZFS », le système leur indique généralement l’un de ces cas :

Un hold existe sur l’instantané, donc ZFS refuse de le détruire tant que le hold n’est pas relâché.
Un clone en dépend (un dataset inscriptible créé à partir d’un instantané). ZFS ne supprimera pas l’instantané car il est littéralement l’origine d’un système de fichiers en activité.
L’instantané est « occupé » à cause d’opérations en cours (send/receive, snapshotting, ou quelque chose maintenant des références).
La réplication, les outils de sauvegarde ou les politiques le recréent, donc il semble que la suppression « ne marche pas ».
Vous supprimez la mauvaise chose (par ex., vous avez supprimé un instantané sur la source mais la cible l’a encore ; ou vous avez détruit un bookmark au lieu d’un instantané ; ou le nom de l’instantané contient des caractères spéciaux et votre shell a menti).

Et l’autre plainte courante — « j’ai supprimé des instantanés, mais l’espace n’a pas été libéré » — n’est pas un problème d’« impossible à supprimer ». C’est de la comptabilité. L’espace dans ZFS n’est libéré que lorsque la dernière référence aux blocs disparaît, et ces blocs peuvent encore être référencés par des instantanés plus récents, des clones, ou simplement des données présentes dans le système de fichiers en direct. ZFS est beaucoup de choses, mais ce n’est pas un destructeur magique.

Première blague (comme promis, seulement deux au total) : les instantanés ZFS sont comme des reçus — faciles à accumuler, difficiles à se débarrasser, et vous n’en avez besoin que quand vous avez déjà pris une terrible décision.

Faits intéressants & courte histoire : pourquoi ZFS se comporte ainsi

Un peu de contexte rend ce comportement moins semblable à du sabotage et plus à de l’ingénierie :

Les instantanés ZFS sont des vues en copy-on-write. Pas d’écrasement en place ; les instantanés gardent des références aux anciennes versions des blocs. C’est pourquoi ils sont instantanés et pourquoi ils peuvent « bloquer » de l’espace.
« Impossible à supprimer » est souvent une fonctionnalité. Les holds ont été conçus précisément pour empêcher l’automatisation de supprimer des instantanés nécessaires pour la conformité, les fenêtres de sauvegarde ou l’intégrité de la réplication.
Les clones sont de vrais systèmes de fichiers. Un clone n’est pas une « copie », c’est un dataset qui partage des blocs avec son instantané d’origine. Supprimer l’origine orphelinerait la lignée du clone.
ZFS a été construit pour être son propre gestionnaire de volumes. C’est pourquoi il peut suivre la propriété des blocs à un niveau qui rend les dépendances d’instantanés applicables — et non négociables.
Les instantanés peuvent être « conservés » par des systèmes distants. Avec la réplication, le receveur peut garder des instantanés ou en exiger comme bases incrémentales. Votre « suppression » sur la source ne fait pas oublier la cible.
Le système de propriétés des datasets fait partie du plan de contrôle. Des propriétés comme readonly, canmount et mountpoint changent le comportement sans modifier les données ; les holds et les origines de clone sont des métadonnées de même nature.
L’héritage Solaris se voit. Beaucoup de comportements ZFS (y compris la rigidité autour des invariants) proviennent des attentes du stockage d’entreprise : la correction d’abord, la commodité ensuite.
La destruction est transactionnelle. Les changements ZFS sont atomiques ; quand il refuse de détruire un instantané, il protège un graphe cohérent de références sur disque.
Les bookmarks existent pour une raison. Les bookmarks sont des pointeurs légers vers le groupe de transactions d’un instantané, utilisés pour préserver une base incrémentale sans conserver tous les métadonnées de l’instantané. Les gens les confondent avec des instantanés et se demandent pourquoi l’espace ne change pas.

Mode d’action pour un diagnostic rapide (premier, second, troisième)

Si vous êtes d’astreinte et que le stockage vous sonne, ne vous perdez pas. Faites ceci, dans cet ordre :

1) Confirmez ce qui est « impossible à supprimer » et pourquoi ZFS s’y oppose

Tentez la destruction et lisez l’erreur exacte. ZFS est en général explicite. « snapshot has dependent clones » et « snapshot is held » ne sont pas subtils.

2) Cherchez immédiatement les holds et les dépendances de clones

Les holds et les clones expliquent la majorité des « pourquoi ça ne supprime pas ». Vérifiez les holds avec zfs holds. Vérifiez les clones avec zfs get origin (ou recherche inverse via zfs list -t all et grep).

3) Si l’espace est le problème, trouvez ce qui le consomme réellement

Utilisez usedbysnapshots, usedbydataset et usedbychildren. Si ce sont des instantanés qui consomment l’espace, déterminez quels instantanés sont gros et s’ils sont épinglés par des clones/holds.

4) Si la suppression « marche » mais les instantanés réapparaissent, traquez le créateur

Cela vient généralement d’un cron, d’un timer systemd, d’un appliance de sauvegarde ou d’un outil de réplication qui croit gérer la rétention. Supprimer les symptômes ne guérira pas la maladie.

Mécanismes principaux : holds, clones, datasets occupés et réplication

Holds : le « non » poli

Un hold est un tag sur un instantané qui empêche sa destruction. Un instantané peut avoir plusieurs holds, typiquement un par workflow : « backup », « replication », « legal », « before-upgrade », et l’infâme « temp » qui devient permanent.

Détail opérationnel clé : vous ne « supprimez » pas le hold, vous le relâchez par son nom. S’il y a plusieurs tags de hold, il faut les relâcher tous (ou utiliser des motifs -r prudemment). C’est là que zfs release est votre ami, et aussi l’endroit où vous pouvez vous tirer une balle dans le pied en relâchant un hold attendu par un système de sauvegarde.

Clones : la dépendance silencieuse

Les clones sont des datasets créés à partir d’un instantané. Ils maintiennent l’instantané en vie parce que l’instantané est l’origine du clone. ZFS ne détruira pas l’instantané d’origine tant que vous ne détruisez pas le clone ou que vous ne le « promotez » (rendant le clone indépendant et inversant la direction de la dépendance).

Piège réel : les clones apparaissent dans des endroits inattendus : pipelines CI, environnements « temporaires » de développeurs, templates de virtualisation, actualisations de bases de données de test. Si vous avez de la chance, le clone est nommé honnêtement. Sinon, il s’appelle prod2 et tout le monde fait semblant que ce n’est pas important.

Instantanés occupés et verrous opérationnels

ZFS peut signaler des instantanés comme occupés s’ils sont impliqués dans des opérations en cours. Causes communes :

zfs send/zfs receive en cours
destruction d’instantanés longue durée (surtout avec un grand nombre d’instantanés)
outils qui gardent des références aux datasets ouvertes plus longtemps que prévu

« Occupé » est généralement temporaire, mais dans des environnements désordonnés cela peut devenir un état permanent créé par des boucles d’automatisation.

Réplication et bases incrémentales

Les pipelines de réplication exigent souvent un instantané commun entre la source et la cible pour envoyer des incrémentaux. Certains outils l’imposent en plaçant des holds sur des instantanés jusqu’à ce que la cible confirme la réception, ou en retenant certains instantanés comme « ancres ».

Opérationnellement, vous devez savoir si l’instantané est conservé parce que ZFS le commande (holds/clones) ou parce que votre outillage l’impose (instantanés recréés, politiques de rétention, ou contraintes distantes).

Tâches pratiques : commandes qui résolvent réellement le problème (avec interprétation)

Les tâches suivantes sont écrites comme vous les utiliseriez en console, avec suffisamment d’interprétation pour vous éviter des ennuis. Adaptez les noms de dataset à votre environnement.

Task 1: List snapshots and sort by space impact

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,creation -s used tank/data
NAME                         USED  REFER  CREATION
tank/data@autosnap_2025-12-20  84G  1.2T   Sat Dec 20 03:00 2025
tank/data@autosnap_2025-12-21  91G  1.2T   Sun Dec 21 03:00 2025
tank/data@autosnap_2025-12-22  12G  1.2T   Mon Dec 22 03:00 2025

Interprétation : USED ici signifie « unique à cet instantané compte tenu de tout le reste qui existe ». Si vous chassez l’espace, triez par used et commencez par les plus gros responsables. Si votre liste d’instantanés est énorme, restreignez à un sous-arbre de dataset.

Task 2: Attempt destroy and capture the real error

cr0x@server:~$ sudo zfs destroy tank/data@autosnap_2025-12-21
cannot destroy snapshot tank/data@autosnap_2025-12-21: snapshot is held

Interprétation : Ne devinez pas. La chaîne d’erreur vous dit dans quelle branche de l’arbre de décision vous êtes : held, has dependent clones, busy, etc.

Task 3: Show holds on a snapshot

cr0x@server:~$ sudo zfs holds tank/data@autosnap_2025-12-21
NAME                         TAG        TIMESTAMP
tank/data@autosnap_2025-12-21 backup     Tue Dec 23 01:12 2025
tank/data@autosnap_2025-12-21 replicate  Tue Dec 23 01:13 2025

Interprétation : Deux systèmes différents (ou deux phases d’un même système) ont placé des holds. Vous devez relâcher les deux tags avant que la destruction ne fonctionne. Aussi : ces tags sont des indices — trouvez les propriétaires avant de les retirer.

Task 4: Release a single hold tag with `zfs release`

cr0x@server:~$ sudo zfs release backup tank/data@autosnap_2025-12-21

Interprétation : Cela supprime seulement le hold backup. Si la suppression échoue encore, il y a au moins un autre tag, ou un autre bloqueur complètement différent.

Task 5: Release multiple holds, then destroy

cr0x@server:~$ sudo zfs release backup tank/data@autosnap_2025-12-21
cr0x@server:~$ sudo zfs release replicate tank/data@autosnap_2025-12-21
cr0x@server:~$ sudo zfs destroy tank/data@autosnap_2025-12-21

Interprétation : Clair et explicite vaut mieux que malin. En production, je préfère deux commandes que je peux auditer plutôt qu’une seule commande qui « devrait marcher ».

Task 6: Find clones that depend on a snapshot (origin search)

C’est la façon la plus fiable : cherchez les datasets dont origin correspond à votre instantané.

cr0x@server:~$ zfs get -H -o name,value origin -r tank | grep 'tank/data@autosnap_2025-12-20'
tank/dev-jenkins-workspace  tank/data@autosnap_2025-12-20
tank/vm-templates/ubuntu    tank/data@autosnap_2025-12-20

Interprétation : Ces datasets sont des clones (ou descendants de clones) liés à cet instantané. L’instantané ne mourra pas tant que ceux-ci ne sont pas gérés.

Task 7: Confirm a dataset is a clone and see its origin

cr0x@server:~$ zfs get origin tank/dev-jenkins-workspace
NAME                      PROPERTY  VALUE                         SOURCE
tank/dev-jenkins-workspace origin    tank/data@autosnap_2025-12-20  -

Interprétation : Ce dataset dépend de cet instantané. Vos options : détruire le clone, ou le promouvoir (s’il doit survivre).

Task 8: Destroy a clone (and its children) to unblock snapshot destruction

cr0x@server:~$ sudo zfs destroy -r tank/dev-jenkins-workspace

Interprétation : -r détruit le dataset et tous ses descendants. C’est correct pour les workspaces CI et datasets éphémères de dev. Ce n’est pas correct pour quelque chose que quelqu’un a commencé à traiter comme de la production en douce.

Task 9: Promote a clone to remove dependency on the origin snapshot

cr0x@server:~$ sudo zfs promote tank/vm-templates/ubuntu

Interprétation : La promotion inverse la dépendance pour que le clone devienne la lignée « parent ». Après promotion, l’instantané original peut devenir destructible (sous réserve d’autres clones/holds). La promotion change les relations d’instantanés ; traitez-la comme une demande de changement, pas comme une correction occasionnelle.

Task 10: Identify snapshot space vs dataset space (why space didn’t free)

cr0x@server:~$ zfs list -o name,used,usedbysnapshots,usedbydataset,usedbychildren -r tank/data
NAME       USED  USEDBYSNAPSHOTS  USEDBYDATASET  USEDBYCHILDREN
tank/data  3.1T  1.4T             1.5T           0.2T

Interprétation : Les instantanés représentent 1.4T ici. Si vous supprimez des instantanés et que ce nombre ne baisse pas, vous avez encore des instantanés (peut-être sur des enfants), des holds/clones empêchant la suppression, ou vous supprimez ceux qui ne possèdent pas réellement l’espace qui vous préoccupe.

Task 11: See which snapshots exist on descendants (the “I deleted it” trap)

cr0x@server:~$ zfs list -t snapshot -r -o name,used -s used tank/data | tail -n 10
tank/data/projects@autosnap_2025-12-21  110G
tank/data/projects@autosnap_2025-12-22   95G
tank/data/home@autosnap_2025-12-21       70G
tank/data/home@autosnap_2025-12-22       68G

Interprétation : Vous avez peut-être détruit l’instantané sur tank/data mais l’usage important se situe sur tank/data/projects et tank/data/home. Les instantanés sont par dataset ; la récursion compte.

Task 12: Destroy a snapshot recursively (carefully)

cr0x@server:~$ sudo zfs destroy -r tank/data@autosnap_2025-12-21

Interprétation : Cela détruit l’instantané portant ce nom sur le dataset et tous ses descendants. C’est puissant et facile à mal utiliser. Assurez-vous que les conventions de nommage des instantanés sont cohérentes et que vous voulez vraiment la récursion.

Task 13: Find snapshots that are held across a whole tree

ZFS n’offre pas une commande unique « lister tous les instantanés tenus » avec tous les détails en une seule fois, donc on le script généralement avec un tuyau sûr.

cr0x@server:~$ for s in $(zfs list -H -t snapshot -o name -r tank/data); do
>   zfs holds "$s" 2>/dev/null | awk 'NR==1{next} {print $1" "$2}'
> done | head
tank/data@autosnap_2025-12-20 replicate
tank/data/projects@autosnap_2025-12-20 replicate
tank/data/projects@autosnap_2025-12-20 backup

Interprétation : Cela vous indique quels instantanés sont protégés et par quels tags. Dans un environnement désordonné, les noms de tags sont la pierre de Rosette pour comprendre quel système « possède » la rétention.

Task 14: Verify whether replication/backup is recreating snapshots

Si les instantanés « reviennent », vérifiez les heures de création et les motifs. C’est la méthode la moins glamour mais la plus efficace : prouver la source de la vérité.

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation tank/data | tail -n 5
tank/data@autosnap_2025-12-25_0000  Thu Dec 25 00:00 2025
tank/data@autosnap_2025-12-25_0100  Thu Dec 25 01:00 2025
tank/data@autosnap_2025-12-25_0200  Thu Dec 25 02:00 2025
tank/data@autosnap_2025-12-25_0300  Thu Dec 25 03:00 2025
tank/data@autosnap_2025-12-25_0400  Thu Dec 25 04:00 2025

Interprétation : Une cadence horaire indique une automatisation. Supprimer sans corriger le planificateur, c’est comme boucher un bateau pendant qu’on en perce d’autres trous.

Task 15: Check for an in-progress send/receive that may hold things “busy”

Cela dépend de l’OS et des outils, mais on peut généralement repérer des streams ZFS actifs via la liste de processus.

cr0x@server:~$ ps aux | egrep 'zfs (send|receive)|mbuffer|ssh .*zfs receive' | grep -v egrep
root     18244  2.1  0.0  17768  4100 ?        Ss   03:02   0:01 zfs send -I tank/data@autosnap_2025-12-24 tank/data@autosnap_2025-12-25_0300
root     18245  0.8  0.0  10432  2820 ?        S    03:02   0:00 ssh backup-target zfs receive -uF tank/replica/data

Interprétation : Si vous supprimez un instantané qui est actuellement la base d’un send incrémental, le job peut échouer ou redémarrer et remettre un hold. Coordonnez-vous avec les fenêtres de réplication.

Task 16: Use dry-run thinking before destructive commands

ZFS n’a pas de --dry-run universel pour destroy. Votre « dry run » est l’inspection : lister les holds, lister les clones, lister les dépendants, confirmer le nommage, et confirmer la portée (-r ou non).

cr0x@server:~$ zfs holds tank/data@autosnap_2025-12-20
cr0x@server:~$ zfs get -H -o name,value origin -r tank | grep 'tank/data@autosnap_2025-12-20' || true
cr0x@server:~$ zfs list -t snapshot -r -o name tank/data | grep '@autosnap_2025-12-20' | head

Interprétation : Cette séquence répond : « Est-ce qu’il est tenu ? », « Y a-t-il des clones ? », et « Qu’est-ce que la récursion va toucher exactement ? ». C’est ennuyeux. Ça marche.

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

Mini-récit 1 : Un incident causé par une mauvaise hypothèse

L’hypothèse : « Si l’instantané est ancien, il est sûr de le supprimer ». Un administrateur de stockage (compétent, prudent, juste pressé) a vu un pool atteindre 90% et a commencé à élaguer les instantanés de plus de 30 jours. La commande destroy a échoué sur un sous-ensemble avec « dependent clones », donc il est passé à autre chose et a supprimé ce qu’il pouvait. L’espace n’est pas revenu suffisamment. La panique est montée. D’autres suppressions ont suivi.

Ce qu’il n’avait pas réalisé : une équipe dev avait un sandbox d’analytics « temporaire » cloné à partir d’un instantané de production vieux d’un mois. Il était utilisé pour des requêtes ad-hoc, et quelqu’un avait pointé un tableau de bord interne dessus parce que c’était « rapide ». Pas de ticket. Pas de documentation. Juste une dépendance silencieuse collée à un instantané comme une bernacle.

La voie de l’astreinte est devenue moche parce que l’erreur n’affichait pas « ceci alimente vos tableaux de bord ». Elle disait simplement « dependent clones ». L’équipe a essayé de promouvoir le clone sans comprendre les conséquences, ce qui a réarrangé la lignée et cassé un script de rétention qui supposait que les origines vivaient à un seul endroit. Soudain, les incrémentaux de réplication ne trouvaient plus leurs bases. Les jobs ont échoué. Les alertes ont afflué.

Ce qui a réglé le problème n’a pas été de l’héroïsme ; ce fut une décision adulte : inventorier les clones, identifier les propriétaires, planifier une fenêtre pour le sandbox, et soit le détruire soit le réhéberger comme dataset propre avec rétention explicite. La leçon durable : « ancien » n’est pas une classification de sécurité. La dépendance l’est.

Mini-récit 2 : Une optimisation qui s’est retournée contre eux

L’objectif était noble : réduire le nombre d’instantanés. Une équipe plateforme a changé leur politique de « instantanés horaires pour 7 jours » vers « horaires pour 24 heures, puis quotidiens pendant 30 jours ». Ils ont aussi ajouté une fonctionnalité pratique : créer un clone du snapshot de la nuit précédente pour chaque développeur voulant un environnement frais. La création de clone était automatisée et rapide. Les développeurs étaient ravis.

Deux mois plus tard, le pool a commencé à croître d’une façon inexplicable. Ils supprimaient les instantanés selon le calendrier ; les graphiques semblaient conformes. Mais usedbysnapshots restait élevé. L’ingénieur stockage a creusé et trouvé des dizaines de clones longue durée créés à partir de « la nuit précédente », dont certains étaient devenus semi-permanents car utilisés pour reproduire des bugs, lancer des benchmarks, ou conserver des données « au cas où ».

L’optimisation a échoué parce que la politique de rétention supposait que les instantanés étaient le seul mécanisme d’épinglage. Les clones ont silencieusement transformé une « histoire d’instantanés courte » en « rétention de blocs longue durée », et le système faisait exactement ce qu’on lui demandait : protéger les blocs d’origine du clone. La solution a été d’imposer un cycle de vie aux clones aussi : expiration automatique, promotion automatique (lorsque approprié), et application de noms et de propriétaires.

C’est une histoire d’entreprise classique : vous optimisez une métrique (nombre d’instantanés) et monétisez accidentellement une autre (rétention de blocs). Le stockage se fiche de la feuille de calcul que vous utilisez ; il vous facture en téraoctets.

Mini-récit 3 : Une pratique ennuyeuse mais correcte qui a sauvé la situation

Dans un autre environnement, le nettoyage des instantanés n’était jamais excitant — et c’est pourquoi ça fonctionnait. Ils avaient une convention écrite : chaque tag de hold doit inclure le nom du système et l’objectif (par ex., backup:daily, replicate:dr, legal:case123). Chaque clone doit inclure un préfixe propriétaire et une date d’expiration dans le nom du dataset. Tout changement de rétention nécessitait une simple revue par un pair.

Puis une alerte ransomware est arrivée. L’équipe sécurité a voulu préserver les anciens instantanés pendant l’enquête. L’outillage de sauvegarde a commencé à placer des holds partout. L’utilisation du stockage a grimpé. Le pool a atteint des seuils inconfortables. C’est là que la « pratique ennuyeuse » a payé : comme les tags étaient significatifs, l’équipe stockage a pu voir quels holds étaient motivés par la sécurité et lesquels étaient liés à la réplication. Ils ont relâché sélectivement les holds lorsque la fenêtre d’investigation s’est fermée, sans casser la réplication DR.

Ils avaient aussi un rapport hebdomadaire (oui, un CSV ennuyeux) listant les clones plus vieux que leur expiration. Quand l’incident est survenu, ils savaient déjà ce qu’il était sûr de supprimer. Pas d’archéologie, pas de conjectures, pas d’emails nocturnes « qui possède ce dataset ».

La journée a été sauvée par quelque chose dont personne ne se vante : nommage cohérent, propriété visible, et piste d’audit. La caractéristique de performance la plus sous-estimée de ZFS est une organisation qui sait ce qu’elle a demandé à ZFS de faire.

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

Checklist A: Remove a snapshot blocked by holds (safely)

Tenter une destruction pour capturer le message d’erreur exact.
Lister les holds avec zfs holds.
Identifier le propriétaire de chaque tag de hold (backup, replication, compliance).
Mettre en pause / coordonner tout workflow qui réappliquera le hold.
Relâcher les holds avec zfs release <tag> <snapshot> pour chaque tag.
Détruire l’instantané.
Vérifier la liste des instantanés et la comptabilité d’espace.

Checklist B: Remove a snapshot blocked by clones

Confirmer l’erreur « has dependent clones » ou trouver les origines référant l’instantané.
Enumérer les clones avec zfs get origin -r et faire correspondre l’instantané.
Pour chaque clone : décider destruction vs promotion.
Si destruction : utiliser zfs destroy -r sur le dataset clone (pas sur l’instantané).
Si promotion : exécuter zfs promote puis revérifier les dépendances.
Détruire l’instantané original quand les dépendances ont disparu.

Checklist C: Space isn’t freeing after snapshot deletion

Vérifier usedbysnapshots sur le sous-arbre du dataset.
Identifier les instantanés lourds via zfs list -t snapshot -o used.
Vérifier s’il reste des holds et des clones.
Confirmer que vous avez supprimé les instantanés sur les bons datasets (la récursion compte).
Chercher d’autres références : instantanés plus récents, clones, ou le dataset live lui-même.
Re-vérifier l’espace libre au niveau du pool et les propriétés reservation/refreservation si applicable.

Deuxième blague (et dernière) : le moyen le plus rapide de réduire le nombre d’instantanés est rm -rf /, mais c’est aussi une excellente façon de réduire le nombre d’employés.

Erreurs courantes (symptômes + corrections)

Mistake 1: Releasing holds without coordinating with replication/backup

Symptôme : Les instantanés se suppriment, puis les jobs de réplication échouent ou les sauvegardes se plaignent de bases incrémentales manquantes.

Correction : Identifiez pourquoi le hold existe. Si c’est une ancre de réplication, soit terminez le cycle de réplication d’abord, soit ajustez la stratégie de réplication pour utiliser un autre instantané de base. Dans certains environnements, la bonne correction est d’arrêter brièvement le service de réplication, nettoyer, puis redémarrer avec une nouvelle baseline.

Mistake 2: Destroying recursively when you meant a single dataset snapshot

Symptôme : Plusieurs datasets perdent leurs instantanés en même temps. Les développeurs demandent pourquoi leur « point de restauration » a disparu.

Correction : Avant d’utiliser -r, listez les instantanés dans le sous-arbre et confirmez la cohérence du nommage. Si l’environnement utilise des noms d’instantanés mixtes, évitez les destructions récursives et ciblez les datasets explicitement.

Mistake 3: Confusing snapshot `USED` with “how big the snapshot is”

Symptôme : Vous supprimez un instantané affichant USED=0 et vous attendez un retour d’espace ; rien ne change, ou vous supprimez les mauvais en premier.

Correction : Comprenez que USED est l’espace unique attribuable à cet instantané. Un instantané avec peu de USED peut rester critique opérationnellement comme base incrémentale ; un instantané avec beaucoup de USED est là où vous récupérerez de l’espace.

Mistake 4: Forgetting clones exist (or not recognizing them)

Symptôme : Erreurs « dependent clones », ou l’espace ne se libère pas malgré l’élagage des instantanés.

Correction : Recherchez des datasets avec une propriété origin pointant vers l’instantané. Décidez destruction vs promotion. Ajoutez des règles de cycle de vie pour les clones afin que cela ne se reproduise pas.

Mistake 5: Deleting snapshots that automation recreates

Symptôme : Vous détruisez des instantanés et ils réapparaissent avec de nouveaux timestamps de création.

Correction : Trouvez et modifiez le planificateur/la politique qui les crée. La suppression d’instantanés n’est pas une politique de rétention ; c’est une action de nettoyage. La rétention vit dans le moteur de politiques.

Mistake 6: Ignoring dataset reservations and refreservations

Symptôme : Le pool semble encore plein après une suppression significative d’instantanés, ou des datasets ne peuvent pas allouer d’espace malgré un « free » affiché ailleurs.

Correction : Vérifiez les propriétés reservation et refreservation. Les réservations peuvent rendre l’espace « indisponible ». Ajustez avec précaution — les réservations sont souvent là pour protéger des charges critiques.

Mistake 7: Fighting “busy” snapshots with force instead of patience and coordination

Symptôme : Destroy échoue avec « dataset is busy » pendant des fenêtres de réplication ou de sauvegarde.

Correction : Identifiez les pipelines zfs send/receive actifs. Attendez la fin ou coordonnez un arrêt. Réessayer sans cesse la destruction dans une boucle n’ajoute que du chaos.

FAQ

1) What does `zfs release` actually do?

Il supprime un tag de hold nommé d’un instantané. Les holds empêchent la destruction d’un instantané. Si un instantané a plusieurs holds, vous devez tous les relâcher (sinon les holds restants bloqueront encore la destruction).

2) Why does ZFS allow holds at all? It feels like it’s fighting me.

Parce qu’en exploitation réelle, l’automatisation et les humains font tous deux des erreurs. Les holds sont des garde-fous : « cet instantané est requis pour la sauvegarde/réplication/conformité ». Sans eux, un script de nettoyage peut effacer vos points de restauration plus vite que votre réponse à l’incident ne peut taper sur le clavier.

3) I released holds and destroyed the snapshot. Why didn’t I get space back?

Parce que ces blocs peuvent encore être référencés par des instantanés plus récents, des clones, ou le système de fichiers en direct. Utilisez zfs list avec usedbysnapshots et triez les instantanés par used pour trouver où l’espace est réellement épinglé.

4) What’s the difference between a snapshot and a bookmark?

Un instantané inclut les métadonnées complètes du point dans le temps. Un bookmark est une référence légère utilisée principalement comme base de réplication incrémentale. Détruire un bookmark ne libère pas l’espace d’un instantané parce que ce n’est pas un instantané ; détruire un instantané peut libérer de l’espace si les blocs ne sont plus référencés ailleurs.

5) How do I know whether a snapshot is kept because of clones?

Cherchez des datasets dont la propriété origin égale cet instantané. S’il en existe, l’instantané est une origine et ne peut pas être détruit tant que ces clones ne sont pas supprimés ou promus.

6) Is it safe to use `zfs destroy -r` on a snapshot name?

Ça peut être sûr si vous détruisez intentionnellement cet instantané dans un arbre de datasets bien compris et avec un nommage cohérent. C’est dangereux si les datasets enfants ont des significations/propriétaires différents. « Récursif » n’est pas un drapeau de commodité ; c’est un multiplicateur de portée.

7) What’s the safest way to clean up snapshots in a replicated environment?

Prendre les décisions de rétention en un seul endroit (source de vérité), coordonner les fenêtres de réplication, et éviter de supprimer les instantanés base incrémentale dont la réplication a besoin. En pratique, cela signifie : comprendre les attentes de votre outil de réplication, respecter les tags de hold qu’il place, et nettoyer dans une fenêtre de changement contrôlée quand il faut casser le verre.

8) Can I force-destroy a held snapshot?

Pas dans le sens de « ignorer les holds ». La méthode correcte est de relâcher les holds. Si vous ne contrôlez pas les holds (par ex., compliance), votre vrai travail est la gouvernance : déterminer qui possède la politique de hold et quelles conditions permettent la libération.

9) Why do I get “snapshot has dependent clones” when I don’t remember creating clones?

Parce que quelque chose d’autre l’a fait. Les outils de virtualisation, les pipelines CI, le self-service développeur, et certains workflows de sauvegarde peuvent créer des clones. Les noms de dataset et la propriété origin vous diront ce qui est connecté — même si personne ne s’en souvient.

10) How do I prevent “undeletable snapshots” from happening again?

Standardisez les tags de hold, implémentez un cycle de vie pour les clones (expiration/propriétaire), et rendez les changements de politique de rétention explicites et revus. Techniquement, ZFS fait la bonne chose ; opérationnellement, vous devez vous assurer que les bonnes personnes et systèmes sont ceux qui posent ces contraintes.

Conclusion

Dans ZFS, les instantanés ne sont pas impossibles à supprimer. Ils sont responsables. Si un instantané ne veut pas mourir, c’est parce que quelque chose en dépend encore — par conception. La route pratique est toujours la même : lisez l’erreur exacte, vérifiez les holds, vérifiez les clones, puis vérifiez si l’automatisation recrée ce que vous supprimez. Une fois que vous traitez les instantanés comme faisant partie d’un graphe de dépendances plutôt que comme des « vieux fichiers », zfs release cesse d’être une incantation mystérieuse et redevient ce qu’il est : un moyen contrôlé d’enlever un verrou de sécurité.

Faites d’abord les inspections ennuyeuses, coordonnez-vous avec les propriétaires de réplication/sauvegarde, et soyez explicite sur la portée. ZFS vous rendra la pareille — juste après avoir confirmé que vous n’êtes pas sur le point de supprimer le seul canot de sauvetage.