Récupération ZFS : impossible d’importer le pool ? Procédure calme et reproductible

État d’esprit : préserver les preuves, réduire les écritures

Quand un pool ne s’importe pas, vous êtes en situation de forensique déguisée en incident. Vos objectifs sont :

• Ne pas empirer la situation. Réduisez les écritures sur les disques affectés jusqu’à ce que vous compreniez ce qui s’est passé.
• Capturer l’état. Sauvegardez les sorties de commandes. Copiez les logs. Notez la chronologie.
• Ne faire qu’un changement à la fois. Si vous activez plusieurs options et que « ça marche », vous ne saurez pas quel changement était déterminant ni quel risque vous avez accepté.

De plus : traitez les options « force » comme une tronçonneuse. Outil utile, mais on ne le jongle pas dans la salle serveurs.

Une citation opérationnelle à garder sur un post-it : « L’espoir n’est pas une stratégie. » — Gene Kranz

Petite blague #1 : ZFS ne s’importe pas parce qu’il se sent prudent aujourd’hui. Pareil, ZFS. Pareil.

Règle stricte : commencer en lecture seule dès que possible

Si votre premier import réussi est en lecture/écriture et que vous vous êtes trompé sur le mode de défaillance, vous pouvez avancer la métadonnée vers une nouvelle réalité pire. Préférez un import en lecture seule pour l’inspection initiale. Vous pourrez toujours monter en écriture ensuite.

Que signifie réellement « ne s’importe pas »

Cette expression recouvre plusieurs symptômes :

• zpool import affiche le pool, mais l’import échoue avec des erreurs d’E/S.
• zpool import n’affiche pas le pool du tout.
• L’import « bloque » (en réalité coincé dans des retries d’E/S ou en attente de périphériques lents).
• L’import fonctionne, mais les datasets ne se montent pas ou le pool est immédiatement suspendu.
• Le mauvais hôte importe le pool (accès multi-hôte, SAN, catastrophes JBOD partagées).

La procédure dépend du cas. On triage donc rapidement.

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

Voici la séquence « arrêtez de scroller, commencez à vérifier ». Le but est d’identifier le goulot rapidement : découverte des périphériques, santé des périphériques, métadonnées du pool, ou montages/clefs ?

Premier : le système voit-il les disques de manière fiable ?

• Vérifiez les logs du noyau pour des resets/timeouts.
• Confirmez l’identité stable des périphériques : by-id, WWN ou IDs GPT.
• Assurez-vous que le HBA/contrôleur voit le nombre de disques attendu.

Si l’OS ne voit pas proprement les disques, ZFS n’est pas le problème. ZFS est juste le premier témoin honnête.

Second : est-ce que zpool import voit le pool, et que dit-il ?

• Si le pool apparaît : lisez attentivement le texte d’état, en particulier « UNAVAIL », « was /dev/… », « insufficient replicas » et le dernier TXG.
• Si le pool n’apparaît pas : scannez manuellement les chemins, vérifiez la confusion du cachefile et envisagez des dommages d’étiquette.

Troisième : importer en mode le plus sûr viable

• Essayez d’abord un import en lecture seule (-o readonly=on).
• Ensuite seulement, envisagez les flags de rewind/rollback (-F avec ou sans -X), et seulement après avoir bien compris ce que vous sacrifiez.
• Si le chiffrement est en jeu, séparez « import du pool » et « montage du dataset » : les clefs peuvent bloquer les montages même si le pool est importé.

Faits et contexte intéressants (pourquoi ZFS se comporte ainsi)

• ZFS stocke plusieurs labels par périphérique. Chaque disque a typiquement des labels près du début et de la fin, d’où la possibilité de récupération même avec des dommages partiels aux labels.
• Les imports de pool sont basés sur des transactions. ZFS progresse via des TXG (transaction groups). Les opérations de rewind consistent à sélectionner un TXG antérieur cohérent.
• Les « uberblocks » sont les miettes de pain. ZFS écrit plusieurs uberblocks ; la logique d’import choisit le meilleur bloc valide trouvé sur les périphériques.
• OpenZFS est la lignée vivante. ZFS a été créé chez Sun Microsystems, puis poursuivi comme OpenZFS sur illumos, FreeBSD et Linux, avec des feature flags gérant la compatibilité.
• Les feature flags ne sont pas cosmétiques. Un pool avec des flags récents peut refuser de s’importer sur un système plus ancien, même si les disques sont sains.
• ZFS s’efforce d’éviter le split-brain. Le « hostid » du pool et les comportements multihost existent parce qu’importer le même pool sur deux machines peut le corrompre rapidement.
• L’auto-réparation nécessite de la redondance. Les checksums détectent la corruption, mais sans mirrors/RAIDZ, ZFS ne peut pas toujours réparer automatiquement.
• L’import peut être lent par conception. Avec beaucoup de disques ou du matériel instable, ZFS peut sonder les labels et retenter des E/S ; cela peut ressembler à un blocage alors qu’il est scrupuleux.

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

Voici les tâches pratiques que j’exécute à peu près dans cet ordre. Chaque point inclut ce qu’il faut rechercher et quelle décision il entraîne. Exécutez en root ou avec sudo. Sauvegardez les sorties dans un fichier si vous êtes en conférence avec d’autres équipes.

Task 1: Capturez l’évidence évidente : que pense ZFS maintenant ?

cr0x@server:~$ zpool status -v
no pools available

Ce que cela signifie : Rien n’est importé. Ce n’est pas encore un diagnostic ; c’est un point de départ.

Décision : Passez à la découverte : le système peut-il voir le pool sur disque ?

Task 2: Lister les pools importables (et ne pas ignorer le texte)

cr0x@server:~$ zpool import
   pool: tank
     id: 1234567890123456789
  state: UNAVAIL
 status: One or more devices are unavailable.
 action: The pool cannot be imported. Attach the missing devices and try again.
   see: zpool(8)
 config:

        tank        UNAVAIL  insufficient replicas
          raidz1-0  UNAVAIL  insufficient replicas
            sda     ONLINE
            sdb     ONLINE
            sdc     UNAVAIL  cannot open
            sdd     ONLINE

Ce que cela signifie : ZFS voit les métadonnées du pool et vous indique précisément pourquoi il n’importe pas : réplications insuffisantes parce qu’un vdev manque un membre (RAIDZ1 tolère une perte ; il peut s’agir de plus d’un, ou du périphérique manquant qui est présent mais injoignable).

Décision : Arrêtez d’essayer des flags aléatoires. Rétablissez d’abord la visibilité des périphériques : trouvez pourquoi sdc ne peut pas s’ouvrir.

Task 3: Confirmez l’identité du périphérique (ne faites pas confiance à /dev/sdX)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ata-|wwn-' | head
lrwxrwxrwx 1 root root  9 Feb  4 09:11 ata-SAMSUNG_MZ7LM960HMJP-00005_S4X9NX0M123456 -> ../../sda
lrwxrwxrwx 1 root root  9 Feb  4 09:11 ata-SAMSUNG_MZ7LM960HMJP-00005_S4X9NX0M123457 -> ../../sdb
lrwxrwxrwx 1 root root  9 Feb  4 09:11 ata-SAMSUNG_MZ7LM960HMJP-00005_S4X9NX0M123458 -> ../../sdd

Ce que cela signifie : Il manque une entrée by-id attendue, ou elle pointe vers un endroit inattendu. C’est souvent un problème de câblage/HBA, un disque mort, ou un disque qui a changé de mode/namespace.

Décision : Si un disque est absent au niveau OS, aucun flag ZFS ne le fera réapparaître. Consultez les logs du noyau et l’état du contrôleur.

Task 4: Triage des logs du noyau pour erreurs d’E/S et resets

cr0x@server:~$ dmesg -T | egrep -i 'error|reset|timeout|sas|scsi|nvme' | tail -n 20
[Mon Feb  4 09:08:12 2026] sd 6:0:12:0: [sdc] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Mon Feb  4 09:08:12 2026] sd 6:0:12:0: [sdc] Sense Key : Hardware Error [current]
[Mon Feb  4 09:08:12 2026] sd 6:0:12:0: [sdc] Add. Sense: Internal target failure
[Mon Feb  4 09:08:13 2026] mpt3sas_cm0: log_info(0x31120405): originator(PL), code(0x12), sub_code(0x0405)
[Mon Feb  4 09:08:14 2026] scsi 6:0:12:0: rejecting I/O to offline device

Ce que cela signifie : Le disque ou le chemin échoue au niveau du transport. ZFS a raison de refuser l’import si la redondance est insuffisante.

Décision : Réparez d’abord le matériel : reseat, remplacer ou déplacer le disque/chemin. Si c’est un SAN/JBOD à double chemin, vérifiez la configuration multipath.

Task 5: Vérifiez que vous êtes sur la bonne version/features OpenZFS

cr0x@server:~$ zpool upgrade -v | head -n 12
This system supports ZFS pool feature flags.

The following features are supported:

FEAT DESCRIPTION
async_destroy                        Destroy filesystems asynchronously.
bookmarks                           ZFS bookmarks.
embedded_data                       Blocks which compress very well use even less space.

Ce que cela signifie : Cet hôte supporte les feature flags en général, mais cela ne confirme pas les flags exacts du pool.

Décision : Si le pool a été importé pour la dernière fois sur un système plus récent, vous devrez peut-être l’importer là-bas (ou mettre à jour ce système). Les problèmes de mismatch apparaissent souvent comme « unsupported feature » à l’import.

Task 6: Obtenez une sortie détaillée du scan d’import (l’histoire du pool)

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -N -f tank
cannot import 'tank': one or more devices is currently unavailable

Ce que cela signifie : Même en scannant des chemins stables et en évitant les cachefiles obsolètes, un vdev est manquant.

Décision : Si la redondance le permet, vous pourriez importer en état dégradé. Sinon, arrêtez et récupérez le(s) périphérique(s) manquant(s) d’abord.

Task 7: Voir si ZFS est juste en attente (triage d’un « blocage » d’import)

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -N -f tank

Ce que cela signifie : Aucune sortie et aucun prompt peuvent vouloir dire que l’import est bloqué à faire des E/S. Ne supposez pas que c’est mort ; supposez que c’est bloqué.

Décision : Dans un autre terminal, confirmez si le processus est actif et si des périphériques sont en timeout.

cr0x@server:~$ ps -eo pid,etime,cmd | egrep 'zpool import|PID'
  PID     ELAPSED CMD
 8421       02:14 zpool import -d /dev/disk/by-id -o cachefile=none -N -f tank

Décision : Si le temps écoulé augmente et que les logs montrent des retries/timeouts, vous avez un problème de chemin matériel. S’il n’y a pas d’erreurs d’E/S, vous pourriez avoir un très grand pool et un sondage de labels lent ; soyez patient mais surveillez les métriques.

Task 8: Vérifiez les E/S actives et identifiez le périphérique lent

cr0x@server:~$ iostat -x 1 5
Linux 6.6.0 (server)  02/04/2026  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.02    0.00    2.31   35.44    0.00   61.23

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
sda              1.0      32.0     0.0    0.0   12.0    32.0       0.0      0.0     0.0    0.01    2.0
sdb              1.0      32.0     0.0    0.0   10.0    32.0       0.0      0.0     0.0    0.01    2.0
sdc              0.0       0.0     0.0    0.0    0.0     0.0       0.0      0.0     0.0    0.00    0.0
sdd              1.0      32.0     0.0    0.0   11.0    32.0       0.0      0.0     0.0    0.01    2.0

Ce que cela signifie : Un iowait élevé avec un périphérique ne montrant rien peut indiquer qu’il ne répond pas du tout, ou que le noyau l’a mis hors ligne. Alternativement, un périphérique avec 100% d’utilisation et un await énorme le ralentit pendant l’import.

Décision : Si un périphérique est hors ligne/non réactif, réparez-le. Si un périphérique est simplement lent, vous pouvez parfois compléter un import en lecture seule pour extraire des données avant de le remplacer.

Task 9: Tentez un import en lecture seule, sans montage (import sûr en premier)

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -o readonly=on -N tank
cannot import 'tank': one or more devices is currently unavailable

Ce que cela signifie : La lecture seule ne contourne pas les périphériques manquants. Elle réduit juste le risque quand l’import est possible.

Décision : Si la redondance existe (mirror/RAIDZ avec perte tolérable), utilisez l’import dégradé. Sinon, arrêtez et récupérez le disque/chemin manquant.

Task 10: Tenter un import dégradé quand la redondance le permet

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -o readonly=on -N -f -o failmode=continue tank
cannot import 'tank': insufficient replicas

Ce que cela signifie : ZFS vous dit qu’il n’existe pas de manière sûre d’assembler des données cohérentes parce que le vdev ne peut pas être reconstruit. C’est le message « il vous manque trop de choses ».

Décision : Récupération matérielle ou restauration depuis une sauvegarde. N’essayez pas d’options astucieuses en espérant des miracles ; vous pourriez seulement créer de nouveaux dégâts.

Task 11: Si le pool s’importe mais que les datasets ne se montent pas, vérifiez le chiffrement et les paramètres de montage

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -N -f vault
cr0x@server:~$ zfs list
NAME            USED  AVAIL  REFER  MOUNTPOINT
vault           1.2T   800G    96K  /vault
vault/secure     0B     800G    96K  /vault/secure

Ce que cela signifie : Le pool est importé, les datasets sont visibles, mais pas forcément montés. Si le chiffrement est activé, les montages peuvent échouer tant que les clefs ne sont pas chargées.

Décision : Vérifiez le statut des clefs, puis chargez-les et montez volontairement.

cr0x@server:~$ zfs get -H -o name,property,value keystatus vault/secure
vault/secure	keystatus	unavailable

Décision : Chargez la clef. Si vous ne l’avez pas, arrêtez et escaladez ; le bruteforce n’est pas une option.

cr0x@server:~$ zfs load-key -r vault/secure
Enter passphrase for 'vault/secure':
cr0x@server:~$ zfs mount -a
cr0x@server:~$ mount | grep vault
vault on /vault type zfs (ro,relatime,xattr,noacl)
vault/secure on /vault/secure type zfs (rw,relatime,xattr,noacl)

Task 12: Si l’import se plaint d’un « pool actif » ou du mauvais hôte, vérifiez hostid et la situation multihôte

cr0x@server:~$ zpool import
   pool: prod
     id: 9876543210987654321
  state: ONLINE
 status: The pool is currently imported by another system.
 action: The pool must be exported from the other system, then imported.
   see: zpool(8)
 config:

        prod        ONLINE
          mirror-0  ONLINE
            wwn-0x5000c500a1b2c3d4  ONLINE
            wwn-0x5000c500a1b2c3d5  ONLINE

Ce que cela signifie : ZFS pense qu’un autre hôte le possède. Parfois c’est vrai (étagère partagée), parfois c’est un état obsolète après un crash, parfois c’est un split-brain en attente.

Décision : Confirmez que l’autre hôte est vraiment down ou a exporté le pool. Si vous n’êtes pas sûr à 100 %, arrêtez-vous. La corruption multi-hôte est rapide et humiliante.

Task 13: Si vous devez forcer l’import, faites-le d’abord en lecture seule

cr0x@server:~$ zpool import -f -o readonly=on -o cachefile=none -N prod
cr0x@server:~$ zpool status -x
pool 'prod' is healthy

Ce que cela signifie : Vous avez récupéré le pool en sécurité (lecture seule, sans montage). C’est le mode inspection.

Décision : Validez les données et la santé des périphériques avant de passer en lecture/écriture. Si c’est un problème de propriété, planifiez une séquence export/import propre.

Task 14: Vérifiez les erreurs au niveau du pool et s’il s’est suspendu

cr0x@server:~$ zpool status -v prod
  pool: prod
 state: SUSPENDED
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
config:

        NAME                        STATE     READ WRITE CKSUM
        prod                        SUSPENDED     0     0     0
          mirror-0                  DEGRADED      0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE        0     0     0
            wwn-0x5000c500a1b2c3d5  FAULTED       0    12     0  too many errors

errors: No known data errors

Ce que cela signifie : ZFS a suspendu les E/S pour protéger la cohérence. C’est généralement un périphérique qui a planté en plein vol.

Décision : Réparez/remplacez d’abord le périphérique fautif. Effacer sans corriger revient à demander à ZFS de reprendre l’écriture dans un incendie.

Task 15: Après réparation matérielle, effacez les erreurs et tentez des actions de récupération délibérées

cr0x@server:~$ zpool clear prod
cr0x@server:~$ zpool status prod
  pool: prod
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
config:

        NAME                        STATE     READ WRITE CKSUM
        prod                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d5  UNAVAIL      0     0     0  cannot open

Ce que cela signifie : Le pool fonctionne sur les réplicas restants. Vous devez rattacher/remplacer le côté manquant.

Décision : Remplacez le disque défaillant, puis laissez resilver. Ne le laissez pas dégradé « un peu ». C’est comme ça que « un peu » devient un incident générateur de réveils.

Task 16: Identifiez les TXG récents et envisagez le rewind uniquement si la corruption est plausible

cr0x@server:~$ zpool import -F -n -d /dev/disk/by-id tank
Would be able to return pool to state as of Tue Feb  3 18:22:41 2026.
Would discard 2.14G of transactions.

Ce que cela signifie : Le dry-run de rewind est disponible. Il ramènerait à un état antérieur et jetterait quelques écritures récentes. Cela peut être acceptable si l’alternative est « pas de pool ». Cela peut aussi être inacceptable si ces écritures étaient critiques.

Décision : Faites une pause et alignez-vous avec les parties prenantes. Si vous procédez, faites d’abord le premier import en lecture seule, confirmez les datasets, puis décidez du passage en lecture/écriture.

Task 17: Exécuter l’import avec rewind soigneusement (seulement si vous avez accepté de sacrifier des TXG récents)

cr0x@server:~$ zpool import -F -o readonly=on -o cachefile=none -N -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
status: Pool was previously in use from another system.
action: Export the pool from the other system, then import it.
config:

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

Ce que cela signifie : Le pool est à nouveau accessible (en mode inspection lecture seule). L’avertissement « previously in use » est courant après des crashs ou des migrations ; ce n’est pas toujours une vraie condition multi-hôte, mais traitez-la sérieusement.

Décision : Validez les données, exportez proprement si nécessaire, puis importez normalement en lecture/écriture. Si vous avez réellement un accès multi-hôte, corrigez cette architecture.

Task 18: Une fois importé, montez volontairement et vérifiez

cr0x@server:~$ zfs mount -a
cr0x@server:~$ zfs list -o name,used,avail,mountpoint | head
NAME               USED  AVAIL  MOUNTPOINT
tank               128K  10.9T  /tank
tank/home          2.1T  10.9T  /tank/home
tank/vm            6.4T  10.9T  /tank/vm

Ce que cela signifie : Les datasets sont montés, les points de montage ont du sens, et vous pouvez procéder aux vérifications au niveau applicatif.

Décision : Si les points de montage sont incorrects (par ex. legacy vs gérés par ZFS), faites une pause et corrigez les propriétés avant de démarrer les services.

Modes de panne que vous pouvez réellement corriger

1) Le pool est sain ; l’OS ne voit pas les disques (ou les voit différemment)

La plupart des incidents « ZFS ne s’importe pas » sont en réalité des « la couche de stockage a changé ». Déclencheurs fréquents :

• Mise à jour de firmware HBA modifiant l’énumération des disques.
• Expanders SAS qui vacillent sous charge.
• Namespaces NVMe modifiés après l’utilisation d’un outil vendeur.
• Mauvaise configuration multipath présentant deux nœuds de périphérique par LUN.

Correction : Stabilisez la couche périphérique d’abord. Utilisez des chemins by-id ; confirmez que tous les WWN attendus existent ; supprimez les nœuds multipath obsolètes ; remplacez câbles/transceivers défaillants.

2) Confusion de cachefile et chemins de périphérique obsolètes

Sur certains systèmes, ZFS utilise un cachefile pour se souvenir des chemins vdev. Si le cachefile pointe vers d’anciens noms /dev/sdX, l’import peut échouer même si les disques existent.

Correction : Utilisez -o cachefile=none et scannez explicitement -d /dev/disk/by-id. Après un import propre, définissez un cachefile approprié pour votre OS, ou laissez le service le gérer.

3) Mismatch de feature flag / version

Si un pool a été mis à jour (feature flags activés) sur un hôte, des hôtes plus anciens peuvent refuser de l’importer. Cela ressemble à une erreur d’import, pas à une défaillance disque.

Correction : Importez sur un système avec un support OpenZFS compatible. Si vous devez déplacer des pools entre hôtes, gérez les versions ZFS comme vous gérez les versions de base de données : délibérément.

4) Corruption des TXG les plus récents après un crash (territoire rewind)

Perte d’alimentation inattendue, caches d’écriture trompeurs et mauvais timing peuvent laisser le TXG le plus récent incohérent. ZFS détecte et évite normalement les uberblocks incohérents, mais parfois il faut revenir en arrière.

Correction : Utilisez zpool import -F -n pour voir le coût du rollback. Procédez seulement si vous acceptez de supprimer des transactions récentes. Préférez d’abord un import en lecture seule.

5) Pool suspendu en raison d’échecs d’E/S

C’est ZFS qui fait ce qu’il faut : arrêter les E/S pour protéger la cohérence. Les gens le détestent parce que c’est bruyant, mais c’est mieux que la corruption silencieuse.

Correction : Identifiez et remplacez/restaurez le chemin du périphérique défaillant. Ensuite zpool clear et resilver.

6) Avertissements « importé ailleurs » (vrai multi-hôte ou état obsolète)

Parfois l’autre hôte existe réellement. Parfois il est mort et a laissé des traces. Quoi qu’il en soit, importer sur deux hôtes transforme un incident récupérable en projet de forensique.

Correction : Confirmez l’exclusivité. Si l’autre hôte est en ligne, exportez depuis lui. S’il est mort, assurez-vous qu’il ne peut pas voir les disques (coupez l’alimentation, déconnectez l’étagère) avant de forcer l’import.

Petite blague #2 : Forcer un import sur un stockage partagé sans vérifier l’autre hôte, c’est comme merger sur main sans tests — techniquement possible, émotionnellement coûteux.

Trois mini-récits d’entreprise venus du terrain

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

L’équipe stockage a remplacé un HBA dans un hôte de virtualisation pendant une fenêtre planifiée. Nouvelle carte, même famille de modèles, même câblage. L’ingénieur a supposé que les noms de périphériques resteraient stables parce que « Linux retrouve toujours les disques ». Il les a retrouvés — juste dans un ordre différent.

Après le reboot, le pool ZFS ne s’importait plus. L’on-call a vu des erreurs cannot open pour quelques périphériques et a immédiatement suspecté une défaillance disque. Un ticket a été ouvert pour aller retirer des disques dans le datacenter. Réflexe coûteux : les swaps de disque sont faciles à mal faire, et chaque retrait est une chance de provoquer une seconde panne.

Trente minutes plus tard, quelqu’un a finalement lancé zpool import -d /dev/disk/by-id -o cachefile=none et a vu les métadonnées du pool parfaitement intactes. Le problème venait du cachefile du système qui référençait d’anciens chemins /dev/sdX et la nouvelle énumération HBA ne correspondait pas. Personne n’avait confirmé des identifiants stables.

La solution a été ennuyeuse : importer via by-id, mettre à jour le comportement du cachefile et ajouter une étape de checklist avant maintenance qui valide tous les WWN après tout changement de contrôleur. Le postmortem a montré que la mauvaise hypothèse ne portait pas sur ZFS mais sur l’identité.

Mini-récit #2 : L’optimisation qui a mal tourné

Une équipe voulait accélérer les sync writes pour une pipeline de logs. Ils ont ajouté des SSD consommateurs rapides comme SLOG, configuré de façon agressive, et célébré quand les benchmarks ont doublé. Puis la réalité est arrivée : un événement d’alimentation et une coupure partielle qui n’a pas complètement mis la baie hors tension, juste assez pour embrouiller plusieurs périphériques.

Après le reboot, l’import du pool fonctionnait parfois et parfois bloquait. Les logs montraient des resets intermittents et « Internal target failure » sur un des SSD. Parce que le SLOG était sur un dispositif consommateur instable sans protection contre la perte d’alimentation, le système passait trop de temps à essayer de lui parler pendant l’import. Ce n’était pas le seul problème, mais c’était le plus bruyant.

La première « solution » tentée a été de forcer l’import avec tous les flags imaginables. Cela faisait parfois importer le système, mais ce n’était pas stable. ZFS faisait ce qu’il pouvait ; le matériel faisait ce qu’il voulait.

La récupération réelle : retirer physiquement le dispositif de log défaillant (ou le remplacer par un dispositif PLP sain), puis importer en lecture seule, remplacer les pièces défectueuses, puis réintroduire un dispositif de log avec des critères de sélection appropriés. L’« optimisation » est devenue une taxe sur la disponibilité.

La leçon : si vous optimisez les frontières de durabilité (sync writes, intent logs, caches d’écriture), vous héritez de leurs modes de défaillance. Si votre activité tient à ces écritures, votre matériel doit en tenir compte aussi.

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

Une entreprise avait une politique : chaque châssis de stockage avait une fiche laminée collée à l’intérieur de la porte avant. Elle listait slot disque → WWN → appartenance pool/vdev. Ça ressemblait à quelque chose d’un NOC des années 1990, et tout le monde s’en moquait jusqu’au jour où ça a servi.

Un pool a cessé de s’importer après qu’un prestataire de maintenance ait « remis de l’ordre dans les câbles ». La moitié des disques étaient présents, l’autre moitié invisibles. Le prestataire jurait n’avoir rien bougé. Les logs OS disaient le contraire.

Parce que l’équipe disposait de la cartographie slot→WWN, ils ont rapidement identifié quelles baies physiques correspondaient aux WWN manquants et ont tracé le problème jusqu’à un câble d’expander mal enfiché à mi-course. Pas de devinettes. Pas de « essayez d’échanger sdc et sdd ». Pas de retrait accidentel du mauvais disque du seul miroir survivant.

Le pool s’est importé en dégradé, puis pleinement après la réparation du câble. Le resilver s’est terminé pendant la nuit. La politique était ennuyeuse. Elle a fait la différence entre un incident de deux heures et une restauration de plusieurs jours.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: zpool import n’affiche rien

Cause racine : Périphériques non découverts, mauvais chemin de scan, ou labels illisibles à cause d’un problème matériel/driver. Parfois le pool existe mais se trouve derrière des nœuds multipath que vous ne scannez pas.

Correction : Scannez des répertoires explicites (-d /dev/disk/by-id), vérifiez dmesg pour des erreurs de découverte et confirmez la présence des WWN attendus. Si vous êtes sur SAN, vérifiez que multipath présente un périphérique stable par LUN.

2) Symptom: L’import échoue avec « insufficient replicas »

Cause racine : Trop de périphériques manquants dans un vdev. Les mirrors ont besoin d’un côté ; RAIDZ nécessite assez de membres pour reconstituer la parité ; si vous êtes en dessous du seuil, ZFS ne peut pas assembler le vdev.

Correction : Restaurez les périphériques manquants (câble/HBA/chemin), remplacez les disques défaillants, ou restaurez depuis une sauvegarde. N’espérez pas que -f contourne la physique.

3) Symptom: L’import bloque indéfiniment

Cause racine : Le noyau retente des E/S vers un périphérique en timeout, souvent à cause d’un disque défaillant, d’un expander ou d’un mismatch de firmware contrôleur.

Correction : Identifiez le périphérique lent/défaillant via les logs du noyau et iostat. Retirez/remplacez le coupable. Puis retentez l’import, de préférence en lecture seule d’abord.

4) Symptom: Le pool s’importe, mais les services échouent parce que les datasets ne sont pas montés

Cause racine : Import avec -N, propriétés de mountpoint, montages legacy, ou clefs de chiffrement non chargées.

Correction : Vérifiez zfs get mountpoint,canmount,keystatus. Chargez les clefs si nécessaire. Montez explicitement avec zfs mount -a ou dataset par dataset.

5) Symptom: Le pool devient immédiatement SUSPENDED

Cause racine : ZFS a détecté des échecs E/S répétés et s’est suspendu pour protéger le pool. Souvent un périphérique se fault sous charge d’écriture.

Correction : Remplacez/réparez le chemin périphérique. Puis clear et resilver. Ne continuez pas à clear sans réparer le matériel.

6) Symptom: « The pool is currently imported by another system »

Cause racine : Soit il est réellement importé ailleurs, soit le système pense qu’il l’était (état obsolète après crash). Dans les environnements de stockage partagé, c’est l’avertissement le plus important.

Correction : Confirmez l’exclusivité : assurez-vous que d’autres hôtes ne peuvent pas voir les disques, puis importez d’abord en lecture seule. Mettez en place multihost et des contrôles opérationnels si des étagères partagées existent.

7) Symptom: Erreur d’import mentionnant des features non supportées

Cause racine : Pool créé ou mis à niveau avec des feature flags non supportés par cette implémentation/version de ZFS.

Correction : Importez sur un hôte plus récent et compatible. Alignez les versions ZFS sur toute la flotte. N’activez pas les features du pool sans réfléchir dans des environnements mixtes.

8) Symptom: Après un import forcé, les données semblent « plus anciennes » que prévu

Cause racine : Rewind/rollback a supprimé des TXG récents, ou les applications supposaient des sémantiques sync qu’elles n’avaient pas.

Correction : Traitez le rewind comme une perte de données intentionnelle. Communiquez clairement. Validez la cohérence applicative ; restaurez les journaux applicatifs si disponibles.

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

Phase 0 : Figerez la scène (5–10 minutes)

• Arrêtez toute automatisation qui pourrait continuer à retenter des imports ou monter des datasets.
• Capturez : dmesg -T, journalctl -k (si disponible), zpool import, et la sortie d’inventaire matériel.
• Confirmez si c’est du stockage partagé. Si oui, assurez-vous qu’un seul hôte peut accéder aux disques.

Phase 1 : Vérité de la couche périphérique

1. Listez les identifiants stables : ls -l /dev/disk/by-id.
2. Comparez les WWN attendus aux WWN présents (depuis votre inventaire, labels ou dernier zpool status connu bon).
3. Vérifiez les logs du noyau pour resets/timeouts des périphériques manquants.
4. Réparez câblage/HBA/disque jusqu’à ce que tous les périphériques attendus soient présents et stables.

Phase 2 : Découverte ZFS non destructive et tentative d’import

1. Scannez explicitement : zpool import -d /dev/disk/by-id.
2. Si le pool apparaît, notez l’état, les vdevs manquants et les indices « last TXG ».
3. Tentez un import sûr : zpool import -d /dev/disk/by-id -o cachefile=none -o readonly=on -N POOL.
4. Si import réussi, inspectez zpool status -v et zfs list avant de monter ou démarrer des services.

Phase 3 : Risque contrôlé (uniquement si nécessaire)

1. Si l’import échoue à cause d’une corruption récente suspectée, faites un dry-run de rewind : zpool import -F -n POOL.
2. Décidez si vous pouvez jeter les transactions indiquées. Traitez cela comme une perte de données.
3. Si vous procédez, importez avec rewind en lecture seule d’abord : zpool import -F -o readonly=on -N POOL.
4. Validez les données, puis exportez et importez normalement en lecture/écriture si approprié.

Phase 4 : Après l’import — stabiliser

• Remplacez les périphériques défaillants et laissez resilver.
• Exécutez un scrub quand le système est stable et que l’impact sur les performances est acceptable.
• Documentez la cause racine. Mettez à jour les runbooks et les cartographies d’inventaire.

Ce qu’il faut éviter (ce sont des récidivistes)

• Ne lancez pas de commandes destructrices (comme repartitionner, formater ou « initialiser » des disques) sur des périphériques que vous n’avez pas identifiés positivement par WWN/serial.
• Ne mettez pas à jour les features du pool pendant la récupération. Ce n’est pas le moment des features.
• Ne faites pas un import en lecture/écriture en premier quand vous n’êtes pas sûr. Vous déboguez ; minimisez les effets secondaires.
• N’ignorez pas les logs matériels. Ils disent généralement la vérité que vous ne voulez pas entendre.

FAQ

1) Dois-je essayer zpool import -f immédiatement ?

Non. Déterminez d’abord si le pool est réellement importé ailleurs et si des périphériques manquent. Le force import sert pour les conflits de propriété, pas pour les disques manquants.

2) Qu’apporte -o cachefile=none ?

Il empêche ZFS de faire confiance à des chemins mis en cache potentiellement obsolètes et force un scan neuf des périphériques que vous spécifiez. C’est une manière simple d’éliminer les problèmes d’anciens noms /dev/sdX.

3) Pourquoi répétez-vous « scannez par-id » ?

Les noms /dev/sdX sont attribués au boot et peuvent changer quand les contrôleurs, firmwares ou timings des disques changent. Les noms by-id et WWN sont la façon de rester sain en production.

4) Si je peux importer en lecture seule, puis-je simplement copier les données et reconstruire ?

Souvent oui, et c’est une excellente démarche quand vous suspectez une dégradation matérielle en cours. L’import en lecture seule réduit le risque d’aggraver les métadonnées pendant l’extraction des données.

5) Quand le rewind (zpool import -F) est-il approprié ?

Quand vous suspectez fortement que les TXG les plus récents sont incohérents (crash en plein write, caches d’écriture trompeurs, coupure subite) et que l’import normal échoue. Faites toujours -n d’abord pour voir le coût.

6) ZFS peut-il récupérer d’une corruption silencieuse sans redondance ?

ZFS peut détecter la corruption via les checksums. La réparation nécessite de la redondance (mirror/RAIDZ ou copies) ou une source externe de confiance (sauvegarde). La détection sans réparation reste utile ; elle vous dit ce dont il ne faut pas vous fier.

7) Pourquoi l’import prend-il si longtemps sur de grands pools ?

L’import peut sonder des labels sur de nombreux périphériques et retenter des E/S quand des périphériques répondent lentement. Si un seul disque vacille, le temps d’import peut exploser parce que le noyau essaie perpétuellement d’aider.

8) Que faire si le pool s’importe mais mes applications échouent toujours ?

Séparez la santé du stockage de la correction applicative. Vérifiez les mountpoints des datasets, les clefs de chiffrement et si les services attendent des chemins/permissions spécifiques. Ensuite validez la cohérence côté application.

9) Est-il sûr de lancer un scrub immédiatement après la récupération ?

Généralement oui, mais le timing compte. Si le matériel est encore instable, un scrub peut amplifier les défaillances. Stabilisez le matériel, assurez-vous que la redondance est restaurée, puis scrubgez pour confirmer l’intégrité.

10) Comment prévenir les problèmes « pool importé ailleurs » ?

Architecturalement : ne présentez pas les mêmes disques à plusieurs hôtes à moins d’avoir une stratégie multi-hôte conçue et testée. Opérationnellement : appliquez du fencing et utilisez des pratiques d’identité hôte stables.

Conclusion : étapes suivantes pour réduire les incidents répétés

Si votre pool ZFS ne s’importe pas, le chemin calme est : stabiliser les périphériques, scanner avec des identifiants stables, importer d’abord en lecture seule, puis prendre des risques contrôlés uniquement quand les preuves le justifient.

Étapes pratiques que j’assignerais réellement après l’incident :

• Standardiser les chemins vdev sur by-id/WWN pour tous les pools. Corriger les pools legacy problématiques avant qu’ils ne deviennent une panne.
• Ajouter une vérification pré-maintenance qui enregistre zpool status, l’inventaire WWN et les versions de firmware des contrôleurs.
• Revoir la protection des caches d’écriture, la protection d’alimentation et toute « optimisation de performance » qui modifie le comportement de défaillance.
• Répéter la récupération en laboratoire : importer avec périphériques manquants, tester les dry-runs de rewind, pratiquer les workflows de clefs de chiffrement.
• Rendre les sauvegardes ennuyeuses et vérifiées. ZFS est résilient, pas magique.

Quand vous répétez cela assez souvent, la partie effrayante cesse d’être les commandes. Elle devient la tendance humaine à se précipiter. Ne le faites pas. ZFS récompense la patience et punit l’improvisation.