ZFS offline/online : Mode maintenance sans compromettre la redondance

Offline/online sans superstition : le modèle mental

ZFS ne fait pas du « RAID » comme votre contrôleur matériel en 2012. Il utilise des vdevs (virtual devices), et la redondance vit au niveau du vdev.
Un pool n’est sain qu’au niveau de son vdev le moins redondant, car toute perte d’un vdev équivaut à une perte de pool. C’est le point principal.

Quand vous exécutez zpool offline, vous n’enlevez pas un disque de l’historique du pool. Vous dites à ZFS :
« Ne faites plus confiance à ce périphérique feuille pour les E/S maintenant. » C’est un changement d’état opérationnel, pas un changement de topologie.
À comparer avec zpool detach (mirror uniquement), qui modifie la topologie en supprimant un périphérique d’un vdev mirror.

Ce que « offline » signifie vraiment

• Offline : le périphérique est intentionnellement indisponible. ZFS ne l’utilisera pas. Le vdev/pool peut devenir DEGRADED.
• Faulted : ZFS a décidé que le périphérique est défectueux (trop d’erreurs, timeouts, etc.). Vous devrez peut‑être le clear/remplacer.
• Removed : le périphérique a disparu (câble, châssis, chemin, HBA, multipath). Parfois il revient ; parfois il ment.
• Unavailable : ZFS ne peut pas ouvrir le chemin du périphérique. Cela inclut les renommages, l’absence de by-id, ou des soucis d’armoire/enclosure.

Offline vs replace vs detach : choisissez le bon verbe

Voici la règle que j’applique en production : utilisez le plus petit marteau qui vous amène de façon fiable à l’état sûr suivant.

• Utilisez zpool offline pour retirer un disque du service temporairement, surtout avant un travail physique.
• Utilisez zpool replace quand vous échangez des médias et voulez que ZFS considère le nouveau disque comme successeur.
• Utilisez zpool detach uniquement sur des mirrors, et seulement quand vous avez vraiment l’intention de réduire la largeur du mirror.
• Évitez de « tirer » sans offliner d’abord, sauf si vous êtes déjà en mode urgence (disque mort ou bus en feu).

La redondance n’est pas un concept philosophique. C’est de l’arithmétique : combien de périphériques peuvent manquer dans le même vdev avant que vous ne perdiez des données.
Les mirrors tiennent généralement un disque manquant (par mirror). RAIDZ1 tient un. RAIDZ2 tient deux. RAIDZ3 tient trois.
Mais la maintenance crée souvent une deuxième défaillance : vous offlinez un disque, puis découvrez qu’un autre mourait silencieusement. Félicitations, vous venez d’inventer un postmortem.

Une citation à garder sur votre terminal : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan.
Les équipes stockage aiment l’espoir. ZFS le sanctionne.

Blague n°1 : Si vous n’avez jamais mis hors ligne le mauvais disque, soit votre étiquetage est parfait—soit vous n’avez pas encore fait assez de maintenance.

Faits et historique utiles

1. ZFS est né chez Sun Microsystems au milieu des années 2000 en réaction aux piles stockage « split‑brain » (gestionnaire de volumes + système de fichiers) incapables de coordonner l’intégrité.
2. Le terme « pool » était un changement de paradigme volontaire : on ne gère pas des systèmes de fichiers sur des disques ; on gère capacité et redondance comme une ressource partagée.
3. ZFS checksum tout (métadonnées et données). C’est pourquoi un pool dégradé n’est pas automatiquement un pool risqué—jusqu’à la perte de la dernière copie saine.
4. Le scrub existe pour combattre la « bit rot » avant que ce soit tendance. Dans ZFS, scrub est une lecture/validation/réparation proactive via la redondance ; ce n’est pas un « fsck ».
5. Resilver n’est pas un scrub. Resilver reconstruit les réplicas manquants après un remplacement/offline/online ; scrub vérifie tout le pool.
6. Le nom by-id est devenu une tactique de survie quand le nommage Linux (/dev/sdX) s’est montré trop changeant sous hotplug, multipath et resets HBA.
7. Les premiers admins ZFS ont appris à la dure au sujet des caches d’écriture : des disques qui mentent sur les flushes peuvent compromettre un système de fichiers, même transactionnel.
8. Le comportement de rebuild RAIDZ diffère du RAID5/6 traditionnel : le resilver ZFS ne copie que les blocs alloués (plus les métadonnées), ce qui peut être beaucoup plus rapide—sauf si le pool est très plein.
9. Les états « REMOVED » ont augmenté avec les SAS expanders et JBODs : un glitch d’armoire transitoire peut ressembler à une défaillance disque, et le traiter comme tel peut aggraver le risque.

Ce ne sont pas des trivia. Chacun change votre façon de répondre quand un disque disparaît et que quelqu’un demande,
« On peut juste le mettre hors ligne et continuer ? »

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

Voici les tâches concrètes que vous effectuerez pendant une fenêtre de maintenance. Pour chacune : la commande, ce que la sortie signifie, et la décision suivante.
Les exemples supposent un pool nommé tank. Adaptez les noms.

Tâche 1 : Confirmer la topologie du pool avant toute manipulation

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: Some supported and requested features are enabled on the pool.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    ONLINE       0     0     0
          raidz2-0                              ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF    ONLINE       0     0     0

errors: No known data errors

Signification : Vous avez un vdev RAIDZ2 unique. Vous pouvez tolérer deux disques manquants dans ce vdev ; une troisième perte tue le pool.
Les noms by-id semblent stables et précis. Bien.

Décision : Si vous comptez mettre un disque hors ligne, vous consommez une « vie » de redondance. Vérifiez qu’il n’y a pas déjà de membres degraded/faulted.

Tâche 2 : Vérifier que vous n’êtes pas déjà dégradé (ne pas cumuler les défaillances)

cr0x@server:~$ zpool list -o name,size,alloc,free,health tank
NAME  SIZE  ALLOC   FREE  HEALTH
tank  43.5T  34.9T  8.6T  ONLINE

Signification : HEALTH est ONLINE. Alloc est assez élevé. Une forte occupation ralentit et rend les resilvers plus risqués (moins d’espace libre, plus de fragmentation).

Décision : Si HEALTH est DEGRADED ou ALLOC est presque plein, traitez la maintenance comme une chirurgie : minimisez le temps en dégradé et envisagez de reporter les travaux non critiques.

Tâche 3 : Identifier le disque physique derrière un périphérique feuille ZFS

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep VKJ0A1AD
lrwxrwxrwx 1 root root  9 Dec 25 03:10 ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD -> ../../sdg

Signification : Le périphérique feuille ZFS correspond actuellement à /dev/sdg. Cela peut changer après un reboot ; by-id est la référence stable.

Décision : Utilisez les noms by-id dans ZFS autant que possible. Utilisez /dev/sdX uniquement pour des vérifications OS transitoires.

Tâche 4 : Vérifier SMART avant de conclure que c’est « juste un câble »

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i 'Serial Number|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count'
Serial Number:    VKJ0A1AD
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       8
197 Current_Pending_Sector  0x0012   200   200     0    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   200   200     0    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200     0    Old_age   Always       -       0

Signification : Des secteurs réalloués et en attente existent. C’est un problème média, pas seulement un câble défaillant (les erreurs CRC indiqueraient le câblage).

Décision : Planifiez un remplacement, pas un « reseat et prière ». Offlinez d’abord, remplacez, laissez resilver, puis scrub plus tard.

Tâche 5 : Mettre le disque cible hors ligne (mode maintenance, intentionnel)

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    DEGRADED     0     0     0
          raidz2-0                              DEGRADED     0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD    OFFLINE      0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF    ONLINE       0     0     0

errors: No known data errors

Signification : Le pool est DEGRADED suite à une action administrateur, pas à une faute. C’est le type de dégradé le plus sûr : vous contrôlez la situation.

Décision : Procédez au travail physique. Et : figez les autres changements risqués. Ce n’est pas le moment pour des upgrades kernel ou des expérimentations firmware HBA.

Tâche 6 : Confirmer que le disque n’est réellement pas utilisé (éviter des E/S surprises)

cr0x@server:~$ sudo zpool iostat -v tank 1 3
                                          capacity     operations     bandwidth
pool                                    alloc   free   read  write   read  write
--------------------------------------  -----  -----  -----  -----  -----  -----
tank                                    34.9T  8.6T     45     30  4.20M  2.10M
  raidz2-0                               34.9T  8.6T     45     30  4.20M  2.10M
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA        -      -      8      5   710K   380K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB        -      -      7      5   690K   370K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC        -      -      9      5   740K   400K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD        -      -      0      0      0      0
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE        -      -      6      5   670K   360K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF        -      -      6      5   690K   380K
--------------------------------------  -----  -----  -----  -----  -----  -----

Signification : Le périphérique offlined ne montre aucune ops/bande passante. Attendu. Si vous voyez des E/S sur une feuille « offline », quelque chose cloche (alias, multipath, mauvais nom).

Décision : En cas d’activité inattendue, arrêtez et revérifiez l’identité du périphérique avant de retirer quoi que ce soit.

Tâche 7 : Remplacer le disque et informer explicitement ZFS (ne pas compter sur l’autodétection)

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep VKJ0A1AD
lrwxrwxrwx 1 root root  9 Dec 25 03:10 ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD -> ../../sdg

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep NEWDRIVE
lrwxrwxrwx 1 root root  9 Dec 25 03:42 ata-WDC_WD80EFZX-68UW8N0_NEWDRIVE -> ../../sdg

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD ata-WDC_WD80EFZX-68UW8N0_NEWDRIVE

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    DEGRADED     0     0     0
          raidz2-0                              DEGRADED     0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC    ONLINE       0     0     0
            replacing-3                         DEGRADED     0     0     0
              ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD  OFFLINE      0     0     0
              ata-WDC_WD80EFZX-68UW8N0_NEWDRIVE  ONLINE       0     0     0  (resilvering)
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF    ONLINE       0     0     0

scan: resilver in progress since Thu Dec 25 03:43:11 2025
        1.26T scanned at 1.45G/s, 312G issued at 360M/s, 34.9T total
        52.0G resilvered, 0.86% done, 1 days 02:13:08 to go
errors: No known data errors

Signification : ZFS a créé un sous‑arbre « replacing », traçant ancien vs nouveau. L’estimation est souvent pessimiste au début.

Décision : N’offlinez pas un autre disque « pour être sûr ». Vous êtes déjà en marge réduite jusqu’à la fin du resilver.

Tâche 8 : Surveiller la progression du resilver et décider de limiter les charges

cr0x@server:~$ zpool iostat -v tank 5

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
scan: resilver in progress since Thu Dec 25 03:43:11 2025
        9.80T scanned at 1.12G/s, 2.01T issued at 235M/s, 34.9T total
        1.62T resilvered, 5.76% done, 0 days 19:04:55 to go

Signification : « scanned » est ce que ZFS a examiné ; « issued » est ce qu’il a réellement dû reconstruire/copy. Issued est ce qui stresse les disques.

Décision : Si la latence applicative augmente, envisagez de réduire temporairement les jobs écriture lourds, les sauvegardes ou compactions. Votre objectif est « finir le resilver sans seconde défaillance », pas « battre des records ».

Tâche 9 : Remettre en ligne un disque précédemment offlined (quand le problème est transitoire)

cr0x@server:~$ sudo zpool online tank ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
status: One or more devices has been brought online.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    ONLINE       0     0     0
          mirror-0                              ONLINE       0     0     0
            ata-SAMSUNG_MZ7KM960_ABC123          ONLINE       0     0     0
            ata-SAMSUNG_MZ7KM960_DEF456          ONLINE       0     0     0

errors: No known data errors

Signification : Online remet la feuille en service. Selon l’incident, ZFS peut resilver pour resynchroniser.

Décision : Si le disque a été offlined pour suspicion d’erreurs média, ne le onlinez pas « pour voir ». Remplacez‑le. La curiosité coûte cher en stockage.

Tâche 10 : Effacer les erreurs transitoires après avoir résolu la cause (pas avant)

cr0x@server:~$ zpool status -v tank
  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.
  see: http://zfsonlinux.org/msg/ZFS-8000-8A
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    DEGRADED     0     0     0
          mirror-0                              DEGRADED     0     0     0
            ata-SAMSUNG_MZ7KM960_ABC123          ONLINE       0     0     7
            ata-SAMSUNG_MZ7KM960_DEF456          ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/data/app.db

cr0x@server:~$ sudo zpool clear tank

Signification : zpool clear remet à zéro les compteurs d’erreurs et états de faute, mais ne répare pas magiquement des données applicatives corrompues.

Décision : Clear uniquement après avoir corrigé la cause sous‑jacente et après avoir traité les « Permanent errors » au niveau dataset/app.

Tâche 11 : Confirmer l’identité du périphérique avec les labels ZFS (quand by-id ment ou duplique)

cr0x@server:~$ sudo zdb -l /dev/sdg | egrep 'name:|pool_guid|vdev_tree|guid'
    name: 'tank'
    pool_guid: 17219319428190311341
    guid: 1329582641194012239

Signification : zdb -l lit le label ZFS sur disque et indique à quel pool il appartient. C’est votre outil de « forensique » quand les chemins sont confus.

Décision : Si un disque ne se label pas comme prévu, stop. Vous regardez peut‑être le disque d’un autre pool ou un spare obsolète.

Tâche 12 : Vérifier que vous n’allez pas resilver depuis un chemin plus lent (multipath/sas)

cr0x@server:~$ lsblk -o NAME,HCTL,SIZE,MODEL,SERIAL,TRAN
NAME HCTL       SIZE MODEL            SERIAL   TRAN
sdg  2:0:6:0    7.3T WDC WD80EFZX-68U NEWDRIVE sas

Signification : HCTL vous donne le chemin controller:target:lun. Utile pour mapper aux ports HBA et aux baies d’expander.

Décision : Si le « nouveau disque » apparaît sur un HCTL inattendu, vous avez peut‑être inséré dans la mauvaise baie. Corrigez‑le maintenant, pas après 12 heures de resilver.

Tâche 13 : Vérifier un scrub/resilver en cours avant de commencer la maintenance (ne pas s’ajouter des tâches)

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
scan: scrub in progress since Thu Dec 25 01:12:04 2025
        18.3T scanned at 710M/s, 18.3T issued at 710M/s, 34.9T total
        0B repaired, 52.4% done, 0 days 05:22:19 to go

Signification : Un scrub est déjà en train de stresser tous les disques. Mettre un disque hors ligne pendant un scrub force ZFS à travailler plus sur les membres restants.

Décision : Privilégiez la pause/l’arrêt du scrub avant une maintenance planifiée si la politique le permet. Si vous devez continuer, acceptez plus de risque et des durées plus longues.

Tâche 14 : Arrêter un scrub (intentionnellement) pour réduire la charge pendant un resilver critique

cr0x@server:~$ sudo zpool scrub -s tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
scan: scrub canceled on Thu Dec 25 03:55:10 2025

Signification : Le scrub a été annulé. Vous n’avez pas réparé l’intégrité ; vous avez réduit la charge. C’est acceptable quand vous gérez le risque.

Décision : Replanifiez le scrub après le resilver et hors heures d’activité. Ne laissez pas le pool sans scrub parce que vous étiez occupé.

Tâche 15 : Exporter/importer comme réinitialisation contrôlée (quand un état de périphérique reste bloqué)

cr0x@server:~$ sudo zpool export tank

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
errors: No known data errors

Signification : Export/import peut résoudre certains problèmes de chemins obsolètes et force un rescan. C’est disruptif : les datasets disparaissent brièvement.

Décision : Utilisez‑le pendant des fenêtres de maintenance, pas en pleine production. Si le problème est matériel, export/import ne le guérira pas.

Tâche 16 : Définir une politique de spare temporaire (si vous avez des spares)

cr0x@server:~$ 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-HGST_HUH721010ALE604_AAA111  OFFLINE      0     0     0
            ata-HGST_HUH721010ALE604_BBB222  ONLINE       0     0     0
        spares
          ata-HGST_HUH721010ALE604_SPARE33   AVAIL

cr0x@server:~$ sudo zpool replace tank ata-HGST_HUH721010ALE604_AAA111 ata-HGST_HUH721010ALE604_SPARE33

Signification : Vous pouvez remplacer activement un disque OFFLINE/FAULTED par un hot spare disponible. ZFS va resilver sur le spare.

Décision : Utilisez les spares pour gagner du temps, pas pour éviter un remplacement correct. Les spares doivent être restaurés en « AVAIL » après installation d’un vrai disque.

Patrons de mode maintenance (mirror, RAIDZ, spares)

Patron A : vdev mirror — l’endroit le plus sûr pour s’entraîner

Les mirrors sont indulgents pendant la maintenance parce que l’arithmétique de redondance est simple : un côté peut disparaître et vous avez toujours une copie complète.
Cela ne signifie pas que vous pouvez devenir négligent. Les mirrors échouent de manière banale : les deux disques achetés ensemble, ayant subi la même charge, vieillissent de la même façon.

Pour les mirrors, vous avez généralement trois flux sensés :

• Offline → replace → resilver (préféré pour un échange physique).
• Offline → online (pour un problème de chemin/câble suspect, après correction).
• Detach (seulement quand vous réduisez volontairement la largeur du mirror, ou pour séparer un mirror pour migration/test en acceptant le risque).

Évitez d’utiliser « detach » dans la maintenance routinière. Detach est définitif. Offline est un bouton pause.

Patron B : RAIDZ — la maintenance est un exercice de budget de risque

RAIDZ est là où les gens prennent des mesures « raisonnables » qui deviennent déraisonnables dès qu’une seconde variable change.
En RAIDZ2, mettre un disque hors ligne pour travail planifié est généralement acceptable. Mais votre risque est concentré :
toute autre défaillance disque ou un châssis instable qui coupe deux chemins à la fois peut vous mener à un état irrécupérable.

Conseils pratiques :

• Minimisez le temps en dégradé. Ayez le disque de remplacement pré‑rodé, étiqueté et prêt.
• Ne faites pas d’expériences firmware pendant que vous êtes en dégradé. Le reset HBA « que vous n’avez jamais vu » arrivera à ce moment‑là.
• Surveillez l’occupation du pool. Une forte allocation tend à augmenter le temps de resilver et la charge, augmentant la probabilité d’une seconde défaillance.
• Privilégiez les resilvers en journée. Le moyen le plus rapide d’obtenir de l’aide est de commencer pendant que les gens sont réveillés et que Slack est bruyant.

Patron C : Hot spares — utiles, mais faciles à mal utiliser

Les hot spares servent à réduire le temps moyen en dégradé, pas à remplacer la maintenance matérielle.
Le schéma d’échec courant : le spare s’active, tout le monde se détend, des semaines passent, et maintenant le spare est « partie intégrante du pool » sans spare restant.
La prochaine défaillance s’en moque.

Ce qu’il ne faut pas faire : « mode maintenance » en arrachant des disques

Des gens le font encore parce que c’est rapide et parfois ça marche.
Le coût est que vous perdez la possibilité de confirmer l’identité, vous risquez un événement au niveau du bus, et vous créez des états ambigus (« REMOVED », « UNAVAIL ») qui compliquent la récupération.
Offline est une commande en une ligne. Utilisez‑la.

Blague n°2 : Le moyen le plus rapide de découvrir que votre processus d’étiquetage est mauvais est de faire des échanges de disques à 2h du matin sous une lampe de poche.

Feuille de route pour diagnostic rapide (trouver le goulot vite)

Quand un pool devient DEGRADED ou qu’un resilver traîne, vous n’avez pas le temps de lire tous les posts de forum jamais écrits.
Vous avez besoin d’un ordre de triage qui trouve rapidement le facteur limitant.

Première étape : confirmer ce que ZFS pense se passer

• Commande : zpool status -v
• Regarder : OFFLINE vs FAULTED vs REMOVED, sous‑arbre « replacing », section « scan: », compteurs d’erreurs.
• Décision : Si un périphérique est FAULTED avec erreurs read/write/cksum, planifiez un remplacement. S’il est REMOVED/UNAVAIL, investiguez le chemin/HBA/enclosure d’abord.

Deuxième étape : vérifier si vous vous battez contre le système (scrub, écritures lourdes, quotas, snapshots)

• Commande : zpool status pour scrub/resilver ; zpool iostat -v 1 pour la forme de charge
• Regarder : scrub en cours, bande passante d’écriture massive, un disque saturé, faible taux « issued »
• Décision : Si le resilver est lent et le pool occupé, soit throttlez les charges, soit acceptez un temps dégradé plus long. Le temps en dégradé est du temps à risque.

Troisième étape : isoler les problèmes de chemin matériel

• Commandes : smartctl -a, lsblk -o NAME,HCTL,SERIAL,TRAN, et logs kernel via dmesg -T
• Regarder : resets de lien, flaps SAS phy, timeouts, erreurs CRC, échecs de commandes en queue
• Décision : Si plusieurs disques montrent des erreurs de transport, arrêtez de remplacer des « mauvais disques » et commencez par vérifier HBA, expander, alimentation du châssis et câblage.

Quatrième étape : vérifier que vous n’êtes pas à court de budget de redondance

• Commande : zpool status et calculez mentalement : combien de pannes ce vdev peut encore encaisser ?
• Regarder : RAIDZ1 avec un disque offline = aucune marge ; mirror avec un côté en échec = aucune marge
• Décision : Si la marge est nulle, arrêtez tout travail électif. Votre objectif devient « redevenir redondant ASAP », même si cela signifie suspendre des workloads.

Cinquième étape : vérifier l’occupation du pool et la fragmentation comme multiplicateur de temps de resilver

• Commande : zpool list
• Regarder : ALLOC élevé, FREE bas, scrubs historiquement lents
• Décision : Si le resilver est lent à cause de l’occupation, vous ne pouvez pas le corriger en vol. Servez‑vous de cela pour justifier une réserve de capacité lors du prochain cycle budgétaire.

Erreurs courantes : symptôme → cause → correction

1) Symptom : le pool est DEGRADED après une maintenance « simple » ; personne ne sait pourquoi

Cause racine : Le disque a été arraché sans être offlined, et les noms de périphériques ont changé après un rescan/reboot.

Correction : Utilisez zpool status pour identifier la feuille manquante par by-id, confirmez avec zdb -l, remettez dans la baie correcte, puis zpool online ou zpool replace selon le cas.

2) Symptom : resilver « bloqué » à 0% ou progresse douloureusement lentement

Cause racine : Le pool est saturé par des écritures applicatives ou un autre scrub ; ou le disque de remplacement est SMR/lent ; ou il y a un problème de transport provoquant des retries.

Correction : Confirmez avec zpool iostat -v quel périphérique est le goulot. Vérifiez smartctl et dmesg -T pour erreurs/timeouts. Réduisez la charge, arrêtez le scrub si nécessaire, et envisagez de remplacer le disque de remplacement s’il est clairement sous‑performant.

3) Symptom : vous avez offlined un disque, et un second disque montre soudain des erreurs

Cause racine : Vous avez retiré de la redondance, augmentant la pression de lecture sur les disques restants ; des erreurs de secteurs latentes sont apparues sous charge.

Correction : Ne « onlinez » pas le disque mauvais juste pour récupérer de la marge. Remplacez les disques défaillants dans l’ordre le plus sûr, envisagez l’usage d’un spare, et maintenez des charges conservatrices jusqu’à restauration de la redondance.

4) Symptom : « cksum errors » sur un disque mais SMART semble correct

Cause racine : Câblage, HBA, expander ou backplane corrompant les données en transit ; parfois la mémoire, mais généralement le transport.

Correction : Vérifiez les erreurs CRC/transport et les logs. Reseat/remplacez le câble, changez de baie, validez la stabilité du firmware HBA. Clear les erreurs seulement après avoir fixé le transport et scrubbé pour confirmer l’absence de nouvelle corruption.

5) Symptom : disque remplacé, mais ZFS continue de référencer l’ancien nom by-id

Cause racine : Le remplacement a été fait sans zpool replace, ou l’OS a présenté un chemin différent ; ZFS suit l’ancienne identité de feuille.

Correction : Utilisez zpool status pour voir l’arbre « replacing ». Si nécessaire, faites explicitement zpool replace l’ancienne feuille par la nouvelle by-id. Confirmez avec zpool status que le resilver est lancé.

6) Symptom : pool devient UNAVAIL après export/import pendant un échange de disque

Cause racine : Trop de périphériques manquants pour un vdev, ou l’import a été tenté sans chemins corrects (by-id manquant), ou un disque appartient à un autre pool.

Correction : Utilisez zpool import sans arguments pour lister les pools, ajoutez -d /dev/disk/by-id, confirmez les labels avec zdb -l. N’utilisez pas import -f sans en comprendre les conséquences.

7) Symptom : après avoir remis un disque online, ZFS ne resilver pas et vous craignez une divergence silencieuse

Cause racine : Le périphérique est revenu sans changements nécessaires (il était offline brièvement), ou ZFS estime qu’il est à jour à cause de l’état des transaction groups.

Correction : Confirmez avec zpool status (l’absence de resilver n’est pas automatiquement mauvaise). Lancez un scrub après la maintenance pour valider l’intégrité bout à bout.

8) Symptom : « trop d’erreurs » et ZFS marque un disque FAULTED qui passe les diagnostics vendor

Cause racine : Timeouts intermittents sous charge, firmware instable, ou resets HBA/enclosure que les tests vendor ne reproduisent pas.

Correction : Traitez les timeouts comme réels. Corrélez avec les logs système, remplacez composants douteux, et préférez des HBA/enclosures stables plutôt que « il a passé un test rapide ».

Trois mini-histoires du monde de l’entreprise

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

Une entreprise SaaS de taille moyenne utilisait ZFS sur Linux pour un store d’objets multi‑locataires. Le pool était en RAIDZ2, dense en JBOD, rien d’exotique.
Ils avaient une routine : si un disque affichait quelques erreurs de checksum, ils le mettaient hors ligne, planifiaient le remplacement et continuaient.

Une nuit, un disque commença à logger des timeouts. L’on‑call le mit offline et ouvrit un ticket pour un swap le matin.
L’hypothèse était que « offline = sûr » et que le reste du vdev porterait silencieusement la charge.

Ce qu’ils ont manqué : le pool était déjà fortement alloué, et des jobs batch nocturnes avaient démarré—lectures et écritures massives.
Avec un disque offlined, ZFS disposait de moins de parallélisme et davantage de reconstruction par lecture. La latence monta. Les clients réessayèrent. La tempête de retries amplifia la charge.

Deux heures plus tard, un second disque (même modèle, même lot d’achat) commença à retourner des secteurs illisibles sous la charge accrue.
Ce disque n’était pas « nouvellement mauvais ». Il avait été nouvellement testé. Le pool passa de « dégradé planifié » à « en défaillance active ».

Ils se sont remis, mais la fenêtre de réparation s’est allongée : disques de remplacement, resilver, puis un scrub qui a trouvé quelques erreurs permanentes dans des objets froids.
Le postmortem ne concernait pas ZFS. Il portait sur l’hypothèse que le mode dégradé est un état opérationnel stable. Ce n’est pas le cas ; c’est une voie d’urgence.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une organisation financière voulait des rebuilds plus rapides. Quelqu’un proposa une « amélioration » simple : planifier des scrubs hebdomadaires pendant les heures de bureau parce que « les scrubs gardent tout sain »
et « il vaut mieux trouver les erreurs tôt ». Ça semblait raisonnable.

Le pool servait des VM. La charge était sensible à la latence : petits writes synchrones, pics de lectures. Le scrub tournait, les caches se réchauffaient, et les performances semblaient correctes—au début.
Après quelques semaines, un schéma apparut : chaque jour de scrub provoquait quelques pauses VM et alertes de stockage. Pas de outage, mais une perte de confiance progressive.

Puis un disque a réellement claqué pendant un scrub. L’équipe l’a remplacé rapidement, mais ils se retrouvèrent avec la charge du scrub plus celle du resilver plus la charge business du jour.
Le temps de resilver grimpa. Le pool resta dégradé beaucoup plus longtemps que d’habitude. L’« optimisation » avait prolongé la fenêtre de risque.

La correction fut ennuyeuse : déplacer les scrubs en fenêtres à faible trafic, imposer des throttles de charge pendant le resilver, et traiter la planification de scrub comme un changement de production avec impact SLO.
Leurs rebuilds ne sont pas devenus plus rapides. Leurs incidents sont devenus plus rares.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une plateforme de santé avait un contrôle de changement strict. Ça agaçait tout le monde, ce qui est la preuve que ça fonctionnait.
Leur runbook stockage exigeait : nommage by-id partout, cartes de baies imprimées mises à jour à chaque changement de châssis, et vérification à deux personnes avant tout pull de disque.

Lors d’un remplacement planifié, le technicien sur site trouva que l’étiquette de baie ne correspondait pas au mapping OS. Le geste facile aurait été de « tirer celui qui semble être le bon ».
Au lieu de ça, ils suivirent le processus : offliner la feuille cible par by-id, confirmer 0 E/S sur ce périphérique avec zpool iostat -v, puis matcher les numéros de série via smartctl.

La discordance s’avéra être due à un swap de backplane quelques mois plus tôt, avec numérotation des baies inversée par le firmware de l’enclosure.
S’ils avaient tiré selon l’autocollant physique, ils auraient retiré un disque sain en laissant le défaillant en ligne—exactement le type de chaos qui rend RAIDZ fragile.

Ils mirent à jour la carte de baies, échangèrent le bon disque, resilverèrent, scrubbrent, et continuèrent. Pas d’incident. Pas d’appel en pont.
La seule victime fut la croyance de quelqu’un que le processus est de la « paperasserie ». Le processus évite de réapprendre la même leçon.

Checklists / plan étape par étape

Maintenance planifiée d’un disque (disque unique) — workflow sûr

1. Confirmer la redondance et l’état courant
   Lancez zpool status -v et zpool list. Si déjà dégradé, arrêtez et réévaluez. Ne cumulez pas le risque.
2. Identifier le disque sans ambiguïté
   Utilisez by-id, puis mappez vers /dev/sdX avec ls -l /dev/disk/by-id. Vérifiez le serial via smartctl -a.
3. Vérifier si c’est média ou transport
   Des secteurs pending/realloués suggèrent le média. Des resets CRC/lien suggèrent le transport. Décidez si vous remplacez un disque ou réparez un chemin.
4. Mettre le disque hors ligne
   zpool offline tank <by-id>. Confirmez qu’il apparaît OFFLINE et qu’il n’y a pas d’E/S.
5. Effectuer l’échange physique
   Utilisez les cartes de baies. Ne comptez pas sur « c’est probablement celui qui clignote » sauf si vous avez une fonction locate validée.
6. Confirmer l’identité du nouveau disque
   Vérifiez by-id et serial. Assurez‑vous de ne pas avoir inséré par erreur une capacité/modèle incorrect.
7. Remplacer explicitement
   zpool replace tank <old-by-id> <new-by-id>. Confirmez l’état « replacing » et le début du resilver.
8. Surveiller le resilver et la santé système
   Suivez zpool status et zpool iostat -v. Vérifiez les logs kernel pour resets/timeouts.
9. Retour en ONLINE et restauration de la posture spare
   Quand le resilver est terminé, assurez‑vous que le pool est ONLINE et que vous avez encore un spare AVAIL si votre politique l’exige.
10. Scrub après coup
    Planifiez un scrub dans une fenêtre sûre pour valider l’intégrité complète après l’événement.

Événement disque d’urgence (FAULTED/REMOVED inattendu) — workflow de confinement

1. Arrêter l’hémorragie : capturez la sortie zpool status -v pour le ticket et le log d’incident.
2. Déterminer le type d’état : FAULTED suggère un remplacement ; REMOVED/UNAVAIL suggère une investigation du chemin d’abord.
3. Vérifier des problèmes systémiques : si plusieurs disques rapportent des erreurs, suspectez HBA/enclosure/câblage/alimentation.
4. Réduire la charge : pausez les scrubs, reportez les jobs batch, réduisez les opérations écriture lourdes si possible.
5. Restaurer la redondance ASAP : remplacez le disque ou restaurez le chemin. Utilisez un hot spare si nécessaire pour gagner du temps.
6. Valider : fin de resilver, puis scrub plus tard, puis revue des compteurs d’erreurs.

Règles que j’applique (pour mieux dormir)

• Ne jamais offliner un disque en RAIDZ1 à moins d’être prêt à un remplacement le jour même et à une surveillance attentive.
• Ne jamais faire plusieurs échanges de disques concurrents dans le même vdev sauf si vous avez une procédure testée et documentée et une raison autre que l’impatience.
• Ne jamais clear des erreurs pour « faire taire une alerte » tant que vous n’avez pas compris la cause.
• Conserver toujours un enregistrement : feuille by-id, baie physique, numéro de série, lot d’achat si connu, et date du dernier scrub.

FAQ

1) Est‑ce que zpool offline réduit la redondance ?

Oui, de la seule manière qui compte : il retire un membre réplique/parité participant d’un vdev.
Le pool peut continuer à servir des données, mais vous avez moins de tolérance aux pannes jusqu’à ce que le périphérique revienne ou soit remplacé et resilver.

2) Dois‑je offliner un disque avant de le retirer physiquement ?

Pour la maintenance planifiée, oui. Offliner est un changement d’état intentionnel qui empêche les E/S surprises et vous aide à confirmer que vous avez ciblé le bon périphérique.
Si le disque est déjà mort/inaccessible, vous ne pourrez peut‑être pas l’offliner de façon significative—mais vous pouvez quand même procéder au remplacement.

3) Quelle est la différence entre offline et detach ?

offline est temporaire et ne change pas la topologie. detach supprime un périphérique d’un vdev mirror et change la topologie définitivement.
Utilisez detach quand vous en avez l’intention, pas comme raccourci de maintenance.

4) Puis‑je offliner un disque en RAIDZ2 et continuer le trafic de production ?

En général, oui. Mais « pouvoir » n’est pas « devoir sans adaptation ». Attendez‑vous à une latence plus élevée sous charge, à des resilvers plus longs, et à un risque accru de pannes latentes.
Réduisez la charge pendant la fenêtre dégradée si vous voulez que la maintenance reste ennuyeuse.

5) Pourquoi l’estimation du temps de resilver varie tant ?

Les estimations ZFS se basent sur le débit observé et le travail découvert jusqu’à présent. Tôt dans un resilver, il peut ne pas avoir cartographié la quantité réelle de données à reconstruire.
Surveillez « issued » et la bande passante réelle ; considérez les ETA comme des indices, pas des contrats.

6) Dois‑je scruber juste après avoir remplacé un disque ?

Pas immédiatement si le pool est occupé et sensible à la latence. D’abord : terminez le resilver et revenez à la redondance.
Ensuite, scrubez dans une fenêtre contrôlée pour valider l’intégrité sur l’ensemble du pool.

7) Je vois des erreurs de checksum, mais pas d’erreurs read/write. Est‑ce un problème de disque ?

Pas toujours. Les erreurs de checksum impliquent souvent le transport (câblage/backplane/HBA) parce que les données sont arrivées corrompues.
Vérifiez SMART (compteurs CRC), les logs système, et si plusieurs disques montrent les mêmes symptômes.

8) Est‑il sûr de remettre en ligne un disque qui a été offlined à cause d’erreurs ?

Si il a été offlined pour un travail de chemin transitoire et que vous avez corrigé le chemin, le online est acceptable et peut déclencher un resilver.
S’il a été offlined parce que le média défaillait (secteurs pending, uncorrectables), le remettre en ligne est un pari risqué pour la production.

9) Que faire si j’ai accidentellement offlined le mauvais disque ?

D’abord : stop. Confirmez la marge de redondance. Si vous avez encore de la marge, exécutez immédiatement zpool online sur le mauvais disque et vérifiez qu’il réintègre proprement.
Puis réidentifiez le bon disque en utilisant numéros de série et mapping by-id avant de continuer.

10) Comment les hot spares interagissent‑ils avec offline/online ?

Un spare peut être utilisé comme cible de remplacement via zpool replace, réduisant le temps en dégradé.
Mais une fois qu’un spare est actif, vous n’avez plus de spare. Remplacez le disque défaillant rapidement et restaurez le spare en AVAIL.

Conclusion : prochaines étapes pratiques

ZFS vous donne les outils pour traiter le travail sur disques comme une opération contrôlée au lieu d’une bagarre de bar avec un châssis serveur.
La différence entre « mode maintenance » et « mode incident » est généralement une chose : avez‑vous changé l’état intentionnellement et l’avez‑vous vérifié.

1. Standardisez le nommage by-id pour les pools et les runbooks. Si vos commandes dépendent de /dev/sdX, vous bâtissez sur du sable.
2. Faites du temps en dégradé une métrique. Suivez combien de temps les pools passent sans redondance complète ; optimisez pour des durées plus courtes, pas plus rapides.
3. Écrivez l’étape de vérification à deux personnes dans la politique pour les échanges physiques : map by-id → serial → baie, puis offline.
4. Planifiez les scrubs comme des changements de production, pas comme des corvées. Alignez‑les sur des fenêtres à faible trafic et une couverture d’intervention.
5. Entraînez‑vous au workflow sur un pool mirror non critique. C’est moins coûteux que de s’entraîner pendant une panne.

Lors de la prochaine fenêtre de maintenance, visez un seul résultat : vous pouvez expliquer chaque état de périphérique dans zpool status et pourquoi il a changé.
Si vous pouvez faire cela, vous n’êtes pas en train de deviner—vous opérez.