Proxmox ZFS « pool is not healthy » : que faire avant que ça empire

Ce que signifie réellement « pool is not healthy » dans Proxmox

Proxmox n’effectue pas d’analyse médico-légale approfondie de ZFS lorsqu’il affiche « pool is not healthy ». Il remonte généralement l’évaluation de santé de ZFS lui-même : l’état du pool n’est pas ONLINE et propre, ou ZFS a enregistré des erreurs qu’il n’a pas pu corriger complètement.

Les états courants derrière cet avertissement :

• DEGRADED : Un ou plusieurs vdevs sont manquants/défaillants, mais la redondance existe encore. Vous roulez sur la roue de secours.
• FAULTED : Le pool (ou un vdev) a perdu sa redondance et/ou son accès. Les lectures/écritures peuvent échouer.
• UNAVAIL : Des périphériques sont manquants, des chemins sont incorrects, ou le pool n’est pas accessible.
• SUSPENDED : ZFS a suspendu les E/S en raison d’échecs répétés. C’est ZFS qui dit « je ne vais pas vous aider à aggraver la situation ».

Séparément de l’état, ZFS suit aussi des compteurs d’erreurs :

• READ : erreurs de lecture — le périphérique n’a pas pu lire des blocs. Peut venir du média, d’un câble, du contrôleur ou du routage.
• WRITE : erreurs d’écriture — écritures échouées. Indique souvent un problème de périphérique/contrôleur.
• CKSUM (somme de contrôle) : données lues sur disque ne correspondant pas à leur checksum ; la redondance a peut‑être réparé. Ce cas est sournois parce que le disque peut « fonctionner » tout en renvoyant silencieusement des données erronées.

Voici le point opérationnel clé : « pool is not healthy » n’est pas un problème unique. C’est une étiquette de catégorie. Votre travail est de le classifier rapidement : s’agit‑il d’une défaillance de périphérique, d’un problème de chemin/câblage/contrôleur, d’un problème logique/de configuration ou d’une corruption réelle des données ?

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : Tout échoue, tout le temps ; concevez et exploitez comme si c’était toujours vrai.

Encore une chose : les clusters Proxmox compliquent les émotions. Quand le stockage d’un nœud devient bizarre, les gens commencent à blâmer le quorum, corosync, le réseau ou la météo. Ne le faites pas. Commencez par les preuves fournies par ZFS.

Blague #1 : Un pool ZFS « sain » c’est comme un enfant tranquille — vous ne vous en vantez pas, vous profitez juste du silence tant qu’il dure.

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

Ceci est la routine « s’orienter en cinq minutes ». L’objectif n’est pas une réparation complète. C’est d’identifier le mode de défaillance et décider si vous pouvez continuer en ligne, devez effectuer une maintenance, ou arrêter de toucher aux choses.

Premier : classer l’état du pool et le type d’erreur

• Exécutez zpool status -xv. Vous cherchez : state, quel périphérique est impliqué, si les erreurs sont READ/WRITE/CKSUM, et le texte exact du message.
• Si le pool est SUSPENDED ou affiche des erreurs permanentes dans des fichiers, considérez l’incident comme haute gravité. Arrêtez les « optimisations », commencez à préserver les preuves et à faire des sauvegardes.

Second : déterminer si c’est un problème de disque ou de chemin

• Vérifiez SMART rapidement : smartctl -a (ou le journal SMART NVMe). Cherchez des secteurs réalloués, des secteurs en attente, des erreurs CRC, des erreurs média.
• Vérifiez les logs du noyau pour des réinitialisations de lien, des erreurs d’E/S, des erreurs de transport : journalctl -k.
• Si vous voyez des storms CRC ou de réinitialisation de lien, suspectez d’abord les câbles/backplane/HBA avant de condamner le disque.

Troisième : décidez de la suite selon la redondance et le risque

• Si la redondance existe (miroir/RAIDZ) et qu’un seul périphérique est impacté : planifiez un remplacement/resilver contrôlé.
• Si la redondance est compromise (vdev mono-disque, RAIDZ avec plusieurs défaillances, plusieurs miroirs dégradés) : priorisez l’évacuation des données et la minimisation des écritures.
• Si c’est un scénario de performance + erreurs (scrub/resilver lent, timeouts) : vérifiez le queueing HBA, la négociation de vitesse SATA et la contention de charge avant de forcer plus d’E/S.

Faits intéressants et un peu d’histoire (parce que ça change les décisions)

Ce ne sont pas des anecdotes. Ils expliquent pourquoi ZFS agit comme il le fait — et pourquoi certaines habitudes « classiques » de RAID sont activement nuisibles.

1. ZFS a été créé chez Sun Microsystems au milieu des années 2000, conçu pour mettre fin à la séparation « système de fichiers + gestionnaire de volumes ». C’est pourquoi il parle de pools et de vdevs plutôt que de partitions destinées.
2. Copy-on-write (CoW) signifie que ZFS n’écrase jamais les blocs en place. Excellent pour la consistance ; cela signifie aussi que « lancez fsck » n’est pas une solution. Le modèle de réparation est différent.
3. Chaque bloc est checksummé, y compris les métadonnées. Voilà pourquoi les erreurs de checksum sont importantes : ZFS détecte des mensonges dans la pile de stockage.
4. Le scrub n’est pas une fonctionnalité de performance. C’est un audit d’intégrité. Lancez‑le parce que vous aimez dormir, pas parce que le tableau de bord sera plus joli.
5. « RAIDZ n’est pas RAID » est plus que de la pédanterie. Les contrôleurs RAID masquent souvent l’identité des disques et les détails d’erreur ; ZFS veut une visibilité directe. Les HBAs en mode IT sont populaires pour une raison.
6. L’état de santé du pool est conservateur. ZFS continuera de se plaindre des erreurs même si elles ont été corrigées, jusqu’à ce qu’elles soient effacées. C’est volontaire : le système veut que des humains reconnaissent le risque.
7. Les secteurs 4K ont tout changé. Le choix de ashift (alignement secteur) est essentiellement irréversible par vdev et peut détruire silencieusement les performances s’il est incorrect.
8. Le résilver a évolué au fil du temps. Les améliorations de « resilver séquentiel » dans les versions récentes d’OpenZFS ont rendu les reconstructions moins pénalisantes, mais elles sollicitent toujours fortement les vdevs affectés.
9. Proxmox a rendu ZFS grand public dans les petits clusters. Bon résultat, mais cela signifie aussi que des environnements de production tournent avec des habitudes « ça marchait en labo » pour le stockage.

Règles de triage : ce que vous faites immédiatement (et ce que vous ne faites pas)

À faire immédiatement

• Capturer l’état courant : zpool status, zfs list, logs pertinents. Quand les choses s’aggravent, vous voudrez un avant/après.
• Arrêter les changements non essentiels : reporter les migrations, suspendre les sauvegardes massives, éviter l’explosion de snapshots. Vous voulez moins d’écritures pendant une période instable.
• Vérifier que vous avez une sauvegarde récente restaurable, pas seulement « un job de sauvegarde qui s’est lancé ». Si la redondance est compromise, les sauvegardes deviennent l’adulte responsable dans la pièce.

Évitez ces mouvements tentants

• Ne « nettoyez » pas les erreurs pour faire disparaître l’alerte avant de les comprendre. Effacer est une reconnaissance, pas une réparation.
• Ne lancez pas un scrub pendant une panne dure (timeouts, réinitialisations, pool suspended). Le scrub augmente les lectures ; les périphériques défaillants meurent souvent plus vite sous pression.
• Ne mettez pas hors ligne le mauvais disque. Identifiez par identifiants persistants, pas par « /dev/sdX est probablement… ». Le « probablement » est la façon la plus sûre de provoquer une seconde panne.
• Ne mélangez pas les héroïsmes et l’incertitude. Si vous devinez, passez en import en lecture seule (si applicable) et évacuez les données.

Blague #2 : Si vous choisissez les disques selon l’ordre /dev/sdX, vous faites de l’ingénierie stockage avec une planche Ouija.

Tâches pratiques avec commandes : lire les sorties, prendre des décisions

Ci‑dessous des tâches pratiques à exécuter sur un hôte Proxmox. Chaque tâche inclut : commande, ce que signifie une sortie typique, et quelle décision cela entraîne. Exécutez-les en root ou avec les privilèges appropriés.

Task 1: Confirm the pool health and identify the offender

cr0x@server:~$ zpool status -xv
  pool: rpool
 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'.
   see: message ID: ZFS-8000-2Q
config:

        NAME                         STATE     READ WRITE CKSUM
        rpool                        DEGRADED     0     0     0
          mirror-0                   DEGRADED     0     0     0
            ata-SAMSUNG_SSD_870...   ONLINE       0     0     0
            ata-SAMSUNG_SSD_870...   UNAVAIL      0     0     0  cannot open

errors: No known data errors

Ce que cela signifie : Le pool est dégradé car un membre du miroir est indisponible. Pas encore d’erreurs de données.

Décision : Traitez comme urgent mais contrôlé. Identifiez s’il s’agit d’une défaillance de disque ou d’un problème de chemin. Planifiez le rétablissement de la redondance dès que possible.

Task 2: Check if Proxmox thinks something is wrong at the cluster level

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prodcluster
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 11:02:18 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Ce que cela signifie : Le quorum du cluster est OK. C’est un incident de stockage, pas un drame de split‑brain.

Décision : Concentrez‑vous sur le ZFS/matériel du nœud. Ne changez pas les paramètres du cluster comme « solution ».

Task 3: Map ZFS device names to real hardware paths (stop guessing)

cr0x@server:~$ zpool status -P
  pool: rpool
 state: DEGRADED
config:

        NAME                                                STATE     READ WRITE CKSUM
        rpool                                               DEGRADED     0     0     0
          mirror-0                                          DEGRADED     0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S5...   ONLINE       0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6...   UNAVAIL      0     0     0  cannot open

Ce que cela signifie : ZFS utilise déjà des chemins by-id stables (bien). Si vous voyez /dev/sdX ici, corrigez cela après l’incident.

Décision : Utilisez ces identifiants pour localiser le disque physique dans le châssis, l’emplacement HBA ou la cartographie de baie.

Task 4: Check recent kernel messages for I/O errors, link resets, and timeouts

cr0x@server:~$ journalctl -k -n 80 --no-pager
Dec 26 10:58:41 server kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
Dec 26 10:58:41 server kernel: ata7.00: irq_stat 0x08000000, interface fatal error
Dec 26 10:58:41 server kernel: ata7: SError: { CommWake DevExch }
Dec 26 10:58:42 server kernel: ata7: hard resetting link
Dec 26 10:58:47 server kernel: ata7: link is slow to respond, please be patient (ready=0)
Dec 26 10:58:52 server kernel: ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Dec 26 10:58:52 server kernel: sd 6:0:0:0: [sdf] tag#7 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Dec 26 10:58:52 server kernel: blk_update_request: I/O error, dev sdf, sector 14680064 op 0x0:(READ)

Ce que cela signifie : Erreurs d’interface fatales et réinitialisations. Cela sent le câble/backplane/HBA plutôt que « le disque est mort ». Notez aussi la négociation du lien à 3.0 Gbps ; cela peut indiquer des problèmes de qualité de signal.

Décision : Avant de remplacer le disque, réassurez/réinstallez le câble, déplacez la baie, vérifiez le firmware HBA, et vérifiez la stabilité d’alimentation. Si les erreurs persistent, remplacez le disque.

Task 5: Pull SMART data for SATA/SAS disks and interpret the right fields

cr0x@server:~$ smartctl -a /dev/sdf
SMART Attributes Data Structure revision number: 16
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       37

Ce que cela signifie : Pas de secteurs réalloués/pending, mais des erreurs CRC existent. Les erreurs CRC sont souvent du bruit de câblage/backplane, pas une panne mécanique du plateau.

Décision : Corrigez le chemin (câble/backplane/HBA). Ensuite, effacez les compteurs au niveau ZFS (pas SMART), et observez. Si les CRC continuent d’augmenter, creusez davantage.

Task 6: Pull NVMe health (different tools, different clues)

cr0x@server:~$ nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 44 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 6%
media_errors                        : 0
num_err_log_entries                 : 0

Ce que cela signifie : NVMe semble sain. Si ZFS rapporte des erreurs de checksum sur un miroir NVMe et que SMART est propre, suspectez des problèmes PCIe, firmware ou corruption mémoire plutôt que l’usure NAND.

Décision : Corrélez avec journalctl -k pour les erreurs PCIe AER ; envisagez des mises à jour firmware et des tests mémoire si les checksums persistent.

Task 7: Verify pool events and timelines (ZFS tells you what it noticed)

cr0x@server:~$ zpool events -v | tail -n 25
Dec 26 10:58:52 sysevent.fs.zfs.vdev_fault
  pool: rpool
  vdev: /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6...
  errno: 5
  description: Vdev I/O failure, zio pool=rpool vdev=/dev/disk/by-id/ata-SAMSUNG...
Dec 26 10:59:10 sysevent.fs.zfs.statechange
  pool: rpool
  old-state: ONLINE
  new-state: DEGRADED

Ce que cela signifie : Vous disposez d’un horodatage clair. C’est de l’or pour corréler avec une maintenance, des événements d’alimentation, des mises à jour du noyau ou quelqu’un qui « a juste réasserré un câble ».

Décision : Utilisez la chronologie pour valider ou éliminer des hypothèses. Si cela a commencé juste après un redémarrage ou un changement de firmware, suspectez une configuration/compatibilité.

Task 8: Check for scrub status and whether it’s currently safe to run one

cr0x@server:~$ zpool status
  pool: rpool
 state: DEGRADED
status: One or more devices could not be opened...
scan: scrub repaired 0B in 00:18:44 with 0 errors on Sun Dec 22 03:20:12 2025
config:
  ...

Ce que cela signifie : Le dernier scrub s’est terminé récemment sans erreur. Cela suggère que l’intégrité était correcte jusqu’à ce que le vdev devienne manquant/indisponible.

Décision : Réparez le périphérique manquant et laissez le resilver s’exécuter ; ne lancez pas de scrub avant que la redondance soit restaurée (sauf si vous diagnostiquez des erreurs de checksum et que le pool est stable).

Task 9: Clear only after you’ve fixed the cause (and know what you’re acknowledging)

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

Ce que cela signifie : Les compteurs d’erreurs ZFS ont été effacés et le pool est revenu à l’état healthy.

Décision : Ne le faites qu’après remédiation. Si vous effacez trop tôt, vous perdez le signal et rendez les problèmes récurrents plus difficiles à prouver.

Task 10: Find and validate the physical disk you’re about to touch

cr0x@server:~$ ls -l /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6*
lrwxrwxrwx 1 root root  9 Dec 26 10:40 /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6... -> ../../sdf
cr0x@server:~$ udevadm info --query=all --name=/dev/sdf | egrep 'ID_SERIAL=|ID_PATH=|DEVNAME='
DEVNAME=/dev/sdf
ID_SERIAL=SAMSUNG_SSD_870_EVO_S6...
ID_PATH=pci-0000:3b:00.0-ata-7

Ce que cela signifie : Vous avez un serial stable et un chemin bus. C’est ainsi que vous évitez d’arracher le mauvais disque.

Décision : Associez le serial à l’étiquette du châssis ou à la cartographie HBA. Si vous ne pouvez pas correspondre avec confiance, arrêtez‑vous et construisez la cartographie d’abord.

Task 11: Offline a failing device (when you actually mean it) and replace it

cr0x@server:~$ zpool offline rpool /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6...
cr0x@server:~$ zpool status -P
  pool: rpool
 state: DEGRADED
config:

        NAME                                                STATE     READ WRITE CKSUM
        rpool                                               DEGRADED     0     0     0
          mirror-0                                          DEGRADED     0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S5...   ONLINE       0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6...   OFFLINE      0     0     0

Ce que cela signifie : Vous avez mis hors ligne intentionnellement le périphérique. ZFS arrêtera de l’utiliser, ce qui peut réduire le spam d’erreurs et la latence.

Décision : Remplacez le disque, puis attachez le nouveau membre. Ne mettez pas hors ligne des disques « pour voir ce qui se passe » en RAIDZ — les miroirs sont tolérants ; RAIDZ l’est moins.

Task 12: Attach/replace and watch resilver progress

cr0x@server:~$ zpool replace rpool /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S6... /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S7...
cr0x@server:~$ zpool status
  pool: rpool
 state: DEGRADED
scan: resilver in progress since Fri Dec 26 11:15:04 2025
        3.12G scanned at 410M/s, 1.02G issued at 134M/s, 92.3G total
        1.02G resilvered, 1.10% done, 0:11:20 to go
config:

        NAME                                                STATE     READ WRITE CKSUM
        rpool                                               DEGRADED     0     0     0
          mirror-0                                          DEGRADED     0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S5...   ONLINE       0     0     0
            /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_S7...   ONLINE       0     0     0  (resilvering)

errors: No known data errors

Ce que cela signifie : Le resilver est en cours et les estimations semblent cohérentes. « Scanned » vs « issued » indique à quelle vitesse ZFS peut lire vs écrire/vérifier.

Décision : Maintenez la charge modérée. Si vous voyez des timeouts, des débits en chute libre, ou des réinitialisations répétées dans les logs, mettez en pause et résolvez la stabilité du chemin matériel.

Task 13: If resilver is painfully slow, check I/O pressure and latency

cr0x@server:~$ iostat -x 2 5
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.33    0.00    5.21   41.08    0.00   41.38

Device            r/s     w/s   r_await   w_await  aqu-sz  %util
sde              58.2   120.4     8.12    42.77   12.40   98.7
sdf               2.1    90.3     1.90   210.55   19.10   99.9

Ce que cela signifie : Un appareil est saturé avec une latence d’écriture énorme. Pendant le resilver, un disque faible ou un chemin faible ralentit tout.

Décision : Réduisez la charge concurrente (sauvegardes, réplication), vérifiez les réglages du cache d’écriture, confirmez que le disque de remplacement n’est pas un piège SMR pour pools HDD, et vérifiez qu’il n’y a pas de goulet d’étranglement contrôleur.

Task 14: Check whether you’re seeing memory-related corruption signals

cr0x@server:~$ dmesg | egrep -i 'edac|mce|ecc|machine check' | tail -n 20
[  912.220112] EDAC MC0: 1 CE memory scrubbing error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0
[  912.220119] mce: [Hardware Error]: Corrected error, no action required.

Ce que cela signifie : Les erreurs ECC corrigées restent un signal. Si des erreurs de checksum apparaissent sur plusieurs disques ou vdevs, la RAM/CPU/PCIe devient un suspect crédible.

Décision : Si les motifs d’erreurs sont « partout », ne jouez pas au whack‑a‑mole avec les disques. Stabilisez la plateforme : tests mémoire, réassort des DIMM, mises à jour firmware, vérification de l’alimentation.

Task 15: Find “permanent errors” and decide whether you need file-level recovery

cr0x@server:~$ zpool status -v
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible.
  see: message ID: ZFS-8000-8A
config:
        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        tank/vmdata:vm-104-disk-0

Ce que cela signifie : Le pool est ONLINE, mais un fichier est corrompu et ne peut pas être réparé par la redondance. En termes Proxmox, cela peut être un disque de VM.

Décision : Restaurer depuis la sauvegarde ou la réplication. Pour un disque de VM, envisagez de restaurer l’image disque de la VM, ou de migrer le service vers un snapshot connu‑bon si vous en disposez.

Task 16: Validate ashift and recordsize choices (performance problems that look like “health”)

cr0x@server:~$ zdb -C rpool | egrep 'ashift|vdev_tree' -n | head -n 20
55:    vdev_tree:
61:        ashift: 12
cr0x@server:~$ zfs get recordsize,compression,atime tank/vmdata
NAME        PROPERTY     VALUE  SOURCE
tank/vmdata recordsize   128K   local
tank/vmdata compression  zstd   local
tank/vmdata atime        off    local

Ce que cela signifie : ashift: 12 (4K) est généralement raisonnable. Les paramètres de dataset montrent un dataset de stockage VM avec compression et atime désactivé.

Décision : Si ashift est 9 sur des disques 4K modernes, attendez‑vous à des douleurs. Vous ne pouvez pas « corriger » ashift in situ ; il faut reconstruire les vdevs. Le tuning de recordsize dépend de la charge ; ne le changez pas pendant un incident sauf si vous savez exactement pourquoi.

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

Mini-récit 1 : La panne causée par une mauvaise hypothèse

Ils avaient un cluster Proxmox propre : trois nœuds, chacun avec des SSD de boot en miroir et un RAIDZ2 séparé pour le stockage des VM. L’alerte indiquait « pool is not healthy » sur le pool VM d’un nœud. L’ingénieur d’astreinte a fait ce que beaucoup d’entre nous font à 2h du matin : il a fouillé sa mémoire pour le dernier incident similaire.

La dernière fois, c’était un SSD mort. Il a donc supposé que c’était encore un disque mort. Il a vu un périphérique en UNAVAIL et l’a immédiatement mis hors ligne. Ensuite il est allé au rack et a remplacé le disque dans la baie qu’il croyait correspondre à /dev/sdf. Le pool est resté dégradé. Les erreurs ont continué. Puis un second périphérique a commencé à flapper. Le pool n’était plus seulement dégradé, il devenait instable.

La cause racine était banale : le HBA avait été déplacé dans un autre slot PCIe lors d’une maintenance antérieure, et la cartographie baie→périphérique documentée n’était plus correcte. Le « disque mort » était sain ; c’était la mauvaise baie. Ils ont retiré un disque sain du RAIDZ2, transformant « un périphérique manquant » en « maintenant on est vraiment en danger ».

Ils ont récupéré, mais uniquement parce que le pool était RAIDZ2 et disposait d’une marge d’erreur supplémentaire par rapport à ce que leur processus méritait. Le postmortem ne portait pas sur ZFS. Il portait sur la discipline d’identification : utilisez toujours /dev/disk/by-id, validez toujours les numéros de série, et n’assumez jamais que les noms de périphériques OS sont stables.

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

Une autre société voulait des VM plus rapides. Quelqu’un a lu que désactiver les écritures sync pouvait augmenter le débit, et ils ont mis sync=disabled sur un dataset utilisé pour une VM base de données. Les benchmarks étaient flatteurs. Les graphes de latence devenaient revendicatifs.

Des mois plus tard, le stockage a commencé à afficher des erreurs de checksum. Un scrub a trouvé quelques réparations, puis plus tard quelques erreurs permanentes sur un disque de VM. La réaction immédiate a été d’accuser « des disques défectueux », et ils ont remplacé deux disques sur deux nœuds. Les erreurs ont continué d’apparaître, et maintenant tout le monde était nerveux parce que les remplacements n’avaient pas « résolu » le problème.

La vraie histoire : ils avaient un bug de firmware du contrôleur qui accusait parfois les écritures avant qu’elles ne soient durables. Avec les sémantiques synchrones affaiblies, la tolérance du système aux accusés d’écriture douteux a disparu. Le mode de défaillance est devenu « l’application croit que les données sont engagées, une coupure de courant survient, et maintenant ZFS voit une réalité incohérente ». ZFS a fait son travail en se plaignant, mais il ne pouvait pas annuler une transaction de base de données que la VM croyait déjà engagée.

Ils ont remis sync=standard, ajouté un vrai SLOG sur un matériel avec protection contre la perte de puissance, et mis à jour le firmware du contrôleur. Les performances ont un peu chuté. Les incidents ont beaucoup diminué. La leçon n’était pas « ne jamais optimiser ». C’était « n’optimisez qu’après avoir compris quel contrat de sécurité vous réécrivez ».

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

Celui‑ci est moins glamour et plus instructif. Une organisation de taille moyenne disposait d’un environnement Proxmox avec des miroirs ZFS pour le stockage des VM. Rien de sophistiqué. Mais ils avaient deux habitudes ennuyeuses : des scrubs mensuels avec alerting, et des tests de restauration trimestriels pour un petit ensemble de VM critiques.

Un lundi, « pool is not healthy » est apparu avec quelques erreurs de checksum sur un seul disque. SMART était propre. Les logs noyau montraient des réinitialisations de lien intermittentes. Au lieu de remplacer immédiatement le disque, ils ont planifié une fenêtre de maintenance, déplacé les VM hors du nœud, et remplacé un câble SAS suspect et un expander du backplane qui avait un port réputé instable.

Ils n’ont effacé les compteurs d’erreur ZFS qu’après la correction matérielle. Les erreurs ne sont pas revenues. Le pool est resté stable. Pas de remplacement d’urgence, pas d’échanges de disque au hasard, pas de scrubs paniqués.

Et voici ce qui compte : parce qu’ils avaient déjà des résultats de scrub et des exercices de restauration, la direction n’a pas contesté la fenêtre de maintenance. Ils disposaient d’un historique qui traduisait un risque technique en confiance opérationnelle. La pratique ennuyeuse n’était pas juste « bonne hygiène ». C’était un levier organisationnel.

Erreurs fréquentes : symptôme → cause racine → correction

1) Symptom: “CKSUM errors increasing” but SMART looks clean

Cause racine : Souvent un câble défectueux, un backplane marginal, un port HBA capricieux, ou des problèmes PCIe/AER. Les checksums détectent les mauvaises données n’importe où dans la chaîne.

Correction : Corrélez avec journalctl -k pour les réinitialisations ; réasserez/remplacez les câbles, déplacez le disque vers une autre baie/port, mettez à jour le firmware HBA. Ensuite lancez un scrub une fois la stabilité rétablie pour valider l’intégrité.

2) Symptom: Pool DEGRADED after reboot, device UNAVAIL

Cause racine : Énumération des périphériques modifiée, liens by-id manquants dans l’initramfs, ou timing BIOS/HBA provoquant une disponibilité tardive des périphériques.

Correction : Assurez‑vous que les pools utilisent des chemins /dev/disk/by-id ; vérifiez les mises à jour d’initramfs ; vérifiez les réglages HBA/BIOS et l’ordre de démarrage ; évitez de mélanger un boot USB avec la complexité ZFS en production.

3) Symptom: Scrub “repaired bytes” repeatedly every scrub

Cause racine : Source de corruption persistante : RAM instable, problème de contrôleur, ou disque renvoyant des lectures incohérentes.

Correction : Ne célébrez pas « il a réparé ». C’est un avertissement. Lancez des diagnostics mémoire, vérifiez les logs ECC, validez le firmware, et isolez en déplaçant des membres de vdev sur d’autres ports.

4) Symptom: Resilver is extremely slow and the host feels frozen

Cause racine : Le resilver concurrence l’I/O des VM ; disque de remplacement plus lent que les autres ; disques SMR dans un workload d’écritures aléatoires ; goulet d’étranglement des queues du contrôleur.

Correction : Limitez les charges (pause des sauvegardes, migration des VM chaudes), confirmez la classe du disque (évitez le SMR dans les pools VM), envisagez de programmer le resilver en période de faible usage.

5) Symptom: Pool SUSPENDED

Cause racine : ZFS a abandonné les E/S à cause d’échecs répétés. Souvent un contrôleur/backplane qui lâche fortement, ou plusieurs disques disparus.

Correction : Arrêtez les écritures. Capturez les logs. Vérifiez la couche physique et l’alimentation. Envisagez une import en lecture seule et une évacuation des données. Remplacez les composants défaillants avant de tenter une importation normale.

6) Symptom: Proxmox UI warns, but zpool status -x says healthy

Cause racine : Statut mis en cache, latence du monitoring, ou pool récemment rétabli mais alerte non effacée.

Correction : Re‑vérifiez avec zpool status -xv, effacez les alertes résolues dans votre monitoring, et vérifiez qu’il n’y a pas de compteurs d’erreurs non nuls.

7) Symptom: “Permanent errors in vm-XXX-disk-Y”

Cause racine : La redondance n’a pas pu reconstruire un bloc. Peut être dû à des défaillances multiples, une corruption silencieuse, ou des écritures effectuées pendant une période défaillante.

Correction : Restaurer depuis sauvegarde/réplication. Si vous avez des snapshots, essayez de cloner et d’exécuter des vérifications de système de fichiers dans le guest. N’assumez pas que « ZFS corrigera » quand il dit explicitement que ce n’est pas possible.

8) Symptom: Frequent device OFFLINE/ONLINE flapping

Cause racine : Connexion lâche, alimentation marginale, surchauffe, problèmes d’expander, ou gestion agressive de l’économie d’énergie du lien.

Correction : Réparez la couche physique, améliorez le refroidissement, vérifiez les rails PSU, désactivez les fonctions d’économie d’énergie problématiques pour les chemins de stockage concernés, et surveillez la réapparition des erreurs.

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

Checklist A: “I just saw the alert” (first 15 minutes)

1. Exécutez zpool status -xv. Enregistrez le résultat (collez‑le dans le ticket/notes).
2. Exécutez zpool status -P pour confirmer les chemins by-id et obtenir l’identifiant exact du périphérique.
3. Vérifiez journalctl -k autour de l’heure de la première erreur ; cherchez réinitialisations/timeouts/AER.
4. Récupérez SMART/NVMe health pour le périphérique impliqué.
5. Décidez : défaillance disque vs défaillance de chemin vs suspicion systémique (RAM/contrôleur).
6. Réduisez la churn : mettez en pause les jobs de sauvegarde/réplication lourds ; évitez les grosses migrations.
7. Vérifiez la capacité de restauration des sauvegardes pour les VM les plus critiques sur ce pool.

Checklist B: Controlled disk replacement (mirror or RAIDZ, stable system)

1. Identifiez le disque par /dev/disk/by-id et le numéro de série.
2. Si il est défaillant mais toujours présent, zpool offlineez‑le intentionnellement.
3. Remplacez le matériel (disque, câble, baie, ou port HBA selon les preuves).
4. Utilisez zpool replace avec des chemins by-id.
5. Surveillez zpool status jusqu’à la fin du resilver.
6. Après la complétion, envisagez un scrub (si c’était lié aux checksum) pendant une fenêtre calme.
7. Ensuite seulement, zpool clear si nécessaire, et continuez la surveillance des réapparitions.

Checklist C: When redundancy is compromised (you’re on the edge)

1. Arrêtez les écritures non essentielles. Si possible, éteignez proprement les VM non critiques.
2. Capturez les preuves : zpool status -xv, zpool events -v, logs noyau.
3. Priorisez l’évacuation : sauvegardes, réplication, ou export des disques VM vers une autre cible de stockage.
4. Si l’import est instable, envisagez une import en lecture seule là où c’est applicable et copiez ce que vous pouvez.
5. Remplacez d’abord le composant manifestement défaillant (souvent chemin/contrôleur/alimentation).
6. Après retour à la stabilité, reconstruisez la redondance ; puis lancez un scrub pour valider.

Checklist D: After the incident (prevent the sequel)

1. Planifiez des scrubs réguliers avec alerting (mensuel est courant ; ajustez selon capacité et charge).
2. Surveillez SMART et les taux de réinitialisation de lien ; alertez sur les tendances, pas uniquement sur les seuils.
3. Documentez la cartographie baie→numéro de série et maintenez‑la après les changements hardware.
4. Standardisez les HBAs et versions firmware entre les nœuds.
5. Testez les restaurations trimestrielles pour des VM représentatives.

FAQ

1) Does “pool is not healthy” mean I’m already losing data?

Pas nécessairement. DEGRADED signifie souvent que la redondance est réduite mais que les données sont encore intactes. « Permanent errors » est l’expression qui doit vous amener à supposer qu’une partie des données est corrompue.

2) Should I run a scrub immediately?

Seulement si le pool est stable et que vous diagnostiquez l’intégrité. Si des périphériques tombent, des timeouts surviennent, ou le pool est suspended, un scrub peut pousser du matériel défaillant à la rupture.

3) What’s worse: READ errors or CKSUM errors?

Les READ indiquent que le périphérique ne peut pas lire. Les CKSUM indiquent que le périphérique (ou le chemin) a renvoyé des données incorrectes. Les erreurs CKSUM pointent souvent vers des câbles/contrôleurs/RAM et peuvent être plus insidieuses.

4) Can I just clear the errors so Proxmox stops complaining?

Vous pouvez, mais c’est une très mauvaise idée avant d’avoir corrigé la cause. Effacer supprime la piste d’audit. Effacez après remédiation pour pouvoir détecter proprement une récurrence.

5) How do I know I’m replacing the correct disk?

Utilisez zpool status -P et /dev/disk/by-id. Confirmez avec udevadm info et le numéro de série du disque. Si vous ne pouvez pas faire correspondre le serial à la baie, faites une pause et construisez la cartographie.

6) Why did the pool go DEGRADED after a reboot even though disks are “fine”?

Causes courantes : changements de pathing, initialisation lente des périphériques, ou utilisation de nœuds périphériques instables. Corrigez en assurant des IDs persistants et en vérifiant le comportement d’initramfs au démarrage.

7) Resilver is taking forever—can I speed it up?

Le moyen le plus rapide est de supprimer la concurrence d’I/O : pausez les sauvegardes, évitez les migrations, réduisez la charge d’écriture des VM. Si le disque de remplacement est plus lent ou le chemin instable, aucune option de tuning ne remplacera la correction hardware.

8) Is ECC memory required for ZFS on Proxmox?

Requise ? Non. Fortement recommandée en production ? Oui — surtout pour des VM importantes. Sans ECC, vous pariez que les erreurs mémoire n’interviendront pas pendant de fortes E/S ou des scrubs.

9) What if zpool status shows “errors: No known data errors” but the pool isn’t healthy?

Cela signifie généralement que la redondance est réduite ou qu’un périphérique est manquant, mais que ZFS n’a pas identifié de blocs irrécupérables. Il faut quand même restaurer la redondance rapidement.

10) Should I use hardware RAID with ZFS in Proxmox?

En général : évitez‑le. ZFS veut un contrôle et une visibilité directe sur les périphériques. Utilisez un HBA (mode IT) sauf si vous avez une exception très spécifique et bien comprise.

Prochaines étapes pour éviter la répétition des incidents

Quand Proxmox indique qu’un pool ZFS n’est pas sain, traitez‑le comme un détecteur de fumée, pas comme une décoration de tableau de bord. Le meilleur résultat est ennuyeux : identifiez le composant défaillant, restaurez la redondance, validez l’intégrité, et resserrez vos pratiques opérationnelles pour que la prochaine alerte soit actionnable plutôt qu’énigmatique.

Actions concrètes que vous pouvez faire cette semaine :

• Planifier un calendrier de scrub récurrent et alerter sur les erreurs/ralentissements de scrub.
• Mettre en place une discipline d’identité disque : /dev/disk/by-id partout, et maintenir une cartographie baie→numéro de série.
• Baseliner la santé SMART/NVMe et les motifs d’erreurs noyau pour repérer rapidement le « nouveau bizarre ».
• Effectuer un test de restauration d’une VM critique. Pas parce que vous attendez une panne — parce que vous attendez la réalité.

Si vous ne faites rien d’autre : n’effacez pas l’alerte tant que vous ne pouvez pas l’expliquer. ZFS vous donne une chance de résoudre le problème alors que vous avez encore des options. Prenez l’indice.