Scénarios de catastrophe ZFS : ce qui casse en premier et ce que vous pouvez sauver

janvier 19, 2026 • février 3, 2026 • Lecture : 29 min • Views: 11

Cet article vous a aidé ?

ZFS ne tombe pas généralement en panne avec des feux d’artifice. Il tombe comme la batterie d’un ordinateur portable d’entreprise : lentement, silencieusement, et juste avant la démo.
Un jour un pool devient DEGRADED, puis un scrub commence à « trouver » des choses, puis une importation se fige pendant que votre pager vous informe poliment que dormir est désormais une fonctionnalité héritée.

Ceci est un guide de terrain pour ces moments. Ce n’est pas une visite des fonctionnalités. C’est une carte des falaises : ce qui a tendance à casser en premier, comment le confirmer rapidement, et quelles données vous pouvez encore récupérer — sans faire le classique « je l’ai réparé en le supprimant ».

Comment ZFS “meurt” : la pile de défaillance

ZFS n’est pas une seule chose. C’est un ensemble de promesses imbriquées : checksums, copy-on-write, sémantiques transactionnelles, réplication,
mise en cache et une topologie de stockage qui mélange « disques » et « intention ». Quand le système est stressé, ces promesses échouent dans un ordre prévisible.

1) Le premier à lâcher est généralement l’environnement, pas ZFS

Dans les incidents réels, la première défaillance se situe souvent en dehors du pool :

Alimentation (sous-tensions, alimentations instables, hypothèses d’alimentation double)
Contrôleurs (bugs de firmware HBA, réinitialisations d’expander, oscillations de lien SATA)
Mémoire (non-ECC plus mauvaise chance ; ECC plus DIMM défaillant)
Températures (disques qui font des erreurs sous la chaleur, se mettent en mode throttling, ou tombent carrément)
Humains (le composant le plus compatible ; il marche avec tous les systèmes)

2) Ensuite l’I/O : les pics de latence deviennent des timeouts puis « device removed »

ZFS est conservateur. Lorsqu’un vdev commence à renvoyer des I/O lents ou incohérents, ZFS préfère cesser de lui faire confiance. C’est ainsi que vous obtenez un pool
techniquement toujours en ligne mais pratiquement inutilisable : tout bloque sur quelques membres mourants, la logique de retry s’accumule, et
l’application l’interprète comme « le stockage est en panne ».

3) Les métadonnées deviennent le champ de bataille

Les données utilisateur survivent souvent plus longtemps que l’intégrité des métadonnées. Si le pool ne peut pas lire les structures qui décrivent les datasets, snapshots et
pointeurs de blocs, vos « données » deviennent un entrepôt sans système d’inventaire. C’est pourquoi les vdevs spéciaux et petits dispositifs de métadonnées comptent
plus qu’on ne le pense.

4) Enfin, la confiance s’effondre : erreurs de checksum qui ne peuvent pas s’auto-réparer

Une seule erreur de checksum est un coup de semonce. Un motif d’erreurs de checksum irrécupérables, c’est ZFS qui vous dit qu’il ne trouve pas de copie valide.
En miroir/RAIDZ, cela signifie généralement que vous avez perdu trop de réplicas ou que la parité ne peut pas reconstruire car la surface d’erreur est plus grande que
la redondance.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : « Tout échoue, tout le temps — concevez et opérez comme si c’était normal. » ZFS aide,
mais il n’abroge pas la physique.

Faits intéressants & contexte historique (pourquoi il se comporte ainsi)

Le comportement de ZFS en cas de catastrophe devient plus logique quand on se rappelle d’où il vient et ce qu’il a été conçu pour survivre.

ZFS est né chez Sun au début des années 2000 pour corriger la corruption silencieuse et la douleur d’administration causées par la séparation gestionnaire de volumes + système de fichiers.
Copy-on-write était le point : ZFS écrit de nouveaux blocs puis engage les pointeurs, évitant ainsi les structures « à moitié écrites » après des crashs.
Les checksums sont de bout en bout : ZFS calcule les checksums des données quand elles sont stockées, pas selon ce que le disque prétend. C’est pourquoi il peut détecter la « détériorisation de bits » au lieu de deviner.
Les scrubs n’étaient pas un luxe ; ils étaient une réponse à la corruption réelle que les RAID classiques considéraient comme « données valides ».
Le modèle de pool était une rébellion : au lieu de découper les disques en volumes, on construit un pool et on alloue des datasets. Les admins ont arrêté de jouer au Tetris.
« RAIDZ » existe parce que les write holes existent : les RAID5/6 classiques peuvent produire des stripes incohérents après une perte d’alimentation ; ZFS tente d’éviter cela avec des écritures transactionnelles.
Le design ARC/L2ARC reflète le RAM cher à l’époque : ARC en RAM, L2ARC optionnel sur flash quand le flash est devenu assez bon marché pour importer.
OpenZFS est devenu le plan de continuité après la chute de Sun ; aujourd’hui c’est un projet multiplateforme avec des valeurs par défaut et des flags de fonctionnalité dépendant du système d’exploitation.

Ce qui casse en premier : scénarios de catastrophe courants

Scénario A : Défaillance d’un seul disque en miroir/RAIDZ

C’est la défaillance « normale ». Si votre topologie a de la redondance et que le reste du système est sain, ZFS fait ce qu’on attend : il se dégrade, continue de servir et exige un remplacement.

Ce qui casse en premier ici est généralement la performance, pas la correction. Un vdev RAIDZ dégradé a moins de parallélisme. Un miroir dégradé est à un disque d’un long week-end.

Scénario B : Défaillances multiples de disques pendant un resilver

La fenêtre dangereuse n’est pas « un disque a lâché ». La fenêtre dangereuse, c’est « un disque a lâché et maintenant on martèle les disques restants. »
Resilver et scrub sont lourds. Ils augmentent la charge, la chaleur et les taux d’erreur. Des disques marginaux deviennent honnêtes.

Ce qui casse en premier : les seconds disques, souvent du même lot, même âge, même profil de vibration. Si votre politique d’achat
achète des disques identiques le même jour, félicitations : vous avez construit une défaillance synchronisée.

Scénario C : Réinitialisations de contrôleur/HBA causant une perte transitoire de périphérique

ZFS réagit aux périphériques qui disparaissent. Si un contrôleur se réinitialise et que tous les disques disparaissent un instant, ZFS peut les marquer comme indisponibles.
Selon le timing et le comportement de l’OS, vous pouvez obtenir :

Pool passe en DEGRADED parce qu’un chemin a oscillé
Pool passe en SUSPENDED parce que les erreurs d’I/O ont dépassé les seuils de sécurité
Problèmes d’import après reboot parce que les noms de périphérique ont changé

Ce qui casse en premier : vos hypothèses sur la « défaillance du disque ». Les disques peuvent être corrects. Le bus ne l’est pas.

Scénario D : Perte d’alimentation + cache d’écriture menteur

ZFS est transactionnel, mais il compte toujours sur la pile de stockage pour honorer les flushes. Si un disque ou contrôleur acknowledge des écritures qu’il n’a pas persistées, vous pouvez obtenir des intent logs corrompus, des métadonnées incohérentes, et un pool qui s’importe mais se comporte comme s’il avait une commotion.

Si vous exécutez sync=disabled sur quoi que ce soit que vous prétendiez « important », vous n’optimisez pas ; vous jouez au poker avec l’emploi de quelqu’un d’autre.

Blague #1 : « sync=disabled » c’est comme retirer la ceinture de sécurité de votre voiture pour améliorer l’accélération. Techniquement vrai, stratégiquement discutable.

Scénario E : Défaillance d’un vdev spécial (métadonnées/petits blocs)

Les vdevs spéciaux sont puissants et dangereux. Si vous placez les métadonnées (et possiblement les petits blocs) sur un vdev spécial, vous créez une dépendance : perdez ce vdev, perdez le pool.
Les miroirs aident, mais le rayon d’explosion est réel.

Ce qui casse en premier : la capacité du pool à retrouver quoi que ce soit. Vous pouvez avoir encore la plupart des blocs de données intacts sur les vdevs principaux,
mais vous ne pouvez pas assembler le système de fichiers sans les structures de métadonnées.

Scénario F : Pool presque plein → fragmentation → effondrement « soudain » de la latence

Les pires catastrophes les plus ennuyeuses sont auto-infligées. Les pools au-dessus d’environ ~80–90% d’utilisation (selon recordsize, charge et topologie) se fragmentent.
L’allocation devient coûteuse. Les écritures s’amplifient. Les latences explosent. Les applications expirent. Les gens accusent « la surcharge ZFS » alors que le pool tente d’allouer des blocs comme on emballe un camion de déménagement sans boîtes vides.

Scénario G : Pression mémoire et ARC mal dimensionné dans un monde de voisins bruyants

ZFS adore la RAM. Votre base de données adore aussi la RAM. Votre plateforme de conteneurs adore la RAM. Quand ils se battent, le noyau gagne en tuant quelqu’un.
ZFS sous forte pression mémoire peut thrasher, évincer l’ARC, augmenter les I/O disque, augmenter la latence, augmenter la pression. Une boucle de rétroaction
qui finit par des tickets « le stockage est lent ».

Scénario H : Perte de clé de chiffrement

Le chiffrement natif ZFS est un bel ouvrage. Il est aussi impitoyable. Perdre la clé (ou la phrase de passe + l’emplacement de la clé), et le pool
peut être parfaitement sain tandis que vos données sont parfaitement inaccessibles. Ce n’est pas un bug. C’est le contrat que vous avez signé.

Ce que vous pouvez sauver (et ce que vous ne pourrez probablement pas)

Quand vous pouvez généralement tout sauver

Défaillance d’un seul disque dans un miroir/RAIDZ avec remplacement rapide
Erreurs transitoires de contrôleur qui n’ont pas corrompu les métadonnées (réparer le bus, clear, scrub)
Erreurs au niveau application quand vous avez des snapshots (rollback/clone/restore)
Suppressions accidentelles si des snapshots existent et n’ont pas été vidés

Quand vous pouvez généralement sauver certaines choses

Importations de pool en lecture seule mais panique ou blocage sous charge d’écriture : vous pouvez souvent zfs send les datasets critiques
Quelques erreurs de checksum irrécupérables : vous pouvez parfois copier des datasets/fichiers non affectés, puis reconstruire
Dommages aux métadonnées limités à certains datasets : d’autres datasets peuvent se monter ; priorisez immédiatement les exports

Quand vous sauvez principalement des logs et des leçons

Vdev spécial perdu sans redondance : le pool est généralement irrécupérable en pratique
Plus de membres de vdev perdus que la redondance ne le permet (par ex., RAIDZ1 avec 2 disques en panne)
Clés de chiffrement disparues (pas de clé, pas de données, aucune exception)

Blague #2 : Récupérer des données sans sauvegardes, c’est comme essayer de décramer du pain grillé avec un tournevis. Vous pouvez être très occupé et quand même avoir très faim.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Le chemin le plus rapide vers la raison est de séparer la santé du pool, la santé des périphériques, et le goulot de performance.
Ne commencez pas par des exploits héroïques. Commencez par des faits.

Premier : Le pool est-il sûr à manipuler ?

Vérifiez l’état du pool : zpool status -xv et zpool list. Si vous voyez SUSPENDED, arrêtez et stabilisez.
Confirmez que vous n’êtes pas à court d’espace : zfs list -o name,used,avail,refer,mountpoint. Les pools à 95% créent des « pannes mystérieuses ».
Vérifiez s’il y a un resilver/scrub actif : la sortie de status vous le dira ; s’il est en cours pendant un incident, pensez à suspendre les workloads concurrents.

Deuxième : Est-ce une défaillance disque, bus ou logicielle ?

Regardez dmesg/journal pour des réinitialisations de lien et des timeouts (erreurs sense SATA/SAS, réinitialisations NVMe).
Vérifiez SMART/NVMe pour les périphériques que ZFS signale. Un seul disque défectueux est plausible ; huit « mauvais disques » en même temps est généralement un contrôleur.
Vérifiez la stabilité des IDs de périphérique (chemins by-id). Si les noms de disque ont changé, les importations peuvent devenir étranges.

Troisième : Trouvez rapidement le goulot

Latence I/O : zpool iostat -v 1 — trouvez le vdev avec un wait élevé et un débit faible.
Pression ARC : si l’ARC est minuscule et que les misses sont élevées, vous allez vers le disque.
Pression d’écritures sync : si vous avez un SLOG et qu’il est lent ou mort, les workloads synchrones ramperont.

Tâches pratiques : commandes, sens des sorties et décisions

Ce sont les tâches « faites ceci à 03:17 ». Chacune inclut quoi chercher et quelle décision elle doit déclencher. Les commandes supposent Linux avec OpenZFS ; ajustez pour votre plateforme, mais gardez la logique.

Tâche 1 : Confirmer si quelque chose est vraiment cassé

cr0x@server:~$ sudo zpool status -xv
all pools are healthy

Sens : ZFS ne voit pas de faute au niveau pool. Votre panne est probablement au-dessus de ZFS (application, réseau) ou en dessous (matériel causant de la latence sans erreurs).
Décision : Passez au triage de performance (zpool iostat, ARC, et métriques système) au lieu de remplacer un disque.

Tâche 2 : Lire l’histoire réelle du pool, pas le résumé rassurant

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible.  Otherwise restore the entire pool from backup.
  scan: scrub repaired 0B in 02:11:45 with 3 errors on Thu Dec 26 01:02:10 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     1
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
/tank/data/db/index/segments_12

Sens : Le pool est en ligne, mais au moins un bloc n’a pas pu être reconstruit et un fichier est endommagé.
Décision : Traitez cela comme un incident de données, pas seulement du matériel. Restaurez le fichier depuis la réplication applicative ou les sauvegardes ; ensuite, relancez un scrub et envisagez de remplacer le disque ayant des erreurs CKSUM.

Tâche 3 : Identifier si « READ/WRITE/CKSUM » pointe vers disque, câblage ou mémoire

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            sda     ONLINE       0     0    12
            sdb     ONLINE       0     0     0

Sens : Les erreurs CKSUM sur sda suggèrent de mauvaises lectures depuis ce chemin de périphérique. Cela peut être le disque, le câble/backplane, ou la mémoire lors des lectures (moins fréquent avec ECC).
Décision : Récupérez SMART et les logs du noyau pour sda ; si des réinitialisations de lien apparaissent, suspectez câblage/HBA. Si SMART montre des secteurs réalloués/en attente, remplacez le disque.

Tâche 4 : Vérifier si le pool s’étrangle par sa capacité

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,health
NAME   SIZE   ALLOC   FREE  FRAG  HEALTH
tank  43.5T   40.9T  2.6T   73%  ONLINE

Sens : 73% de fragmentation avec peu d’espace libre est un piège de performance.
Décision : Arrêtez de discuter des tunables et créez de l’espace. Supprimez les snapshots anciens, déplacez les données froides, ou étendez le pool. Si la charge est très aléatoire en écritures, envisagez d’ajouter des vdevs, pas de remplacer des disques par des plus gros un par un.

Tâche 5 : Trouver le vdev chaud sous charge

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        40.9T  2.6T     210    980  34.1M  112M
  raidz2-0  40.9T  2.6T     210    980  34.1M  112M
    sda         -      -      35    165  5.6M   19M
    sdb         -      -      36    164  5.5M   19M
    sdc         -      -      34    166  5.7M   18M
    sdd         -      -      35    321  5.5M   37M
    sde         -      -      35      0  5.6M     0
    sdf         -      -      35    164  5.6M   19M

Sens : Un disque (sdd) prend une part disproportionnée des écritures ; cela peut être une distribution normale, des retries, ou un problème de chemin.
Décision : Corrélez avec les compteurs d’erreurs de zpool status et les logs du noyau. Si un disque a une latence/timeouts élevés, remplacez-le ou reseatez-le.

Tâche 6 : Confirmer si ZFS bride à cause d’erreurs (I/O suspendues)

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: SUSPENDED
status: One or more devices are faulted in response to persistent errors.
action: Make sure the affected devices are connected, then run 'zpool clear'.
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     FAULTED     75     0     0  too many errors

Sens : ZFS a arrêté les I/O pour éviter plus de dommages ou de blocages.
Décision : Ne faites pas « clear and pray » à répétition. Réparez d’abord le problème de périphérique/chemin sous-jacent (remplacez disque, réparez HBA/backplane), puis zpool clear et scrub.

Tâche 7 : Vérifier l’identité du périphérique pour éviter de remplacer le mauvais disque

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sdc|WDC|SEAGATE' | head
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-WDC_WD80... -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-WDC_WD80... -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-WDC_WD80... -> ../../sdc

Sens : Vous pouvez mapper les noms logiques de périphérique à des IDs stables.
Décision : Utilisez les chemins by-id pour les remplacements et la documentation. Si votre runbook dit « remplacer sdc », mettez-le à jour ; il mentira dès que vous redémarrerez.

Tâche 8 : Vérifier SMART pour les marqueurs « il meurt »

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep 'Reallocated|Pending|Offline_Uncorrectable|CRC|SMART overall'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       8
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       8
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Sens : « PASSED » n’est pas une lettre de non-culpabilité. Les secteurs en attente et non récupérables sont de vrais problèmes.
Décision : Remplacez le disque. Si les erreurs CRC étaient élevées, suspectez d’abord câblage/backplane.

Tâche 9 : Remplacer un périphérique défaillant de manière sûre

cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-WDC_WD80_BAD /dev/disk/by-id/ata-WDC_WD80_NEW
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
scan: resilver in progress since Thu Dec 26 01:22:01 2025
        1.23T scanned at 2.10G/s, 412G issued at 703M/s, 40.9T total
        412G resilvered, 0.98% done, 16:10:12 to go

Sens : Le resilver a démarré ; l’estimation de temps est souvent une fiction optimiste.
Décision : Réduisez la charge si vous le pouvez. Surveillez d’éventuelles erreurs supplémentaires. Si d’autres disques commencent à montrer des erreurs pendant le resilver, cessez de prétendre que c’est un événement mono-disque et réévaluez le matériel.

Tâche 10 : Confirmer le comportement du scrub et interpréter les compteurs d’erreurs

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
scan: scrub in progress since Thu Dec 26 02:01:44 2025
        7.88T scanned at 1.05G/s, 1.12T issued at 153M/s, 40.9T total
        0B repaired, 2.74% done, 06:12:10 to go

Sens : Le scrub vérifie les checksums. « 0B repaired » est bon pour l’instant ; s’il termine avec repaired >0 et sans erreurs permanentes, la redondance a fonctionné.
Décision : Si le scrub trouve des erreurs permanentes, identifiez les fichiers affectés et restaurez-les depuis snapshots/sauvegarde. N’ignorez pas les « quelques » erreurs de checksum.

Tâche 11 : Problèmes de montage — voyez ce que ZFS pense être monté

cr0x@server:~$ zfs list -o name,mounted,mountpoint,canmount
NAME                 MOUNTED  MOUNTPOINT     CANMOUNT
tank                 yes      /tank          on
tank/data             no      /tank/data     on
tank/data/db          no      /tank/data/db  on

Sens : Les datasets sont présents mais non montés. Cela peut être dû à des dépendances, chiffrement verrouillé, ou conflit de point de montage.
Décision : Vérifiez l’état de chiffrement et les erreurs dans zpool status et les logs système. Tentez un montage explicite et capturez l’erreur.

Tâche 12 : Triage chiffrement — pouvez-vous charger les clés ?

cr0x@server:~$ zfs get -H -o name,property,value encryption,keylocation,keystatus tank/data
tank/data	encryption	aes-256-gcm
tank/data	keylocation	file:///root/keys/tank_data.key
tank/data	keystatus	unavailable
cr0x@server:~$ sudo zfs load-key -a
Enter passphrase for 'tank/data': 
cr0x@server:~$ zfs get -H -o name,property,value keystatus tank/data
tank/data	keystatus	available

Sens : Le dataset était chiffré et verrouillé ; il est maintenant déverrouillé.
Décision : Si vous ne pouvez pas charger les clés, arrêtez. Ne détruisez ni ne recréez rien. Votre incident est désormais « gestion de clés », pas « fiabilité du stockage ».

Tâche 13 : Importer un pool en sécurité après un crash (d’abord en lecture seule)

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          raidz2-0  ONLINE
            sda     ONLINE
            sdb     ONLINE
            sdc     ONLINE
            sdd     ONLINE
            sde     ONLINE
            sdf     ONLINE
cr0x@server:~$ sudo zpool import -o readonly=on tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
status: The pool is imported in read-only mode.

Sens : Vous avez importé sans permettre les écritures. Cela réduit le risque pendant que vous évaluez.
Décision : Si vous suspectez une corruption, gardez en lecture seule et commencez à extraire les datasets critiques via zfs send ou une copie fichier vers une destination sûre.

Tâche 14 : Trouver ce qui a changé récemment (snapshots, holds, clones)

cr0x@server:~$ zfs list -t snapshot -o name,creation -S creation | head
NAME                         CREATION
tank/data@auto-2025-12-26-0100  Thu Dec 26 01:00 2025
tank/data@auto-2025-12-26-0000  Thu Dec 26 00:00 2025
tank/data@auto-2025-12-25-2300  Wed Dec 25 23:00 2025

Sens : Vous avez des snapshots récents ; c’est bien. Si vous n’en avez pas, votre futur vous prépare une conversation sérieuse.
Décision : Si l’incident est « mauvais déploiement qui a supprimé des choses », restaurez depuis snapshot (clone ou rollback). Si l’incident est une corruption, utilisez les snapshots pour zfs send vers un nouveau pool.

Tâche 15 : Répliquez d’abord les données les plus précieuses

cr0x@server:~$ sudo zfs send -v tank/data@auto-2025-12-26-0100 | sudo zfs receive -u rescue/data
send from @auto-2025-12-26-0100 estimated size is 3.12T
total estimated size is 3.12T
TIME        SENT   SNAPSHOT
00:00:10   5.28G   tank/data@auto-2025-12-26-0100

Sens : Vous streamez un snapshot cohérent vers un pool/dataset de secours, plutôt que d’essayer de « réparer sur place ».
Décision : Si vous voyez des erreurs de send, notez le dataset et ajustez la priorité. Vous pouvez souvent sauver d’autres datasets même si un est endommagé.

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

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne exploitait une plateforme de VM sur ZFS. Deux nœuds de stockage, chacun avec un pool RAIDZ2. Il y avait de la réplication, mais « au mieux des efforts ».
L’hypothèse de l’équipe — jamais écrite, toujours répétée — était que RAIDZ2 signifiait « nous pouvons perdre deux disques et être tranquilles. »

Un vendredi, un pool est passé en DEGRADED. Un disque a été remplacé. Le resilver a commencé. Pendant le resilver, un second disque a commencé à logger des timeouts.
Tout le monde était calme : « On est toujours dans les limites de RAIDZ2. » Puis le contrôleur s’est réinitialisé. Tous les disques sont tombés un instant, sont revenus, et ZFS a marqué un troisième
périphérique comme faulted en raison des erreurs accumulées. Le pool est passé de « ok » à SUSPENDED en un clin d’œil.

La mauvaise hypothèse n’était pas à propos de la mathématique de parité. C’était l’idée que les défaillances sont indépendantes et que « perdre » un périphérique revient à « un disque physiquement mort ».
En réalité, un HBA ou un backplane défaillant peut faire paraître plusieurs disques comme morts simultanément. ZFS se fiche de la raison pour laquelle le périphérique a cessé de répondre ; il sait seulement qu’il a cessé.

La récupération n’a pas été héroïque. Ils ont importé en lecture seule, commencé immédiatement des zfs send pour les datasets VM critiques vers l’autre nœud,
et accepté que certaines VMs basse priorité seraient reconstruites plus tard depuis des images. La correction a été ennuyeuse : nouveau firmware HBA, discipline de câblage améliorée,
et une politique « toute anomalie multi-disques est d’abord bus jusqu’à preuve du contraire. »

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

Un autre atelier exploitait du NFS sensible à la latence sur ZFS. Ils ont benché, vu de gros gains en désactivant sync, et l’ont déployé en production.
La justification sonnait raisonnable : « L’app est déjà résiliente, et on a des UPS. »

Des mois plus tard, un événement d’alimentation a frappé. Pas une panne complète — juste une sous-tension qui a fait redémarrer un nœud. Le pool s’est importé. Les services ont démarré. Les utilisateurs ont remarqué
des corruptions de fichiers étranges : petites, aléatoires, non reproductibles. Le genre de problème qui fait tout le monde douter de la réalité.

Ce qui s’est passé : « sync disabled » a permis au système d’acquitter des écritures avant qu’elles ne soient durables. L’UPS n’a pas aidé parce que le mode de défaillance
n’était pas tant « alimentation coupée » que « matériel qui se comporte de façon imprévisible sous alimentation instable ». ZFS a respecté le contrat qu’on lui avait donné ; le contrat avait été réécrit par un flag de tuning.

La correction a été douloureuse mais simple : restaurer les datasets affectés depuis des snapshots/replications connus bons, réactiver sync, et ajouter un SLOG
dimensionné et spécifié pour des écritures synchrones soutenues. La leçon a été retenue. Ils font toujours des benchs. Ils benchent juste la réalité, pas une fantaisie.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un fournisseur SaaS avait un pool ZFS hébergeant des uploads clients et des artefacts de build internes. Leurs données n’étaient pas « vie ou mort », mais le genre de données qui génère du churn quand elles disparaissent. Ils faisaient des scrubs hebdomadaires et une réplication de snapshots quotidienne vers un système séparé. Pas de drame, pas de slides exécutifs. Juste de la maintenance calendaire.

Une semaine, le scrub a rapporté une poignée d’erreurs de checksum qu’il a réparées. L’ingénieur d’astreinte a quand même ouvert un ticket, car « réparé » n’est pas la même chose que « ok ». SMART a montré un disque avec des secteurs en attente croissants. Le disque a été remplacé pendant les heures ouvrables. Personne n’a remarqué.

Deux semaines plus tard, un autre disque du même châssis a lâché violemment pendant une charge de pointe. Le resilver a commencé. Un autre disque a commencé à vaciller. Cette fois,
il y avait un vrai risque de dépasser les limites de redondance si les choses empirent.

L’équipe n’a pas joué au poulet avec le resilver. Ils ont réduit la charge, arrêté temporairement les écritures non essentielles, et confirmé la fraîcheur de la réplication.
Quand le pool a survécu, tant mieux. S’il n’avait pas survécu, ils étaient déjà prêts à basculer. La pratique ennuyeuse n’était pas seulement le scrub ; c’était d’avoir
un plan pour arrêter de creuser quand le trou devenait profond.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : Le pool est ONLINE mais tout est lent

Cause racine : Pool presque plein + fragmentation ; ou un périphérique lent/défaillant causant un engorgement de file.
Correction : Vérifiez zpool list pour espace libre/frag ; lancez zpool iostat -v 1 pour trouver le périphérique en retard ; libérez de l’espace et remplacez/réparez le membre lent.

2) Symptom : Beaucoup de disques « échouent » en même temps

Cause racine : Réinitialisation HBA, expander/backplane, problème d’alimentation, ou câblage.
Correction : Inspectez les logs système pour réinitialisations/timeout de lien ; reseatez/remplacez HBA ou backplane ; ne remplacez pas les disques en masse tant que vous n’avez pas prouvé qu’ils sont mauvais.

3) Symptom : Les erreurs CKSUM augmentent, SMART a l’air correct

Cause racine : Intégrité du chemin (câbles), problèmes de contrôleur, ou corruption mémoire.
Correction : Vérifiez les compteurs UDMA CRC, reseatez les câbles, testez la mémoire, déplacez le disque sur un autre port/contrôleur et voyez si les erreurs suivent le disque ou le chemin.

4) Symptom : Le scrub trouve des « erreurs permanentes »

Cause racine : ZFS ne peut pas reconstruire au moins un bloc à partir de la redondance.
Correction : Restaurez les fichiers/datasets affectés depuis snapshot/sauvegarde/réplica ; après restauration, relancez un scrub. Traitez-le comme un incident d’intégrité des données.

5) Symptom : L’import bloque ou prend une éternité

Cause racine : Un ou plusieurs périphériques timeout ; lectures extrêmement lentes pendant la relecture ; fort churn metadata.
Correction : Importez en lecture seule ; isolez les disques défaillants (SMART/logs) ; essayez d’importer sur un système avec des HBAs connus bons ; priorisez l’export des données critiques.

6) Symptom : Un dataset ne se monte pas après reboot

Cause racine : Clé de chiffrement non chargée ; conflit de point de montage ; canmount=off ; ou propriétés de dataset corrompues/bloquées.
Correction : Vérifiez zfs get keystatus, zfs list -o mounted,canmount,mountpoint, et corrigez clés/propriétés ; montez explicitement et capturez les erreurs.

7) Symptom : Le resilver est douloureusement lent

Cause racine : Charge concurrente élevée ; disques SMR ; disque de remplacement lent ; mismatch ashift ; goulot du contrôleur.
Correction : Réduisez la charge, vérifiez le type de disque, regardez zpool iostat pour le débit par disque ; ne « tunez » pas aveuglément en augmentant des tunables — trouvez le limiteur.

8) Symptom : Tout est mort après l’ajout d’un vdev spécial

Cause racine : Le vdev spécial n’était pas redondant ou pas surveillé ; il a échoué et a pris les métadonnées avec lui.
Correction : S’il est parti, les options de récupération sont limitées. Prévenez cela la prochaine fois : mirrorisez les vdevs spéciaux, surveillez-les comme si votre emploi en dépendait (parce que c’est le cas), et traitez-les comme des dispositifs tier-0.

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

Checklist : Quand un pool passe en DEGRADED

Capturez la sortie zpool status -v pour le dossier d’incident.
Vérifiez si un resilver/scrub est en cours ; décidez de réduire la charge.
Validez capacité/fragmentation : zpool list, zfs list.
Mappez les noms de périphérique aux by-id et emplacements physiques avant de toucher le matériel.
Récupérez SMART/NVMe et vérifiez les logs système pour réinitialisations de lien.
Remplacez le composant défaillant (disque vs câble vs HBA) en vous basant sur les preuves.
Surveillez le resilver ; guettez de nouvelles erreurs sur d’autres membres.
Scrub après la fin du resilver.
Si des erreurs permanentes sont reportées : restaurez les fichiers/datasets affectés depuis des sources connues bonnes.

Checklist : Quand vous voyez des erreurs permanentes de checksum

Arrêtez d’écrire si possible ; envisagez d’importer en lecture seule si vous pouvez redémarrer en toute sécurité.
Identifiez les fichiers affectés depuis zpool status -v.
Décidez de la source de restauration : snapshots, réplication, reconstruction applicative, ou sauvegardes.
Restaurez et vérifiez l’intégrité (checks applicatifs, hash, ou validation spécifique au domaine).
Relancez un scrub ; si les erreurs persistent, suspectez des dommages silencieux supplémentaires et escaladez vers une migration de pool.

Checklist : Quand la performance s’effondre mais la santé semble OK

Vérifiez le remplissage du pool et la fragmentation.
Lancez zpool iostat -v 1 et trouvez le device/vdev le plus lent.
Vérifiez la pression sur les écritures sync et la santé du SLOG (si utilisé).
Vérifiez la pression mémoire et le swapping ; la « lenteur » du stockage peut être une guerre de RAM.
Recherchez l’activité en arrière-plan : scrub/resilver, destructions de snapshot, réceptions de réplication.
Corrigez le goulot que vous pouvez prouver. Ne commencez pas par tuner.

FAQ

1) Qu’est-ce qui échoue réellement en premier dans la plupart des catastrophes ZFS ?

L’environnement : alimentation, contrôleurs, câblage, ou changements humains. ZFS est souvent le messager qui refuse de mentir à ce sujet.

2) Les erreurs de checksum signifient-elles toujours un disque mort ?

Non. Elles peuvent venir du média disque, mais aussi du câblage/backplane, de problèmes de contrôleur, ou de corruption mémoire. Utilisez SMART plus les logs noyau pour distinguer.

3) Dois-je lancer un scrub pendant un incident ?

Si le pool est stable mais que vous suspectez une corruption latente, un scrub est diagnostic et correctif. Si le matériel est en train de lâcher activement, le scrub peut accélérer l’effondrement. Stabilisez d’abord.

4) RAIDZ2 est-il « suffisamment sûr » pour les gros disques ?

C’est plus sûr que RAIDZ1, mais la sécurité dépend du temps de rebuild, de la charge, et des défaillances corrélées. Les miroirs rebuildent plus vite ; RAIDZ économise de l’espace. Choisissez selon vos objectifs de récupération, pas votre tableur.

5) Puis-je importer un pool en lecture seule pour sauver des données ?

Oui, et vous devriez souvent le faire. zpool import -o readonly=on réduit le risque pendant que vous évaluez et extrayez des données.

6) Quel est le mode de défaillance ZFS le plus irrécupérable ?

La perte des clés de chiffrement est absolue. La perte d’un vdev spécial non redondant est presque aussi grave. Dans les deux cas, le pool peut être « sain » et néanmoins inutilisable.

7) Ajouter un SLOG rend-il mon pool plus sûr ?

Cela peut rendre les écritures synchrones plus rapides et prévisibles. Cela ne remplace pas les sauvegardes, et un SLOG mal spécifié peut devenir un problème de performance ou de fiabilité.

8) Pourquoi ZFS devient-il lent quand le pool est presque plein ?

ZFS alloue des blocs à travers l’espace libre ; quand l’espace libre est rare et fragmenté, l’allocation devient coûteuse et l’amplification d’écriture augmente. La solution est plus d’espace, pas plus d’espoir.

9) Dois-je jamais utiliser `sync=disabled` ?

Seulement lorsque la perte de données est acceptable et explicitement convenue. Pour la plupart des systèmes de production, c’est un piège à la belle ligne de benchmark.

10) Puis-je « clear » les erreurs et passer à autre chose ?

Vous pouvez effacer des compteurs, pas la réalité. Si les erreurs proviennent d’un événement transitoire et que les scrubs reviennent propres, très bien. Si les erreurs continuent d’augmenter, vous masquez un défaut actif.

Prochaines étapes que vous pouvez faire cette semaine

Si vous voulez moins de catastrophes ZFS, faites moins de magie et plus de routine. ZFS récompense la compétence ennuyeuse.

Planifiez des scrubs et examinez les résultats comme s’ils comptaient. Parce que c’est le cas.
Établissez une politique de remplacement basée sur les tendances SMART et l’âge, pas seulement sur la panne.
Passez aux noms de périphérique stables (by-id) dans les configs de pool et les runbooks.
Testez l’import lecture seule et la restauration de snapshot sur un clone non-productions. N’attendez pas l’incident pour découvrir que la sauvegarde est « théorique ».
Faites de la gestion d’espace une métrique de premier ordre : alertez au-dessus de 80–85% de pool et sur les anomalies de croissance des snapshots.
Auditez les vdevs spéciaux et les dispositifs log : assurez redondance, surveillance et matériel approprié.
Rédigez l’ordre de triage (santé du pool → santé du périphérique/chemin → goulot de performance) et faites-le suivre par l’astreinte.

L’objectif n’est pas de ne jamais voir DEGRADED. L’objectif est de le voir tôt, de répondre calmement, et de ne jamais avoir à apprendre ce que « erreurs permanentes » vous fait ressentir au creux de l’estomac.