Bases de la récupération d’un pool ZFS : étapes pour ne pas empirer

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

Cet article vous a aidé ?

Le moment le plus dangereux lors d’une récupération ZFS, ce sont les cinq premières minutes. Non pas parce que ZFS est fragile, mais parce que les humains le sont. Vous êtes de garde, le pool est « UNAVAIL », les tableaux de bord sont rouges, et quelqu’un propose « reboot immédiatement ». C’est ainsi que vous transformez un incident réparable en une affaire médico-légale.

Voici le guide de terrain pour récupérer un pool ZFS avec un minimum de drame : quoi vérifier en premier, quelles commandes lancer, comment lire la sortie et quelles décisions prendre en fonction de ces informations. C’est orienté opinion ; il suppose la pression de la production. Il suppose aussi que vous souhaitez garder votre travail et vos données.

Mentalité de récupération : arrêter d’aggraver

La récupération d’un pool ZFS ressemble moins à « réparer un système de fichiers » et davantage à « gérer des preuves sur une scène d’accident ». Les outils sont puissants, les structures de données sont résilientes, et vous pouvez absolument empirer la situation en faisant preuve de créativité sous stress.

Trois règles pour éviter les ennuis :

Minimiser les écritures jusqu’à ce que vous compreniez la panne. Les écritures peuvent écraser les métadonnées dont vous avez besoin pour une récupération propre.
Privilégier l’observation à l’action. Vos premières commandes doivent être en lecture seule : status, discovery d’import, logs du noyau.
Ne changer qu’une variable à la fois. Si vous remplacez des disques, changez des câbles et réécrivez des chemins de périphériques en une seule fois, votre timeline devient de la fiction.

Et : ne « nettoyez » pas les labels et partitions tant que vous n’avez pas capturé assez d’état pour revenir en arrière. ZFS pardonne, il n’est pas devin.

Blague #1 : « Je vais juste exécuter zpool import -f et voir ce qui se passe » est l’équivalent stockage de « Je vais juste remuer le manche de l’avion et voir ce qui arrive ».

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

Ceci est le chemin le plus court vers « qu’est-ce qui est réellement cassé ? ». Il est conçu pour identifier rapidement le goulot d’étranglement : matériel, topologie, métadonnées ou erreur opérateur.

Premier : s’agit-il d’un problème de visibilité des périphériques ou d’un problème de métadonnées ZFS ?

Vérifier les logs du noyau pour des réinitialisations de disques/liens (timeouts SATA, SAS, NVMe).
Vérifier si l’OS voit encore les périphériques (chemins by-id, multipath, mapping d’armoire).
Lancer la découverte d’import sans importer pour voir si ZFS peut lire les labels.

Si les périphériques sont absents au niveau OS, ZFS ne peut pas vous sauver pour l’instant. Réparez les câbles, les HBA, les expanders, le zoning, le multipath, puis revenez à ZFS.

Deuxième : quel est l’état du pool et quel type de redondance avez-vous ?

Mirror vs RAIDZ modifie le risque. Un mirror dégradé est généralement une routine. Un RAIDZ dégradé avec plusieurs problèmes peut nécessiter une danse prudente.
Cherchez « trop d’erreurs » vs « périphérique retiré ». Ce sont des modes de panne différents avec des actions différentes.

Troisième : avez-vous une corruption ou simplement « impossibilité d’assembler le pool » ?

Signes de corruption : erreurs de checksum, « permanent errors », erreurs de lecture sur des fichiers spécifiques, redémarrages répétés de resilver.
Signes d’assemblage : pool n’importe pas, vdevs top-level manquants, cachefile obsolète, périphériques renommés, ordre HBA changé.

Une fois que vous avez étiqueté l’incident comme « visibilité », « assemblage », « dégradé mais importable » ou « corruption », vous cessez de vous agiter et commencez à exécuter.

Faits intéressants et contexte historique (points rapides)

ZFS a été créé chez Sun Microsystems au milieu des années 2000 avec pour objectif l’intégrité des données de bout en bout, pas seulement des fonctions pratiques.
Le modèle « copy-on-write » fait que ZFS n’écrase généralement pas les métadonnées en place, ce qui explique pourquoi de nombreux modes de panne sont récupérables si vous évitez les écritures supplémentaires.
RAIDZ était la réponse de ZFS au classique « RAID5 write hole », en s’appuyant sur des sémantiques transactionnelles plutôt que sur des batteries de contrôleur.
ZFS vérifie les checksums des données et des métadonnées (non optionnel pour les métadonnées), ce qui explique pourquoi « checksum error » indique souvent une corruption réelle, pas un avertissement cosmétique.
OpenZFS est devenu un effort multi-plateforme au fur et à mesure que ZFS sortait des systèmes dérivés de Solaris ; aujourd’hui les comportements varient légèrement selon les plateformes et versions.
La propriété ashift existe parce que les tailles de secteurs physiques et les « mensonges » des disques comptent ; un mauvais alignement peut ruiner silencieusement les performances et parfois la prédictibilité de la récupération.
Les labels de pool ZFS se trouvent à plusieurs endroits sur chaque vdev, ce qui explique pourquoi les « labels endommagés » sont souvent récupérables sauf si quelque chose continue d’écrire au mauvais endroit.
Les scrubs n’ont pas toujours été « opérations standard ». Beaucoup d’organisations ont commencé à traiter les scrubs comme routiniers après que les grosses capacités de disque ont rendu fréquentes les erreurs de secteurs latentes.
Les special vdevs et L2ARC ont rendu les pools plus rapides mais ont aussi ajouté de nouvelles façons de se nuire si vous traitez les « cache devices » comme jetables sans comprendre leur rôle.

Flux de triage : confirmer, isoler, préserver

Si votre pool vient de partir en sucette, ne commencez pas par « réparer ». Commencez par confirmer (ce qui est vrai), puis isoler (stopper l’hémorragie), puis préserver (capturer l’état pour pouvoir raisonner ensuite).

Confirmer : qu’est-ce qui a exactement changé ?

La plupart des incidents ZFS ne sont pas des corruptions mystiques. Ils sont triviaux : un disque est tombé, un HBA a redémarré, un câble a été touché pendant une « maintenance », un alias multipath a changé, une mise à jour firmware a réordonné les périphériques. Le pool est souvent intact ; ce sont vos hypothèses qui ne le sont pas.

Isoler : réduire le churn et les effets secondaires

Si les applications frappent un pool dégradé, suspendre ou limiter leur activité. Faire resilver sous charge d’écriture est possible, mais plus lent et risqué.
Si le pool est instable (devices online/offline), arrêter le churn : réparer la couche lien d’abord.
Si vous êtes tenté de lancer des commandes « de nettoyage », faites une pause et prenez des snapshots/exports seulement si c’est sûr.

Préserver : capturer l’information que vous regretteriez de ne pas avoir

Collectez l’état avant de modifier quoi que ce soit : zpool status, la sortie de zpool import, lsblk et les mappings by-id, et les logs du noyau. C’est ainsi que vous évitez le classique « on a remplacé le mauvais disque ».

Tâches pratiques (commandes + signification des sorties + décisions)

Ce sont des tâches opérationnelles réelles. Chacune inclut : commande, sortie d’exemple, ce que cela signifie et la décision que vous prenez. Adaptez les noms de pool et les identifiants de périphériques à votre environnement.

Task 1: Check current pool health (if imported)

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

Signification : ZFS pense que tout est OK. Si vous observez encore des erreurs applicatives, le problème peut être au niveau supérieur (NFS/SMB, permissions, bugs applicatifs) ou au-dessous (I/O intermittente pas encore remontée).

Décision : Si le pool est sain, ne lancez pas de commandes de récupération « au cas où ». Passez aux logs et aux symptômes applicatifs.

Task 2: Inspect a degraded pool and identify the failing vdev

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
  scan: scrub repaired 0B in 0 days 00:18:22 with 2 errors on Fri Dec 20 02:19:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LM1T9-0  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9-1  ONLINE       0     0     2
            ata-SAMSUNG_MZ7LM1T9-2  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        /tank/projects/db/wal/00000001000000A9000000FF

Signification : Le pool est importable mais présente des erreurs de checksum et un fichier spécifique est impacté. Ce n’est pas « un disque est manquant ». C’est plutôt « ZFS n’a pas pu réparer les données avec la redondance » ou « la redondance a retourné des données incohérentes ».

Décision : Déterminez si le fichier peut être reconstruit (WAL de base de données, artefacts dérivés) ou doit être restauré. Ne commencez pas à arracher des disques parce que vous avez vu « 2 » sous CKSUM ; corrélez d’abord avec SMART et les logs d’erreurs.

Task 3: Discover importable pools without importing

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

        tank                        ONLINE
          mirror-0                  ONLINE
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123  ONLINE
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456  ONLINE

Signification : ZFS voit les labels du pool et peut assembler la topologie. Bon signe. Si le pool n’apparaît pas ici, vous avez probablement des problèmes de visibilité de périphériques, des labels endommagés, ou vous êtes sur le mauvais hôte.

Décision : Si l’import est possible, importez d’abord en lecture seule lorsque la situation est ambiguë.

Task 4: Attempt a cautious read-only import

cr0x@server:~$ sudo zpool import -o readonly=on -N tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: none requested
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456    ONLINE       0     0     0

Signification : Importé sans monter les datasets (-N) et en mode lecture seule. C’est un excellent état pour l’inspection : vous pouvez lister datasets et propriétés sans écrire de nouvelles métadonnées.

Décision : Si vous devez extraire des données, vous pouvez monter des datasets spécifiques en lecture seule. Si vous prévoyez des réparations, passez en lecture-écriture uniquement une fois que la couche périphérique est stable.

Task 5: Check OS-level device presence and stable identifiers

cr0x@server:~$ ls -l /dev/disk/by-id/ | head
total 0
lrwxrwxrwx 1 root root  9 Dec 26 03:10 ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 03:10 ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 03:10 nvme-SAMSUNG_MZVL21T0HCLR-00B00_S6XYZ123 -> ../../nvme0n1

Signification : Les liens by-id existent. C’est important parce que l’ordre /dev/sdX n’est pas une promesse ; c’est une suggestion qui change quand vous clignez des yeux.

Décision : Si le pool a été construit avec des chemins /dev/sdX, planifiez une migration contrôlée vers by-id pendant les heures normales. Pendant la récupération, mappez quel disque physique correspond à quel identifiant avant de remplacer quoi que ce soit.

Task 6: Read the kernel’s opinion about your storage (timeouts, resets)

cr0x@server:~$ sudo dmesg -T | egrep -i "zfs|sd[a-z]|ata|nvme|sas|reset|timeout|I/O error" | tail -20
[Thu Dec 26 03:01:22 2025] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Thu Dec 26 03:01:22 2025] ata6.00: failed command: READ FPDMA QUEUED
[Thu Dec 26 03:01:22 2025] blk_update_request: I/O error, dev sdc, sector 1219024896 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 03:01:23 2025] ata6: hard resetting link
[Thu Dec 26 03:01:29 2025] ata6: link is slow to respond, please be patient (ready=0)
[Thu Dec 26 03:01:35 2025] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Thu Dec 26 03:01:35 2025] sd 6:0:0:0: [sdc] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Thu Dec 26 03:01:35 2025] zfs: vdev state changed, pool_guid=10293847566554433211

Signification : C’est un flapping classique : réinitialisation du lien, échecs de lecture, et ZFS notant des changements d’état de vdev. ZFS peut récupérer d’incidents transitoires, mais des réinitialisations répétées pendant un resilver peuvent prolonger fortement l’incident.

Décision : Réparez la couche physique avant d’exécuter des actions ZFS qui nécessitent des lectures soutenues (scrub/resilver). Changez le câble, déplacez le port, vérifiez le firmware HBA, vérifiez l’expander.

Task 7: Check SMART/NVMe health to confirm a drive is actually sick

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Model|Serial|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count|SMART overall"
Device Model:     WDC WD80EFAX-68LHPN0
Serial Number:    WD-DEF456
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   095   095   140    Pre-fail  Always       -       0
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       -       12

Signification : « PASSED » n’est pas une absolution. Les secteurs pending et uncorrectable signifient que le disque a des zones illisibles. Les erreurs CRC suggèrent aussi un problème de câble/backplane.

Décision : Si pending/uncorrectable sont non nuls et augmentent, remplacez le disque. Si les erreurs CRC augmentent sans autres signes, suspectez d’abord le câblage/backplane/HBA.

Task 8: Find which device corresponds to which bay (enclosure mapping)

cr0x@server:~$ sudo lsblk -o NAME,SIZE,SERIAL,MODEL,HCTL,WWN
NAME   SIZE SERIAL    MODEL            HCTL       WWN
sdb    7.3T WD-ABC123 WDC WD80EFAX-68L  6:0:0:0   0x50014ee2b1234567
sdc    7.3T WD-DEF456 WDC WD80EFAX-68L  6:0:1:0   0x50014ee2b7654321
nvme0n1 1.8T S6XYZ123 SAMSUNG MZVL21T0  -         0x002538b111223344

Signification : Vous bâtissez une cartographie entre noms logiques et périphériques physiques. Cela vous évite de remplacer le mauvais disque — la forme la plus coûteuse de cardio.

Décision : Avant tout remplacement, enregistrez les numéros de série et emplacements de baie (depuis vos outils d’armoire ou inventaire). Si vous ne pouvez pas faire la correspondance, arrêtez-vous et résolvez cela.

Task 9: Clear transient errors only after the underlying cause is fixed

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

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456    ONLINE       0     0     0

Signification : Les compteurs sont réinitialisés. Cela ne « répare » rien ; cela vous donne un état propre pour la surveillance après remédiation.

Décision : Utilisez zpool clear après avoir réparé le câblage ou remplacé un disque et que vous souhaitez confirmer que le problème ne revient pas.

Task 10: Replace a failed disk in a mirror (clean and boring)

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
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456    FAULTED      0     0     0  too many errors

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ata-WDC_WD80EFAX-68LHPN0_WD-NEW999
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
  scan: resilver in progress since Thu Dec 26 03:22:01 2025
        1.21T scanned at 1.18G/s, 312G issued at 305M/s, 7.30T total
        312G resilvered, 4.17% done, 06:35:11 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          mirror-0                                DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-NEW999    ONLINE       0     0     0  (resilvering)

Signification : Le remplacement a commencé et le resilver est en cours. Si le débit de resilver est extrêmement bas, suspectez des erreurs I/O en cours, des disques SMR sous charge ou une charge concurrente.

Décision : Surveillez la stabilité du resilver. Si l’ancien disque est encore lisible de façon intermittente, gardez-le connecté jusqu’à la fin du resilver — sauf s’il bloque activement le bus.

Task 11: Identify what’s preventing import (missing device vs wrong hostid)

cr0x@server:~$ sudo zpool import tank
cannot import 'tank': pool may be in use from other system, it was last accessed by server-a (hostid=0x12ab34cd) on Thu Dec 26 01:50:20 2025
use '-f' to import anyway

Signification : ZFS pense qu’un autre hôte utilisait le pool. Cela peut être légitime (stockage partagé, cluster, SAN) ou juste un hostid obsolète après déplacement des disques.

Décision : Confirmez que le pool n’est pas importé ailleurs. Si vous êtes sûr, importez avec force, mais traitez cela comme un événement opérationnel à documenter et auditer.

Task 12: Force import safely, ideally read-only first

cr0x@server:~$ sudo zpool import -f -o readonly=on -N tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456    ONLINE       0     0     0

Signification : Le pool s’importe et est stable en lecture seule. C’est un point de mise en scène sûr pour vérifier les données avant d’autoriser des écritures.

Décision : Si l’incident impliquait des reboots inattendus ou des problèmes HBA, gardez-le en lecture seule jusqu’à ce que vous ayez confirmé la stabilité des périphériques et extrait les données irremplaçables.

Task 13: Import using an alternate root (for recovery environments)

cr0x@server:~$ sudo zpool import -R /mnt -N tank
cr0x@server:~$ sudo zfs mount -a
cr0x@server:~$ mount | grep tank
tank/home on /mnt/home type zfs (rw,xattr,noacl)

Signification : -R définit une racine de montage alternative. Utile dans un shell de secours, un hôte de récupération, ou quand vous ne voulez pas entrer en collision avec des points de montage de production.

Décision : Utilisez ceci lors d’une récupération depuis un OS vivant ou pour migrer des disques vers un hôte temporaire pour inspection.

Task 14: Verify snapshots exist before you attempt “repairs”

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -S creation tank | head
NAME                              CREATION
tank@autosnap_2025-12-26_0200      Thu Dec 26 02:00 2025
tank@autosnap_2025-12-26_0100      Thu Dec 26 01:00 2025
tank@autosnap_2025-12-26_0000      Thu Dec 26 00:00 2025

Signification : Les snapshots offrent un point de récupération logique même quand le matériel est instable. Ils vous donnent aussi la confiance nécessaire pour revenir en arrière sur des datasets si besoin (avec précaution).

Décision : Si les snapshots manquent et que vous envisagez des actions destructrices, faites une pause. Vos options de récupération viennent de se réduire.

Task 15: Run a scrub when the pool is stable, then interpret results

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 03:40:11 2025
        2.88T scanned at 1.02G/s, 1.44T issued at 512M/s, 7.30T total
        0B repaired, 19.72% done, 03:05:19 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456    ONLINE       0     0     0

Signification : Le scrub lit tout et vérifie les checksums. « Repaired » indique que ZFS a corrigé des données à l’aide de la redondance. Si des réparations se répètent, vous avez un problème persistant (disque, câblage, mémoire, contrôleur).

Décision : Si le scrub se termine avec des erreurs, traitez cela comme un incident réel, pas un avertissement. Collectez zpool status -v et décidez s’il faut restaurer des fichiers impactés ou remplacer du matériel.

Task 16: List and evaluate permanent errors

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
errors: Permanent errors have been detected in the following files:
        /tank/projects/db/base/16384/2609
        /tank/projects/db/base/16384/2610

Signification : ZFS vous dit : « Je sais quels fichiers sont mauvais. » C’est un cadeau. Pour les bases de données et images de VM, ces chemins sont cruciaux.

Décision : Si ce sont des fichiers critiques : restaurez depuis une sauvegarde/snapshot de réplication, ou reconstruisez le dataset/l’application. Ne supposez pas qu’un autre scrub réparera magiquement des « permanent errors ».

Task 17: Check whether you’re dealing with insufficient replicas (a.k.a. you lost redundancy)

cr0x@server:~$ sudo zpool status -v vault
  pool: vault
 state: DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
action: Replace the device using 'zpool replace'.
config:

        NAME                        STATE     READ WRITE CKSUM
        vault                       DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ata-ST12000NM0008_A1    ONLINE       0     0     0
            ata-ST12000NM0008_A2    ONLINE       0     0     0
            15553461652766218490    UNAVAIL      0     0     0  was /dev/disk/by-id/ata-ST12000NM0008_A3
            ata-ST12000NM0008_A4    ONLINE       0     0     0
            ata-ST12000NM0008_A5    ONLINE       0     0     0
            ata-ST12000NM0008_A6    ONLINE       0     0     0

Signification : ZFS se souvient d’un vdev par GUID et vous indique l’ancien chemin. C’est souvent « disque manquant » ou « disque ré-énuméré mais label disparu ».

Décision : Trouvez le disque manquant (par serial, baie, chemin HBA). S’il est présent mais que le label a disparu, traitez cela comme suspect — quelque chose l’a peut-être écrasé. Ne lancez pas zpool replace tant que vous ne savez pas quel disque physique correspond à ce GUID.

Task 18: Export a pool cleanly before moving disks to another host

cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import
no pools available to import

Signification : Export ferme et vidange proprement le pool. Quand vous déplacez des disques entre hôtes, cela réduit les frictions « pool may be in use » et diminue le risque d’état obsolète.

Décision : Si la machine est assez stable pour exporter, faites-le. Si elle ne l’est pas, planifiez une importation en lecture seule sur l’hôte de récupération et documentez pourquoi.

Erreurs courantes : symptômes → cause racine → correction

Voici la partie où je vous évite vos futurs regrets. Ce ne sont pas des théories. Ce sont des choses que l’on fait à 03:00 quand Slack hurle.

1) Le pool n’importe pas après « un simple reboot »

Symptômes : zpool import affiche le pool, mais l’import se plaint d’« in use from other system » ou se bloque.
Cause racine : hostid obsolète, pool non exporté proprement, ou périphériques qui flappent empêchant l’import.
Correction : Vérifiez qu’aucun autre hôte ne l’a importé. Faites un import forcé en lecture seule (-f -o readonly=on -N) pour inspecter. Réparez la couche périphérique avant d’autoriser les écritures.

2) Des « erreurs de checksum » apparaissent et quelqu’un remplace immédiatement le disque

Symptômes : CKSUM non nul sur un vdev ; pool dégradé ; scrub rapporte des erreurs.
Cause racine : Peut être le média du disque, mais aussi la RAM, un HBA/backplane qui flippe, un mauvais câble SAS, ou des bugs firmware. Remplacer le disque peut ne rien résoudre et ajouter du stress lors du resilver.
Correction : Corrélez : stats SMART, dmesg, compteurs d’erreurs sur plusieurs disques, et si les erreurs « suivent » un câble/port. Remplacez le matériel en vous basant sur des preuves, pas sur des impressions.

3) Le resilver est « bloqué » à faible vitesse

Symptômes : zpool status montre un resilver avec des heures/jours restants ; le débit s’effondre.
Cause racine : Comportement SMR sous écritures aléatoires, retries de lecture dus à un média marginal, pool occupé par des écritures applicatives, ou un périphérique lent dans un RAIDZ qui bride tout le vdev.
Correction : Réduisez la charge, vérifiez les erreurs I/O dans les logs, envisagez d’arrêter temporairement les écritures lourdes, et assurez-vous que le disque de remplacement n’est pas un mismatch de performances. Si vous observez des réinitialisations répétées, corrigez le câblage/HBA d’abord.

4) Le pool est UNAVAIL après des changements « d’optimisation »

Symptômes : Un special vdev, SLOG ou périphérique de métadonnées échoue ; le pool ne monte plus les datasets ; pics de latence avant la panne.
Cause racine : Traiter des « fast devices » comme optionnels alors qu’ils ont été configurés comme requis (special vdev n’est pas comme L2ARC). Ou les avoir surchargés ou mal dimensionnés.
Correction : Remplacez les périphériques du special vdev comme vous le feriez pour un disque critique. Concevez les special vdevs avec redondance. N’en ajoutez pas sans être prêt à les opérer en production.

5) Quelqu’un exécute `zpool labelclear` sur le mauvais disque

Symptômes : Un vdev précédemment visible devient « manquant », le pool se dégrade davantage, la sortie d’import change de façon déroutante.
Cause racine : Mauvaise identification des disques physiques, reliance sur /dev/sdX, ou saut de l’étape de mapping serial→baie.
Correction : Arrêtez. Capturez la sortie actuelle de zpool import. Reconstituez le mapping avec serials, WWN et outils d’armoire. N’effacez les labels que si vous êtes absolument certain que le disque n’appartient à aucun pool requis.

6) Les scrubs « réparent » sans cesse chaque semaine

Symptômes : Les scrubs réparent de petites quantités de données de façon répétée ; les erreurs de checksum tournent entre les disques ; aucun disque unique n’est constamment coupable.
Cause racine : Souvent non lié au disque : RAM instable (surtout sans ECC), problèmes HBA, câblage, backplane ou instabilité d’alimentation.
Correction : Traitez cela comme un problème d’intégrité de plateforme. Lancez des tests mémoire durant une maintenance, vérifiez les logs ECC, mettez à jour le firmware, et validez câblage/backplane. Remplacer des disques au hasard est juste du déni coûteux.

Checklists / plan étape par étape

Checklist A: When a pool is degraded but online

Exécuter zpool status -v. Identifier si les erreurs sont READ/WRITE/CKSUM et si des « permanent errors » existent.
Vérifier dmesg pour des réinitialisations/timeouts autour de la même heure.
Vérifier SMART/NVMe pour les périphériques impliqués.
Mapper les périphériques par serial/WWN vers les baies physiques.
Si un disque est clairement défaillant : remplacez-le et surveillez le resilver.
Après le resilver : lancez un scrub du pool. Confirmez l’absence d’erreurs.
Alors seulement : réinitialisez les compteurs (zpool clear) et remettez la charge normale.

Checklist B: When a pool won’t import

Exécuter zpool import (sans arguments) et sauvegarder la sortie.
Confirmer que l’OS voit tous les périphériques attendus (ls -l /dev/disk/by-id/, lsblk).
Vérifier les logs du noyau pour des réinitialisations/timeouts de lien.
Si « in use from other system » : vérifiez qu’aucun autre hôte ne l’a importé ; puis essayez l’import forcé en lecture seule : zpool import -f -o readonly=on -N POOL.
Si des périphériques manquent : réparez d’abord le chemin matériel (câbles/HBA/armoire), puis relancez la découverte d’import.
Si l’import réussit en lecture seule : montez sélectivement et copiez les données irremplaçables avant toute tentative de récupération en écriture.

Checklist C: When you suspect corruption

Importer en lecture seule et sans montage (-o readonly=on -N) si possible.
Exécuter zpool status -v et identifier les chemins de permanent errors.
Décider d’une réponse au niveau fichier : restaurer/reconstruire/supprimer les artefacts dérivés.
Lancer le scrub seulement quand les périphériques sont stables.
Si la corruption réapparaît : investiguer la RAM, HBA, firmware, alimentation et câblage. ZFS rapporte des symptômes ; votre plateforme fournit la maladie.

Trois mini-histoires du monde corporate

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un serveur de stockage avec douze disques en RAIDZ2, une paire de SSD de boot en miroir, et un joli tableur mappant les baies aux numéros de série. Le tableur était « assez précis », ce qui revient à dire qu’un parachute est « grosso modo plié ».

Un disque a commencé à timeout. L’ingénieur de garde a vu /dev/sdj accumuler des erreurs et a retiré le « disque en emplacement 10 », parce que c’est ce que disait le mapping du dernier trimestre. Le pool a empiré immédiatement. Maintenant deux membres d’un vdev RAIDZ2 étaient manquants : le disque réellement défaillant et le disque parfaitement sain qui avait été retiré.

Ce qui était effrayant, c’était la normalité apparente au départ. ZFS n’a pas crié différemment. Il est juste passé de « dégradé mais disponible » à « import échoue de façon intermittente » parce que les disques restants subissaient une charge de reconstruction massive et que le lien initial défaillant continuait de flapper.

La récupération a duré plus longtemps que nécessaire parce qu’ils ont passé des heures à débattre des commandes ZFS. La solution était ennuyeuse : remettre en place le disque suspect initial, reconstruire le mapping correct baie→serial depuis les données d’armoire, puis remplacer le serial réellement défaillant. Après cela, le resilver a terminé et le pool est revenu propre.

Action post-mortem : bannir /dev/sdX de toute procédure opérationnelle et exiger la confirmation du serial avant tout retrait de disque. Ça n’a pas rendu les gens plus intelligents. Ça a rendu l’incident suivant survivable.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une équipe voulait accélérer les opérations sur les métadonnées pour des millions de petits fichiers. Ils ont ajouté un special vdev sur une paire de SSD rapides. Ça a marché. La latence a chuté, les traversées d’annuaires sont devenues réactives, et tout le monde a eu sa dose de dopamine « on a réparé le stockage ».

Des mois plus tard, un des SSD a commencé à produire des erreurs. Pas catastrophiquement — juste assez pour disparaître de façon intermittente sous charge. Le pool n’a pas simplement dégradé comme un miroir normal. La charge lourde en métadonnées a fait du special vdev le centre de l’univers, si bien que chaque accroc s’est transformé en timeouts applicatifs.

Pendant l’incident, quelqu’un a demandé : « Si c’est juste un cache, peut-on le détacher ? » C’est là que se trouvait la mécompréhension : un special vdev n’est pas un cache. Il peut contenir des métadonnées requises (et éventuellement des petits blocs). Le perdre peut rendre le pool inutilisable.

La récupération a été simple mais tendue : stabiliser le chemin du périphérique (c’était un connecteur de backplane marginal), remplacer le SSD défaillant et resilver le miroir du special vdev. Ensuite, le pool est revenu à des performances et une stabilité normales.

Leçon : si vous ajoutez un composant d’optimisation qui peut faire tomber tout le pool, ce n’est pas une optimisation. C’est une nouvelle couche d’infrastructure critique. Traitez-la comme telle.

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

Une équipe d’entreprise effectuait des scrubs hebdomadaires, des tests de restauration mensuels, et avait l’habitude, presque old-school, d’après tout changement matériel, de capturer zpool status, zpool get all pour les propriétés clefs, et un inventaire des périphériques avec serials et WWN. C’était de la paperasserie. Personne n’en tirait gloire.

Un après-midi, une étagère de stockage a rebooté de façon inattendue. L’OS est revenu avec un ordre d’énumération différent, et un chemin n’est pas revenu. Le pool ne s’est pas importé automatiquement. Le canal d’incident a commencé à se former, comme des nuages d’orage autour d’un pique-nique.

Au lieu d’improviser, ils ont suivi le playbook. Ils ont comparé l’inventaire by-id actuel avec le dernier snapshot capturé dans leurs propres archives, identifié précisément quel serial manquait, et corrélé avec les logs d’armoire. Ce n’était pas un disque mort — c’était un chemin SAS qui n’a pas réussi à se reconnecter après le reboot de l’étagère.

Ils ont réparé le chemin, relancé zpool import, importé en lecture seule pour valider, puis importé normalement. Pas de flags « force », pas de clear de labels, pas de magie. L’incident a été court parce que l’équipe avait passé des années à investir dans l’ennui.

Blague #2 : Le meilleur héroïsme du stockage est si terne que personne ne le remarque — comme un extincteur qui ne sert jamais.

Une citation à mettre dans votre canal d’incident

Werner Vogels (idée paraphrasée) : Tout échoue tout le temps ; concevez et opérez en supposant que la défaillance est normale.

Points de décision qui comptent (et pourquoi)

Import en lecture seule : votre soupape de sécurité

Quand vous n’êtes pas sûr de la stabilité des périphériques, l’import en lecture seule permet d’inspecter les datasets, valider les métadonnées et copier les données sans écrire. Ce n’est pas une cure ; c’est une posture diagnostique plus sûre.

Le scrub n’est pas un premier secours ; c’est un examen complet

Un scrub est lourd. Il touche tout. Sur un pool avec un disque marginal ou un HBA instable, scruber peut transformer « presque OK » en « maintenant on a découvert chaque secteur faible en même temps ». Cette découverte est utile, mais pas quand votre couche transport est en feu.

La vitesse de resilver est un signal de santé, pas un confort

Les resilvers lents arrivent pour des raisons innocentes (pool occupé, comportement SMR). Ils arrivent aussi parce que le système effectue des retries infinis sur des lectures. Surveillez les resets et les erreurs I/O dans les logs ; c’est là que la vérité se cache.

FAQ

1) Dois-je redémarrer un serveur ZFS quand le pool est dégradé ?

Pas en première action. Rebooter peut réordonner les périphériques, perdre un état transitoire et faire d’un lien qui flap un disque manquant. Stabilisez le matériel et capturez les sorties d’abord.

2) Quand `zpool import -f` est-il approprié ?

Quand vous avez confirmé que le pool n’est pas importé ailleurs et que l’état « in use » est obsolète (déplacement d’hôte, crash). Préférez -o readonly=on -N avec -f pour le premier import si vous avez un doute.

3) Si SMART indique « PASSED », le disque peut-il quand même être mauvais ?

Oui. « PASSED » est souvent un contrôle de seuil. Les secteurs pending, les uncorrectable et la croissance des erreurs CRC sont des signaux opérationnels indépendamment du résultat global.

4) Que signifient réellement les erreurs de checksum ?

ZFS a lu des données, a calculé le checksum et cela n’a pas correspondu à ce qui est stocké. Les données corrompues peuvent provenir du média disque, d’un câble, d’un contrôleur, de la RAM ou même du firmware. Traitez cela comme une preuve et corrélez.

5) Un scrub est-il la même chose qu’un resilver ?

Non. Un scrub est une vérification proactive de toutes les données. Un resilver est la reconstruction sur un remplacement ou un périphérique de retour. Les deux lisent beaucoup ; le resilver écrit aussi.

6) Puis-je simplement détacher un périphérique « cache » défaillant pour remettre le pool en ligne ?

Ça dépend de ce que c’est. L2ARC est généralement amovible sans perdre l’intégrité du pool. Un périphérique SLOG peut souvent être retiré avec des précautions. Un special vdev peut être requis — ne le traitez pas comme un cache.

7) Pourquoi ZFS affiche-t-il un long ID numérique au lieu d’un nom de périphérique ?

C’est le GUID du vdev. ZFS l’utilise pour suivre les membres même si les chemins de périphériques changent. C’est aussi un indice que ZFS se souvient de quelque chose que l’OS ne présente pas actuellement.

8) Quelle est la façon la plus sûre de déplacer un pool vers une autre machine pour récupération ?

Exporter le pool proprement si possible, déplacer les disques, puis importer en lecture seule avec une racine alternative (-o readonly=on -R /mnt -N) pour inspecter avant d’engager des écritures.

9) Si le pool est dégradé, dois-je exécuter `zpool clear` pour le « réparer » ?

Non. zpool clear réinitialise les compteurs d’erreurs. C’est utile après avoir corrigé la cause sous-jacente pour confirmer si les erreurs reviennent. Cela ne répare pas les données.

10) Comment décider entre « remplacer le disque » et « réparer le câblage » ?

Regardez les preuves : les erreurs CRC et les resets de lien suggèrent le transport. Les secteurs pending/uncorrectable suggèrent le média. Si plusieurs disques sur le même chemin HBA montrent des problèmes, suspectez le composant partagé.

Conclusion : prochaines étapes réellement faisables

Si vous ne retenez rien d’autre : stabilisez la couche périphérique, importez en lecture seule quand vous doutez, et ne remplacez jamais un disque que vous ne pouvez pas identifier positivement. ZFS est conçu pour survivre à des défaillances matérielles. Il est moins tolérant à l’improvisation.

Prochaines étapes pratiques pour votre environnement :

Rédiger une page de runbook on-call utilisant le « Playbook de diagnostic rapide » et les checklists ci-dessus.
Assurer que chaque pool utilise des chemins de périphérique stables (by-id/WWN) et documenter comment mapper les serials aux baies.
Planifier des scrubs et alerter sur les nouvelles erreurs de checksum, pas seulement sur l’état du pool.
Tester les restaurations. Pas en théorie. Sur de vraies données. Le jour où vous en aurez besoin n’est pas le jour pour découvrir que vos sauvegardes sont de l’art conceptuel.
Auditer tous les vdevs « optimisation » (special, SLOG) et s’assurer qu’ils sont redondants et monitorés comme des éléments de première importance.