ZFS snapdir=visible : Auditer les instantanés sans énerver les utilisateurs

Il y a une forme particulière de panique qui s’installe dans une organisation quand quelqu’un dit « Il faut auditer les fichiers tels qu’ils étaient mardi dernier » et que l’équipe stockage répond « Bien sûr, mais seuls les administrateurs root voient les instantanés. » Ce n’est pas tant une limitation technique qu’un choix de politique — et comme la plupart des choix de politique en stockage, ça devient un problème d’UX dès que les utilisateurs sont impliqués.

snapdir=visible est l’un de ces interrupteurs ZFS qui paraissent anodins mais qui changent la façon dont les gens interagissent avec un système de fichiers. Bien utilisé, il transforme la forensique d’instantanés en expérience en libre-service et évite que votre on-call ne devienne une API humaine de restauration de fichiers. Mal utilisé, c’est le dossier mystère le plus déroutant du monde, ça casse les attentes des clients SMB/NFS et ça génère une tempête de tickets qui vous fera envisager l’agriculture.

Ce que snapdir fait réellement (et ce qu’il ne fait pas)

Les instantanés ZFS ne sont pas des « copies de sauvegarde » au sens classique des serveurs de fichiers. Ce sont des vues en lecture seule et à un instant donné d’un dataset. En interne, ce sont des références métadonnées vers des blocs déjà présents ; ZFS utilise le copy-on-write, donc les blocs référencés par des instantanés sont préservés tant qu’aucun instantané (et aucun fichier vivant) ne les référence plus.

La propriété de dataset snapdir contrôle la façon dont les instantanés sont exposés dans l’espace de noms du système de fichiers. Concrètement :

• snapdir=hidden (par défaut dans de nombreux environnements) : le répertoire .zfs existe conceptuellement mais n’apparaît pas dans les listes de répertoires.
• snapdir=visible : le répertoire .zfs apparaît à la racine du point de montage du dataset, généralement comme /.zfs dans ce dataset, avec un sous-répertoire snapshot contenant chaque instantané comme un arbre de répertoires consultable.

Ce qu’il ne fait pas : il n’accorde pas de permissions. Il n’outrepasse pas les bits de mode POSIX, les ACL, ou les règles de partage SMB. Il ne rend pas non plus le contenu des instantanés modifiable. Il ne transforme pas non plus les instantanés en datasets indépendants que vous pouvez monter n’importe où. C’est important parce que beaucoup d’attentes du type « les utilisateurs voient maintenant les instantanés ! » s’effondrent en « les utilisateurs voient les noms d’instantanés mais pas les fichiers qu’ils veulent », ce qui est moins valorisant et plus frustrant.

Deux phrases de sagesse issues de la production : la visibilité n’est pas l’accès, et l’accès sans processus, c’est le chaos. Si vous activez la visibilité sans expliquer aux utilisateurs quoi en faire, ils l’exploreront comme un enfant dans une salle serveur : avec curiosité et sans sens des conséquences.

Pourquoi rendre les instantanés visibles ?

L’argument de vente est simple : audits plus rapides et moins de restaurations demandées. La réalité est nuancée : cela change la dynamique de la réponse aux incidents et transfère une partie de la complexité des SREs vers les utilisateurs. Ça peut être une bonne chose — tant que vous l’encadrez avec des paramètres raisonnables, de la formation et des garde-fous.

Cas d’usage où snapdir=visible brille

• Revues d’audit et conformité : « Montrez-moi à quoi ressemblait ce dossier le 1er. » Les utilisateurs peuvent parcourir les instantanés pour vérifier la présence/absence d’artefacts sans ouvrir un ticket.
• Restauration en libre-service : restaurer un fichier supprimé devient un copier-depuis-instantané, pas « attendez que l’équipe stockage le restaure ».
• Diff forensic : comparer deux points dans le temps pour détecter une dérive de configuration ou une altération de données. Les instantanés ZFS offrent une vue cohérente.
• Réduction du rayon d’action des restaurations : les utilisateurs peuvent restaurer seulement ce dont ils ont besoin, au lieu de demander un rollback global (l’équivalent stockage d’un marteau-piqueur pour réparer une montre).

Cas d’usage où ça pose problème

• Datasets partagés avec permissions désordonnées : les utilisateurs voient les arbres d’instantanés mais ne peuvent pas lire la plupart d’entre eux à cause des ACLs. Cela génère des tickets « sauvegarde cassée ».
• Comportements étranges des clients SMB/NFS : certains clients traitent les répertoires commençant par un point comme cachés ; d’autres non. Les indexeurs et outils de sauvegarde peuvent récursivement parcourir ces répertoires de façon inattendue.
• Environnements multi-tenant : exposer les noms d’instantanés peut divulguer des informations (noms de projets, dates d’incidents, politiques de rétention) même si l’accès aux données est bloqué.

Blague #1 : Rendre les instantanés visibles sans plan, c’est comme cacher vos doubles de clés sous le paillasson et être surpris que tout le monde regarde dessous.

Comment le répertoire .zfs se comporte en pratique

Quand vous mettez snapdir=visible sur un dataset, ZFS expose un répertoire spécial à la racine de ce dataset : .zfs. Sous celui-ci vous obtenez typiquement :

• .zfs/snapshot/ — des répertoires nommés comme chaque instantané, chacun contenant un arbre complet du système de fichiers tel qu’il était au moment de l’instantané.

Quelques comportements qui comptent opérationnellement :

• L’arbre d’instantané est en lecture seule. Les utilisateurs peuvent copier depuis celui-ci mais pas modifier à l’intérieur.
• Les permissions sont évaluées de la même manière que pour le dataset vivant. Si un utilisateur ne pouvait pas lire /data/hr/payroll.xlsx hier, il ne pourra pas non plus le lire dans .zfs/snapshot/yesterday/data/hr/payroll.xlsx.
• C’est par dataset. Si vous avez des datasets imbriqués, chaque dataset a sa propre vue .zfs. Cela peut perturber les utilisateurs qui traversent des points de montage et voient soudainement des listes d’instantanés différentes.
• Ce n’est pas un répertoire normal. Certains outils le traitent de manière étrange : comportements de récursion, numéros d’inode, et sémantiques de parcours peuvent surprendre des utilitaires plus anciens.

Il y a aussi un comportement social subtil : une fois que les utilisateurs découvrent .zfs/snapshot, ils commencent à l’utiliser comme une « machine à remonter le temps ». C’est acceptable — jusqu’à ce que la rétention expire et que la « machine à remonter le temps » n’ait plus de carburant. Si vous voulez moins de courriels en colère, communiquez la rétention comme une fonctionnalité produit (« nous conservons 30 instantanés journaliers ») plutôt que comme une propriété magique de l’univers.

Faits et contexte historique à connaître

Un peu de contexte aide à prendre de meilleures décisions. Voici quelques faits concrets qui importent souvent en production :

1. Les instantanés ZFS sont peu coûteux à créer car ils enregistrent surtout des métadonnées ; le coût important apparaît plus tard quand les instantanés maintiennent des blocs anciens vivants.
2. Le copy-on-write explique pourquoi les instantanés fonctionnent : ZFS n’écrase jamais en place ; les modifications écrivent de nouveaux blocs, et les instantanés gardent des références aux anciens blocs.
3. Le répertoire .zfs est synthétique : il n’est pas stocké comme des fichiers normaux ; c’est une vue virtuelle fournie par ZFS.
4. La visibilité a été conçue pour des flux administratifs et est ensuite devenue un mécanisme de restauration en libre-service dans de nombreuses entreprises — souvent sans plan UX formel.
5. Les « fuites » de noms d’instantanés existent : même si les données sont protégées, les noms d’instantanés peuvent révéler des noms de projet, des dates d’incident ou des indices RH si vous les incluez dans les noms.
6. La snapshot récursive peut donner une illusion de complétude : snapshotter un dataset parent n’inclut pas automatiquement tous les datasets enfants sauf si vous le faites explicitement ou utilisez les flags récursifs.
7. « Previous Versions » SMB est une fonctionnalité distincte de snapdir=visible ; vous pouvez supporter l’un, l’autre, ou les deux, et ils se comportent différemment.
8. Les instantanés ne sont pas des sauvegardes si le pool meurt ou si un ransomware chiffre le dataset vivant et que vous répliquez des blocs chiffrés. Les instantanés sont un filet de sécurité local, pas un plan de reprise après sinistre.
9. La politique de rétention est une politique de capacité : « conserver plus d’instantanés » revient à « acheter plus de disque », mais avec moins de réunions d’achat.

Trois micro-histoires en entreprise (douleurs, ironie, salut)

1) Incident causé par une mauvaise hypothèse : « Visible signifie récupérable »

Un grand partage de fichiers interne subissait des suppressions fréquentes. L’équipe stockage a activé snapdir=visible pour réduire les tickets de restauration. En une journée, la file d’aide s’est améliorée — jusqu’à ce qu’un analyste conformité tente de récupérer un fichier depuis un instantané et obtienne « Permission denied ». Il a escaladé en supposant que les instantanés étaient des « archives de sauvegarde » et donc accessibles aux auditeurs par défaut.

La mauvaise hypothèse était subtile : le rôle de l’analyste accordait l’accès en lecture à certains rapports via une couche applicative, pas via les permissions du système de fichiers. Dans le monde vivant, l’application médiatisait l’accès. Dans le monde des instantanés, l’utilisateur interagissait directement avec les permissions POSIX et les ACLs, qui étaient plus strictes. L’utilisateur pouvait lister les noms d’instantanés mais ne pouvait pas traverser des répertoires clés.

L’incident est devenu politique parce que cela semblait indiquer que le stockage avait « cassé le processus d’audit ». En réalité, le stockage exposait la réalité : le rôle d’audit n’avait jamais eu d’accès direct au système de fichiers. La correction n’a pas été technique au départ — c’était de la terminologie. L’équipe a rédigé une note interne courte : « Les instantanés exposent l’historique du système de fichiers ; ils n’augmentent pas les privilèges. » Puis ils ont ajouté un groupe « auditeur » contrôlé avec des ACLs en lecture seule sur des datasets spécifiques, et créé un processus documenté pour les approbations d’accès temporaires.

Après ça, le gain était réel : les audits sont devenus plus rapides et l’on-call a cessé les restaurations artisanales à 2 h du matin. Mais la leçon clé est restée : un interrupteur fonctionnel n’est pas un processus.

2) Optimisation qui a rebondi : « Rendons tout visible partout »

Une équipe plateforme a décidé de standardiser : tous les datasets obtiennent snapdir=visible. Leur objectif était la cohérence et moins de cas particuliers. Ils l’ont déployé un vendredi après-midi parce que le changement était « juste une propriété ». (Si vous cherchez un signe de l’univers : c’était le signe.)

Le lundi matin a apporté son lot d’ennuis. Un ensemble d’agents d’indexation de fichiers — déployés initialement pour accélérer la recherche d’entreprise — a commencé à crawler les arbres .zfs/snapshot. Chaque instantané ressemblait à tout un nouvel univers de fichiers. Les indexeurs ne comprenaient pas qu’il s’agissait de vues historiques et réindexaient volontiers le même contenu des dizaines de fois à travers les instantanés. Le CPU de la ferme d’indexeurs a grimpé, le trafic réseau a augmenté, et le cluster de stockage a vu bien plus de lectures de métadonnées qu’à l’habitude.

Pire, certaines équipes utilisaient des outils qui traitent n’importe quel arbre de répertoires comme du contenu de sauvegarde candidat. Quelques « scripts de sauvegarde maison » (ces scripts écrits une fois, jamais retestés, et maintenus par superstition) ont suivi .zfs et ont fait exploser les fenêtres de sauvegarde. Personne ne voulait l’admettre, mais « l’optimisation » avait créé une taxe sur plusieurs systèmes.

Le rollback a été rapide : désactiver la visibilité sur les partages larges, puis réactiver sélectivement là où la récupération en libre-service importait et où les clients étaient bien configurés. La correction à plus long terme a été de configurer les indexeurs et outils de sauvegarde pour exclure /.zfs, et de créer des datasets avec une intention claire : les partages utilisateurs ont eu une politique d’exposition des instantanés soignée, tandis que les datasets machine sont restés cachés.

Blague #2 : Le moyen le plus rapide de trouver un crawler oublié est de lui donner un labyrinthe infini et de le regarder sprinter.

3) Une pratique ennuyeuse mais correcte qui a sauvé la journée : « Une petite limite de dataset et des noms prévisibles »

Une organisation d’ingénierie stockait les artefacts de build et les packages de release sur ZFS. Ils étaient stricts sur la disposition des datasets : chaque ligne produit avait son propre dataset, et les permissions étaient cohérentes. Les noms d’instantanés suivaient une norme ennuyeuse : auto-YYYYMMDD-HHMM, créés chaque heure et purgeés quotidiennement.

Un jour, un responsable de release a découvert qu’un binaire signé avait disparu du dossier « final ». La peur immédiate était une compromission. Ils avaient besoin de répondre à deux questions : quand a-t-il disparu, et qui y avait accès ? Comme snapdir=visible était activé sur ce dataset, l’équipe de release a pu immédiatement parcourir les instantanés, trouver le dernier instantané contenant le fichier, et réduire la fenêtre à une heure précise.

L’équipe stockage a tout de même été impliquée, mais la question n’était plus « restaurer tout s’il vous plaît ». C’était « nous avons identifié la fenêtre de disparition ; pouvez-vous corréler avec les logs SMB et confirmer qu’il n’y a pas eu de problème de pool ? » C’est le type de ticket que vous souhaitez : borné, fondé sur des preuves et rapide.

Le dénouement final était banal : un job d’automatisation avait un pattern de nettoyage trop large. Mais l’investigation a évité le drame parce que les limites de dataset étaient propres, les noms d’instantanés prévisibles, et l’exposition des instantanés intentionnelle. Ce n’était pas de l’ingénierie héroïque ; c’était la bonne hygiène qui rapporte des intérêts.

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

Ci-dessous se trouvent des tâches réelles que vous pouvez exécuter en production pour implémenter, auditer et dépanner snapdir=visible. Chacune inclut ce qu’il faut surveiller pour que ce ne soit pas juste du spam de commandes.

Task 1: Check current snapdir setting on a dataset

cr0x@server:~$ zfs get -H -o name,property,value,source snapdir tank/projects
tank/projects	snapdir	hidden	default

Interprétation : Il utilise la valeur par défaut (hidden). Si la source est local, quelqu’un l’a explicitement définie ; si c’est inherited, un dataset parent la contrôle.

Task 2: Enable snapdir=visible (single dataset)

cr0x@server:~$ sudo zfs set snapdir=visible tank/projects
cr0x@server:~$ zfs get -H snapdir tank/projects
tank/projects	snapdir	visible	local

Interprétation : Le dataset affichera désormais un répertoire .zfs à son point de montage. Cela ne change pas la rétention des instantanés, ne crée pas d’instantanés, et n’altère pas les permissions.

Task 3: Verify .zfs exists and is visible in the mountpoint

cr0x@server:~$ ls -la /tank/projects | head
total 12
drwxr-xr-x  6 root root    6 Dec 24 10:01 .
drwxr-xr-x  4 root root    4 Dec 24 09:58 ..
drwxr-xr-x  2 root root    2 Dec 24 10:01 .zfs
drwxr-xr-x 18 root root   18 Dec 24 09:59 engineering
drwxr-xr-x 11 root root   11 Dec 24 10:00 finance

Interprétation : Si .zfs n’est pas présent, confirmez que vous listez le point de montage du dataset (pas un répertoire parent) et que le dataset est monté.

Task 4: List snapshots via ZFS CLI (ground truth)

cr0x@server:~$ zfs list -t snapshot -o name,creation,used,refer,mountpoint -r tank/projects | head
NAME                                   CREATION                USED  REFER  MOUNTPOINT
tank/projects@auto-20251224-0900        Wed Dec 24 09:00 2025   12M   1.20T  -
tank/projects@auto-20251224-1000        Wed Dec 24 10:00 2025   18M   1.21T  -

Interprétation : Le USED d’un instantané indique combien d’espace unique cet instantané retient (blocs non référencés ailleurs). Si USED augmente, la rétention a un coût capacitif direct.

Task 5: List snapshots by browsing .zfs

cr0x@server:~$ ls -1 /tank/projects/.zfs/snapshot | head
auto-20251224-0900
auto-20251224-1000

Interprétation : Si l’interface ZFS montre des instantanés mais que .zfs/snapshot est vide, vous n’êtes probablement pas dans le dataset que vous pensez (confusion de datasets imbriqués), ou le chemin client traverse une frontière de point de montage.

Task 6: Copy a deleted file back from a snapshot (safe self-serve restore)

cr0x@server:~$ cp -av /tank/projects/.zfs/snapshot/auto-20251224-0900/engineering/readme.txt \
> /tank/projects/engineering/readme.txt
'/tank/projects/.zfs/snapshot/auto-20251224-0900/engineering/readme.txt' -> '/tank/projects/engineering/readme.txt'

Interprétation : Utilisez cp (ou rsync) pour restaurer dans l’arbre vivant. N’essayez pas d’écrire à l’intérieur de l’arbre d’instantané ; il est en lecture seule et échouera.

Task 7: Confirm a user’s ability to traverse snapshot directories

cr0x@server:~$ sudo -u alice ls -la /tank/projects/.zfs/snapshot/auto-20251224-0900/finance
ls: cannot open directory '/tank/projects/.zfs/snapshot/auto-20251224-0900/finance': Permission denied

Interprétation : C’est généralement le comportement attendu. Cela signifie que l’instantané respecte les mêmes permissions que l’arbre vivant. Si les utilisateurs attendent d’y avoir accès, il faut discuter des ACLs/permissions, pas toucher à un réglage stockage.

Task 8: Find what’s consuming space due to snapshots (high-level)

cr0x@server:~$ zfs list -o name,used,avail,refer,ratio,mountpoint tank/projects
NAME          USED  AVAIL  REFER  RATIO  MOUNTPOINT
tank/projects 3.41T 2.12T  1.21T  1.68x  /tank/projects

Interprétation : USED inclut les blocs détenus par les instantanés. Si REFER est stable mais que USED augmente, des instantanés (ou des clones) maintiennent d’anciens blocs.

Task 9: See snapshot space consumption per snapshot

cr0x@server:~$ zfs list -t snapshot -o name,used,refer -s used -r tank/projects | tail -5
tank/projects@auto-20251220-0900  1.9G  1.08T
tank/projects@auto-20251221-0900  2.3G  1.10T
tank/projects@auto-20251222-0900  3.1G  1.14T
tank/projects@auto-20251223-0900  4.8G  1.18T
tank/projects@auto-20251224-0900   12M  1.20T

Interprétation : Les instantanés plus anciens retiennent souvent plus de blocs uniques, surtout si le dataset subit beaucoup de changements (images VM, artefacts de build, bases de données). Quelques instantanés volumineux peuvent dominer les coûts.

Task 10: Detect “snapshot directory crawlers” using filesystem activity symptoms

cr0x@server:~$ sudo zpool iostat -v tank 2 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        8.10T  2.12T    980    210   118M  22.1M
  raidz2    8.10T  2.12T    980    210   118M  22.1M
    sda         -      -    160     35  19.7M  3.6M
    sdb         -      -    165     36  19.4M  3.7M
    sdc         -      -    162     34  19.6M  3.5M

Interprétation : Une montée soudaine des IOPS de lecture et de la bande passante de lecture après activation de la visibilité pointe souvent vers des crawlers (indexeurs, antivirus, scripts de sauvegarde) parcourant les arbres d’instantanés.

Task 11: Check dataset mountpoints and nested dataset boundaries (avoids confusion)

cr0x@server:~$ zfs list -o name,mountpoint -r tank/projects
NAME                     MOUNTPOINT
tank/projects            /tank/projects
tank/projects/engineering /tank/projects/engineering
tank/projects/finance    /tank/projects/finance

Interprétation : Chaque dataset enfant a son propre namespace d’instantanés et potentiellement sa propre propriété snapdir. Les utilisateurs qui traversent vers /tank/projects/engineering verront .zfs pour ce dataset, pas les instantanés du parent.

Task 12: Set snapdir via inheritance (apply to a subtree)

cr0x@server:~$ sudo zfs set snapdir=visible tank/projects
cr0x@server:~$ zfs get -H -o name,value,source snapdir tank/projects/engineering
tank/projects/engineering	visible	inherited from tank/projects

Interprétation : L’héritage est votre ami pour la cohérence, mais augmente aussi le rayon d’action. Pour des partages orientés utilisateur, envisagez des réglages locaux explicites et documentez l’intention.

Task 13: Disable visibility (the “stop the bleeding” button)

cr0x@server:~$ sudo zfs set snapdir=hidden tank/projects
cr0x@server:~$ zfs get -H snapdir tank/projects
tank/projects	snapdir	hidden	local

Interprétation : Cela cache à nouveau .zfs des listings de répertoire. Ça ne supprime pas les instantanés ; ça retire juste la surface UX.

Task 14: Verify snapshot retention and prune intentionally

cr0x@server:~$ zfs destroy tank/projects@auto-20251220-0900
cr0x@server:~$ zfs list -t snapshot -r tank/projects | grep auto-20251220-0900
cr0x@server:~$ echo $?
1

Interprétation : Supprimer un instantané libère de l’espace uniquement si ces blocs ne sont plus référencés par d’autres instantanés ou clones. Si l’espace ne diminue pas, vous avez probablement d’autres instantanés qui retiennent la même churn, ou des clones qui épinglent les blocs.

Task 15: Investigate clones pinning snapshot space

cr0x@server:~$ zfs get -H -o name,value origin -r tank/projects | grep -v '^-$'
tank/projects/engineering/testclone	tank/projects@auto-20251222-0900

Interprétation : Si des datasets sont clonés à partir d’instantanés, ces instantanés (ou leurs blocs) peuvent être irrémédiablement non supprimables tant que les clones existent ou sont promus. La visibilité ne cause pas ça, mais ça apparaît souvent lors des audits d’instantanés.

Modèle de contrôle d’accès : ce que les utilisateurs peuvent vraiment voir et faire

snapdir=visible change la découvrabilité, pas l’autorisation. Dans la plupart des configurations POSIX, un utilisateur a besoin de :

• Permission d’exécution (traversée) sur chaque répertoire du chemin pour atteindre un fichier dans l’instantané.
• Permission de lecture sur le fichier pour le copier.
• Les droits ACL appropriés si vous utilisez des ACL NFSv4 ou des ACL POSIX.

Cela signifie que vous pouvez utiliser la visibilité sans donner de nouveaux pouvoirs, mais cela signifie aussi que les utilisateurs peuvent se sentir « frustrés » par des noms d’instantanés qu’ils ne peuvent pas utiliser. Un schéma pratique est de séparer les datasets par audience :

• Partages utilisateurs (home directories, partages d’équipe) : envisagez snapdir=visible plus des consignes explicites sur la restauration en libre-service, avec des exclusions configurées pour les crawlers.
• Datasets machine (bases de données, images VM, caches CI) : gardez snapdir=hidden sauf raison forte ; ces arbres sont de la nourriture pour crawlers et souvent très changeants.
• Datasets d’audit : si des auditeurs ont besoin d’accès, accordez-le intentionnellement via des ACL à un groupe en lecture seule ; ne comptez pas sur « ils voient donc c’est autorisé ».

Un mot sur le nommage : les noms d’instantanés deviennent une UI quand vous les exposez. Si vos noms d’instantanés contiennent des espaces, des blagues ou des noms d’incidents, vous écrivez essentiellement votre journal interne sur la porte d’entrée. Utilisez des noms prévisibles et ennuyeux. L’ennui est scalable.

Performance et impact opérationnel

En théorie, exposer .zfs/snapshot n’est qu’un listing de répertoire. En pratique, cela change ce que font les utilisateurs et les programmes, ce qui change les patrons de charge. La plupart des « problèmes de performance » imputés à snapdir=visible sont en réalité causés par :

• Des scans récursifs par des indexeurs, antivirus, agents de sauvegarde, ou des scripts « find / -type f » qui incluent maintenant les instantanés.
• De la navigation lourde en métadonnées par des utilisateurs qui traitent les arbres d’instantanés comme des archives et lancent beaucoup de listings sur de nombreux instantanés.
• Des frontières de montage confuses où les utilisateurs traversent vers des datasets enfants et déclenchent des ensembles d’instantanés différents, multipliant leur navigation.

Opérationnellement, prévoyez :

• Plus de lectures de métadonnées (surtout si les utilisateurs parcourent des instantanés anciens avec de grands arbres de répertoires).
• Plus de pression sur le cache (ARC) si les arbres d’instantanés sont fréquemment parcourus et ne tiennent pas en mémoire.
• Des questions de support du type « qu’est-ce que ce dossier .zfs ? » et « pourquoi y a-t-il tant de copies ? »

Une astuce pragmatique : traitez snapdir=visible comme un produit destiné aux utilisateurs. Livrez-le avec des exclusions (indexeurs/sauvegardes), une déclaration de rétention, et un extrait « comment restaurer votre fichier ». Vous économiserez plus d’heures qu’aucune micro-optimisation de recordsize ne le fera.

Mode opératoire pour un diagnostic rapide

Quand quelqu’un dit « les instantanés sont lents » ou « activer snapdir a causé de la latence », vous n’avez pas le temps pour des débats philosophiques. Voici un ordre d’action rapide pour trouver rapidement les goulots d’étranglement.

First: confirm what changed and where

1. Confirmez le dataset et le point de montage que les utilisateurs accèdent (les datasets imbriqués comptent).
2. Confirmez que snapdir est réellement visible sur ce dataset (et si c’est hérité).
3. Confirmez si la plainte porte sur le listing des noms d’instantanés ou sur le parcours du contenu des instantanés.

cr0x@server:~$ zfs list -o name,mountpoint -r tank/projects
cr0x@server:~$ zfs get -H -o name,value,source snapdir tank/projects tank/projects/engineering

Second: check pool health and obvious saturation

1. Santé du pool (erreurs, resilvering) en premier. Un pool dégradé rend toute fonctionnalité coupable.
2. IOPS et bande passante sur le pool pendant la fenêtre de la plainte.
3. Indices de latence : beaucoup d’opérations de lecture avec un faible débit indiquent souvent une tempête de métadonnées.

cr0x@server:~$ zpool status -x
all pools are healthy
cr0x@server:~$ zpool iostat -v tank 1 5

Third: look for snapshot tree crawlers and metadata storms

1. Y a-t-il des processus qui font de larges traversées de répertoires ?
2. Un indexeur/AV/agent de sauvegarde a-t-il récemment mis à jour sa configuration ?
3. Le dataset est-il exporté via SMB/NFS et crawlé par des clients ?

cr0x@server:~$ ps auxww | egrep 'find |updatedb|locate|rsync|backup|index' | head
cr0x@server:~$ sudo lsof +D /tank/projects/.zfs/snapshot 2>/dev/null | head

Interprétation : lsof +D peut être coûteux sur de grands arbres ; utilisez-le avec précaution. S’il est trop lent, ciblez un seul répertoire d’instantané ou utilisez des vérifications ciblées basées sur des agents connus.

Fourth: validate ARC pressure and memory contention

1. Si l’ARC thrash, les charges de métadonnées font plus de dégâts.
2. Confirmez que vous n’êtes pas en swap ; le swap transforme ZFS en numéro de performance artistique.

cr0x@server:~$ free -h
cr0x@server:~$ vmstat 1 5

Fifth: decide the mitigation

• Si des crawlers sont la cause : excluez /.zfs au niveau des outils, puis retestez.
• Si ce sont des navigations lourdes légitimes des utilisateurs : envisagez de fournir un hôte « restore » dédié ou un workflow documenté, ou gardez la visibilité seulement sur des datasets sélectionnés.
• Si le pool est saturé : vous pouvez être lié par la capacité ou les IOPS indépendamment de la visibilité — réparez le pool, pas le symptôme.

Erreurs courantes : symptômes et corrections

Mistake 1: Enabling visibility on broad shares without excluding crawlers

Symptômes : pic soudain des IOPS de lecture, listings de répertoires plus lents, montée du CPU sur indexer/AV, fenêtres de sauvegarde qui explosent.

Correction : cachez à nouveau snapdir pour arrêter l’hémorragie, puis configurez des exclusions dans les crawlers pour /.zfs. Réactivez sélectivement sur les datasets utiles.

cr0x@server:~$ sudo zfs set snapdir=hidden tank/projects
cr0x@server:~$ zpool iostat -v tank 2 3

Mistake 2: Assuming snapshots are readable by auditors because they’re visible

Symptômes : plaintes « Permission denied », escalade d’audit, accusations que le stockage « a retenu » des données.

Correction : alignez les permissions/ACL du système de fichiers sur les exigences d’audit, ou fournissez un workflow médiatisé. Documentez que la visibilité n’augmente pas les privilèges.

cr0x@server:~$ getfacl -p /tank/projects/finance | head -40

Mistake 3: Confusing parent dataset snapshots with child dataset snapshots

Symptômes : les utilisateurs disent « l’instantané dont j’ai besoin n’est pas là », alors qu’il existe ailleurs ; listes d’instantanés incohérentes selon le chemin.

Correction : cartographiez les frontières de datasets et points de montage ; assurez-vous que l’automatisation des instantanés couvre bien les datasets enfants comme prévu.

cr0x@server:~$ zfs list -o name,mountpoint -r tank/projects
cr0x@server:~$ zfs list -t snapshot -r tank/projects/engineering | head

Mistake 4: Snapshot naming that becomes a security or HR problem

Symptômes : les utilisateurs peuvent déduire des événements sensibles à partir des noms d’instantanés ; questions gênantes en audit ; « pourquoi y a-t-il un instantané appelé layoff-plan ? »

Correction : standardisez des noms neutres (horodatage + politique), gardez le « sens » dans votre système de changement, pas dans les noms d’instantanés.

cr0x@server:~$ zfs list -t snapshot -o name -r tank/projects | head

Mistake 5: Treating snapshots as a replacement for backups

Symptômes : pas de copies hors site, un ransomware chiffre les données vivantes et les instantanés expirent ou répliquent l’état chiffré, perte catastrophique du pool.

Correction : gardez les instantanés comme rollback local ; utilisez la réplication et des domaines de rétention séparés pour de vraies sauvegardes (et testez les restaurations).

cr0x@server:~$ zfs list -t snapshot -r tank | wc -l

Mistake 6: Letting snapshot retention drift until the pool is full

Symptômes : le pool atteint une forte allocation, la performance se dégrade, les suppressions ne libèrent plus d’espace « comme avant », purge d’instantanés en urgence.

Correction : surveillez la croissance des instantanés, purgez avec intention, et comprenez les clones. Envisagez quota/refquota pour limiter les dégâts par dataset.

cr0x@server:~$ zpool list
cr0x@server:~$ zfs list -o name,used,refer,avail -r tank/projects

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

Checklist A: Safe rollout of snapdir=visible on a user share

1. Choisissez le(s) dataset(s) intentionnellement. Privilégiez les partages d’équipe ou les répertoires personnels avec des permissions stables.
2. Confirmez l’automatisation des instantanés (horaire/journalier) et que la rétention est documentée.
3. Standardisez les noms d’instantanés pour qu’ils soient prévisibles et ennuyeux.
4. Inventoriez les crawlers : indexeurs, antivirus, agents de sauvegarde, outils d’analyse de fichiers, recherche. Planifiez des exclusions pour /.zfs.
5. Activez la visibilité en pilote (un dataset, une équipe).
6. Mesurez l’impact : iostat du pool, expérience client, types de tickets.
7. Publiez un guide de restauration en 2 minutes (« copier depuis .zfs/snapshot/<snap>/chemin »).
8. Étendez progressivement, avec un plan de rollback (snapdir=hidden).

Checklist B: Self-serve restore workflow (user-friendly, low-risk)

1. Trouver le bon point de montage du dataset (éviter la confusion des datasets imbriqués).
2. Parcourir .zfs/snapshot pour la fenêtre temporelle.
3. Localiser le fichier dans l’arbre d’instantané.
4. Le copier dans l’espace vivant avec un nouveau nom d’abord (sécurité).
5. Vérifier le contenu, puis remplacer l’original si nécessaire.

cr0x@server:~$ ls /tank/projects/.zfs/snapshot | tail -5
cr0x@server:~$ cp -av /tank/projects/.zfs/snapshot/auto-20251224-0900/engineering/spec.docx \
> /tank/projects/engineering/spec.docx.restored
cr0x@server:~$ ls -l /tank/projects/engineering/spec.docx*

Checklist C: Audit workflow (prove “what existed when”)

1. Identifier le dataset et le chemin pertinent.
2. Trouver l’instantané le plus proche du temps d’intérêt (zfs list -t snapshot).
3. Vérifier l’existence et les métadonnées dans la vue d’instantané.
4. Si nécessaire, hasher le fichier d’instantané et la copie restaurée pour démontrer l’intégrité (le hashage est une décision opérationnelle ; cela peut être lourd).
5. Enregistrer le nom et l’heure de création de l’instantané comme ancre de preuve.

cr0x@server:~$ zfs list -t snapshot -o name,creation -r tank/projects | tail -5
cr0x@server:~$ ls -l /tank/projects/.zfs/snapshot/auto-20251224-0900/finance/ledger.csv
cr0x@server:~$ sha256sum /tank/projects/.zfs/snapshot/auto-20251224-0900/finance/ledger.csv

FAQ

1) Does snapdir=visible make snapshots accessible to everyone?

Non. Cela rend le répertoire d’instantanés visible dans les listings. L’accès au contenu des instantanés dépend toujours des permissions du système de fichiers et des ACLs.

2) Will enabling it slow down my pool?

Pas directement. Le risque est comportemental : une fois les instantanés visibles, outils et utilisateurs peuvent les parcourir, provoquant des lectures de métadonnées et une charge accrue. Si vous excluez les crawlers et l’appliquez sélectivement, l’impact est en général modéré.

3) Why can users list snapshot names but not open folders inside them?

Parce que lister .zfs/snapshot peut être autorisé tandis que la traversée dans des répertoires protégés est bloquée par les permissions d’exécution des répertoires ou les ACLs. C’est courant dans des datasets aux permissions mixtes.

4) How do I hide snapshots again without deleting anything?

Définissez snapdir=hidden sur le dataset. Les instantanés restent ; ils ne s’affichent simplement plus via .zfs.

cr0x@server:~$ sudo zfs set snapdir=hidden tank/projects

5) Is .zfs present on child datasets too?

Oui, chaque dataset a son propre namespace d’instantanés et des règles d’héritage de propriété. Les datasets imbriqués sont une source fréquente de confusion sur la « mauvaise liste d’instantanés ».

6) Can users delete or modify files inside snapshots?

Non. Le contenu des instantanés est en lecture seule. Les utilisateurs peuvent copier les données vers le système de fichiers vivant s’ils ont la permission d’y écrire.

7) Is this the same as “Previous Versions” in Windows shares?

Non. « Previous Versions » Windows est typiquement implémenté par le serveur SMB qui mappe des instantanés dans cette UI. snapdir=visible expose les instantanés via un répertoire du système de fichiers. Vous pouvez utiliser l’un, l’autre, ou les deux ; testez le comportement des clients attentivement.

8) If I delete a snapshot, will I immediately get space back?

Pas toujours. L’espace est libéré uniquement quand les blocs ne sont plus référencés par aucun instantané, clone, ou le système de fichiers vivant. Les clones sont une raison fréquente pour laquelle la suppression d’un instantané ne récupère pas d’espace.

9) What’s the safest way to let users restore files without giving them too much rope?

Activez la visibilité seulement sur des datasets conçus pour la navigation utilisateur, gardez des noms d’instantanés prévisibles, publiez un workflow de restauration, et assurez-vous que vos crawlers excluent /.zfs. Combinez cela avec des quotas/refquotas pour limiter la croissance dans le pire des cas.

Conclusion

snapdir=visible est un classique de ZFS : une seule propriété qui transforme un primitif de stockage en fonctionnalité orientée utilisateur. L’ingénierie est solide, mais le résultat dépend de la façon dont les humains et les logiciels se comportent une fois la porte ouverte.

Si vous traitez la visibilité des instantanés comme un produit — déploiement ciblé, rétention claire, nommage sensé, exclusions pour les crawlers, et workflow de restauration documenté — vous obtenez des audits plus rapides, moins de tickets de restauration et moins de drames à minuit. Si vous activez partout et partez, vous découvrirez quels outils de votre environnement sont secrètement alimentés par la récursion. En stockage, les données sont prévisibles ; ce sont les utilisateurs et leurs scripts qui maintiennent l’excitation.