Proxmox ZFS DEGRADED : Remplacer un disque sans dégâts collatéraux

Que signifie vraiment “DEGRADED” dans Proxmox + ZFS

Dans ZFS, DEGRADED signifie que la pool reste utilisable, mais qu’au moins un vdev (périphérique virtuel) a perdu de la redondance
ou qu’un composant est indisponible ou se comporte mal. L’important n’est pas le mot, mais les implications :

• Vous êtes à une panne de la perte de données si vous êtes sur des mirrors avec une face absente, ou sur RAIDZ sans
  tolérance de parité restante.
• Les performances sont souvent dégradées parce que ZFS peut reconstruire des lectures, retenter des E/S ou contourner un périphérique instable.
• Les scrubs et les resilvers deviennent des événements à risque : ils sollicitent les disques restants, ce que vous ne voulez pas quand ils vieillissent.

Proxmox est surtout un messager ici. Il exécute ZFS comme couche de stockage (souvent pour rpool et parfois pour les pools de VM),
et affiche zpool status dans l’interface. Le véritable plan d’action se situe dans le shell.

« Remplacer un disque » sonne comme une tâche matérielle. Dans ZFS, c’est une opération de migration de données avec une dépendance matérielle. Traitez-la ainsi.

Guide de diagnostic rapide (vérifier premier/deuxième/troisième)

Quand une pool devient dégradée, votre rôle est de répondre rapidement à trois questions : Quel disque ? Est-il réellement défaillant ou juste manquant ?
La pool est-elle suffisamment stable pour resilver en sécurité ?

Premier : confirmer l’état de la pool et le membre vdev exact qui est malade

Ne devinez pas à partir de l’UI Proxmox. Obtenez le statut faisant autorité depuis ZFS.

Deuxième : déterminer si c’est un “disque mort” ou un “problème de chemin”

Un disque peut sembler en panne parce qu’un reset de contrôleur, un câble SATA défectueux, un slot de backplane instable ou un renommage de périphérique l’a fait disparaître.
La correction diffère — et remplacer du matériel à l’aveugle peut empirer la situation.

Troisième : évaluer le risque avant de stresser la pool

Si les disques restants montrent des secteurs réalloués, des erreurs de lecture ou des timeouts, vous voudrez peut-être ralentir les E/S,
planifier une fenêtre ou effectuer un snapshot/une réplication de sauvegarde avant le resilver.

La manière la plus rapide de trouver le goulot : ZFS status → kernel logs → SMART. Si ces trois éléments concordent, agissez.
S’ils divergent, marquez une pause et comprenez pourquoi.

Faits intéressants & contexte historique (pourquoi ZFS réagit ainsi)

• ZFS est né chez Sun Microsystems au milieu des années 2000 avec la vérification de bout en bout (checksumming) comme fonctionnalité primaire, pas un ajout.
• Le “copy-on-write” explique pourquoi ZFS déteste les demi-vérités : il écrit de nouveaux blocs puis met à jour des pointeurs, ce qui rend la corruption silencieuse plus facile à détecter.
• ZFS ne “rebuild” pas ; il “resilver” : il ne reconstruit que les blocs réellement utilisés — pas l’intégralité du périphérique brut.
• RAIDZ a été conçu pour corriger le write hole de RAID‑5/6 en intégrant la gestion de la parité au modèle transactionnel du filesystem.
• Les noms de périphériques comme /dev/sda ne sont pas stables ; l’utilisation de noms persistants via /dev/disk/by-id est devenue la bonne pratique car l’énumération Linux change.
• Les scrubs existent parce que les checksums doivent être exercés : ZFS détecte la corruption, mais un scrub force la lecture et la vérification proactive des données.
• Les disques Advanced Format (secteur 4K) ont créé une ère de douleur ; ashift est la façon dont ZFS aligne les allocations sur la taille physique des secteurs.
• SMART n’est pas un verdict, c’est un bulletin météo : beaucoup de disques meurent en semblant “healthy”, tandis que d’autres traînent des mois en “failing”.

Une idée paraphrasée restant douloureusement vraie vient de Gene Kranz (directeur de vol de la NASA) : soyez dur et compétent.
En termes de stockage : n’improvisez pas, et ne touchez pas à deux choses en même temps.

Avant de toucher le matériel : garde-fous pour éviter les dégâts collatéraux

Utilisez des identités de disque stables (basées sur le serial), pas ce que Linux a nommé aujourd’hui

Si vous travaillez les disques uniquement par /dev/sdX, vous jouez à la roulette russe avec une roue chargée. Les upgrades Proxmox,
les mises à jour du kernel, les resets de contrôleur ou simplement un reboot peuvent remixer l’énumération. ZFS peut aussi stocker des chemins sous plusieurs formes.
Vous devez ancrer vos décisions à des faits immuables : WWN, serial et emplacement en baie.

Décidez votre rayon d’impact

Si la pool héberge des disques de VM (zvols), un resilver est très consommateur d’I/O. Si vous pouvez évacuer les VM critiques,
faites-le. Si vous ne le pouvez pas, procédez quand même — mais de façon intentionnelle : limitez la charge, évitez la maintenance simultanée
et surveillez la latence comme un aigle.

Ne “réparez” pas deux problèmes en même temps

Remplacer un disque est déjà une urgence contrôlée. Ne le couplez pas avec une mise à jour du kernel, un firmware HBA,
un changement de feature flag ZFS ou un « rangement rapide de câbles ». Vous voulez de la causalité. Vous voulez la réversibilité.

Blague n°1 : Les baies de stockage n’ont pas d’humeur. Elles ont des conséquences, et elles se souviennent toujours de ce que vous avez fait.

Tâches pratiques avec commandes, sorties et décisions (12+)

Tout ce qui suit est rédigé pour un nœud Proxmox typique utilisant ZFS sous Linux. Les commandes supposent les privilèges root ou sudo.
Remplacez les noms de pool/périphérique par votre réalité. Si votre pool est rpool, parfait. Si c’est tank, utilisez-le.

Task 1: Confirm pool health and identify the failing member

cr0x@server:~$ sudo zpool status -v
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 00:14:12 with 0 errors on Thu Dec 19 02:10:03 2025
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        DEGRADED     0     0     0
          mirror-0                                   DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321   FAULTED     12     0     0  too many errors

errors: No known data errors

Ce que cela signifie : Vous avez un mirror avec une face faulted. Les lectures sont servies depuis le disque restant.
La pool tourne encore, mais la redondance est perdue pour ce vdev.
Décision : Remplacez ...654321. Ne détachez pas le disque sain. Ne « clear »z pas les erreurs en espérant.

Task 2: Map ZFS device IDs to physical disks (WWN/serial)

cr0x@server:~$ ls -l /dev/disk/by-id | egrep 'S2Y3NX0K123456|S2Y3NX0K654321'
lrwxrwxrwx 1 root root  9 Dec 26 09:10 ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456 -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 09:10 ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321 -> ../../sdb

Ce que cela signifie : Pour l’instant le disque sain est /dev/sda et le disque défectueux est /dev/sdb.
Cette correspondance peut changer après un reboot.
Décision : Travaillez en termes de /dev/disk/by-id/ata-..., et n’utilisez /dev/sdb que pour des vérifications SMART immédiates.

Task 3: Check kernel logs for timeouts/resets (distinguish disk vs path)

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'sdb|ata|I/O error|timeout|reset' | tail -n 25
Dec 26 08:41:12 server kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 26 08:41:12 server kernel: ata2.00: failed command: READ DMA EXT
Dec 26 08:41:12 server kernel: blk_update_request: I/O error, dev sdb, sector 118782976 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 26 08:41:13 server kernel: ata2: hard resetting link
Dec 26 08:41:18 server kernel: ata2: link is slow to respond, please be patient (ready=0)
Dec 26 08:41:23 server kernel: ata2.00: configured for UDMA/133

Ce que cela signifie : Cela ressemble à de véritables erreurs d’E/S et à des resets de lien. Peut être le disque, peut être le câble/backplane.
Décision : Si c’est une baie hot-swap, reseatez le disque une fois (avec précaution) avant de remplacer. Si le problème persiste, remplacez le disque et envisagez d’échanger la baie/le câble plus tard.

Task 4: Get SMART health summary (fast)

cr0x@server:~$ sudo smartctl -H /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-5-pve] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!

Ce que cela signifie : Le disque admet qu’il est mort.
Décision : Remplacez le disque. Plus de diagnostics inutiles.

Task 5: Pull the SMART attributes that matter (timeouts vs wear vs media)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i 'Serial Number|Reallocated|Pending|Offline_Uncorrectable|CRC|Power_On_Hours|Media_Wearout|Percentage_Used' 
Serial Number:                       S2Y3NX0K654321
Power_On_Hours:                      43120
Reallocated_Sector_Ct:               48
Current_Pending_Sector:              9
Offline_Uncorrectable:               9
UDMA_CRC_Error_Count:                0

Ce que cela signifie : Des secteurs en attente et des erreurs non corrigeables sont des signes classiques de défaillance média. Le compteur CRC est à 0, donc le problème est moins probablement lié au câble.
Décision : Remplacez le disque. Si les CRC étaient élevés, vous suspecteriez le câblage/backplane et remplaceriez quand même — mais en faisant plus attention.

Task 6: Verify the pool’s topology (mirror vs RAIDZ) before replacement commands

cr0x@server:~$ sudo zpool get -H -o value ashift rpool
12

Ce que cela signifie : ashift=12 (secteurs 4K). C’est souhaitable dans les systèmes modernes.
Décision : Assurez-vous que le disque de remplacement n’est pas plus petit et qu’il est adapté pour un alignement 4K. Vous ne pouvez pas changer ashift d’un membre vdev en place.

Task 7: Check that the replacement disk is visible and not in use

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINT
NAME    SIZE MODEL             SERIAL           TYPE MOUNTPOINT
sda   476.9G SAMSUNG MZ7LN512  S2Y3NX0K123456   disk 
├─sda1 1007K                    0               part 
├─sda2    1G                    0               part 
└─sda3 475.9G                    0               part 
sdb   476.9G SAMSUNG MZ7LN512  S2Y3NX0K654321   disk 
├─sdb1 1007K                    0               part 
├─sdb2    1G                    0               part 
└─sdb3 475.9G                    0               part 
sdc   476.9G SAMSUNG MZ7LN512  S2Y3NX0K777777   disk 

Ce que cela signifie : Le nouveau disque est sdc et apparaît vierge (aucune partition listée). Bien.
Décision : Utilisez /dev/disk/by-id pour sdc aussi. Confirmez que le serial correspond à l’étiquette du boîtier/baie.

Task 8: Confirm persistent ID for the new disk

cr0x@server:~$ ls -l /dev/disk/by-id | grep S2Y3NX0K777777
lrwxrwxrwx 1 root root  9 Dec 26 09:16 ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777 -> ../../sdc

Ce que cela signifie : Vous avez un identifiant stable pour le disque de remplacement.
Décision : Procédez avec zpool replace en utilisant les chemins by-id.

Task 9: Replace the member correctly (let ZFS do the right thing)

cr0x@server:~$ sudo zpool replace rpool \
  /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321 \
  /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777

Ce que cela signifie : ZFS va attacher le nouveau disque et démarrer le resilver sur celui-ci.
Décision : Ne redémarrez pas. Ne retirez pas le disque restant sain. Surveillez la progression du resilver.

Task 10: Watch resilver progress and verify it’s actually moving

cr0x@server:~$ watch -n 5 sudo zpool status rpool
  pool: rpool
 state: DEGRADED
status: One or more devices is being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Fri Dec 26 09:18:41 2025
        112G scanned at 1.21G/s, 38.2G issued at 423M/s, 475G total
        38.2G resilvered, 8.04% done, 00:17:42 to go
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        DEGRADED     0     0     0
          mirror-0                                   DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777   ONLINE       0     0     0  (resilvering)

Ce que cela signifie : Le resilver est actif, il affiche le débit, l’ETA et le scanné vs émis. C’est bon signe.
Décision : Si “issued” reste bloqué à 0 pendant des minutes alors que “scanned” augmente lentement, vous pourriez être engorgé ou bloqué par des erreurs. Vérifiez les logs et SMART du disque survivant.

Task 11: Check load/latency impact on the node (avoid accidental outage)

cr0x@server:~$ sudo iostat -x 2 5
Linux 6.8.12-5-pve (server) 	12/26/2025 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.12    0.00    3.44   24.66    0.00   63.78

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
sda              98.0   91200.0     0.0   0.00    3.10   930.6     21.0    980.0    8.60    46.7     0.41  38.0
sdc              44.0   40120.0     0.0   0.00    4.90   912.7     62.0   15200.0    2.40   245.2     0.44  29.5

Ce que cela signifie : Le %iowait est élevé. C’est normal pendant un resilver. %util non saturé suggère qu’il reste de la marge.
Décision : Si l’iowait écœure la latence des VM, bridez la charge ou planifiez une fenêtre calme. Évitez de lancer des sauvegardes ou des migrations lourdes pendant le resilver.

Task 12: Confirm pool returns to ONLINE and the old device is gone

cr0x@server:~$ sudo zpool status -v rpool
  pool: rpool
 state: ONLINE
  scan: resilvered 475G in 00:22:19 with 0 errors on Fri Dec 26 09:41:00 2025
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        ONLINE       0     0     0
          mirror-0                                   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777   ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Vous êtes revenu à la redondance. Aucune erreur. C’est l’état objectif.
Décision : Faites maintenant le nettoyage et la vérification : planification de scrub, alerting, étiquetage et notes post-mortem.

Task 13: If the disk is “UNAVAIL” not “FAULTED,” check if it’s just missing

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

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        DEGRADED     0     0     0
          mirror-0                                   DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321   UNAVAIL      0     0     0  cannot open

Ce que cela signifie : ZFS ne peut pas ouvrir le périphérique ; cela peut être un disque mort, ou un problème de chemin.
Décision : Vérifiez si le périphérique existe dans /dev/disk/by-id. S’il a disparu, cherchez des problèmes de contrôleur/backplane avant de le déclarer « failed ».

Task 14: Validate the missing device path exists (or not)

cr0x@server:~$ test -e /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321; echo $?
1

Ce que cela signifie : Le code de sortie 1 signifie que le chemin n’existe pas. L’OS ne le voit pas.
Décision : Vérifiez le siège physique, le slot de backplane, les logs HBA. S’il revient, vous pourrez peut-être faire un zpool online au lieu d’un remplacement.

Task 15: If a disk came back, try onlining it (only if you trust it)

cr0x@server:~$ sudo zpool online rpool /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321

Ce que cela signifie : ZFS va tenter de ramener le périphérique en ligne. S’il s’agissait d’un incident transitoire, la pool peut revenir à ONLINE sans remplacement.
Décision : Si SMART reste mauvais ou si les logs montrent des resets répétés, ne vous attachez pas. Remplacez-le de toute façon.

Task 16: Clear old error counts only after fixing the underlying problem

cr0x@server:~$ sudo zpool clear rpool

Ce que cela signifie : Cela efface les compteurs d’erreurs et certains états de fault.
Décision : Utilisez-le pour confirmer que la correction a tenu (les erreurs restent à 0). Ne l’utilisez pas pour “verdir” une pool sans avoir remplacé le composant.

Blague n°2 : Si vous « clear » les erreurs de la pool sans rien réparer, félicitations — vous venez de faire taire l’alarme incendie pendant que le toast continue de brûler.

Flux de remplacement : mirror vs RAIDZ, hot-swap vs cold-swap

Mirror vdevs : le cas simple (facile à foirer quand même)

Les mirrors sont opérationnellement amicaux. Remplacez un disque, resilver, c’est fini. Le mode de défaillance est humain :
quelqu’un arrache le mauvais disque, remplace par un disque un poil plus petit, utilise des noms de périphériques instables,
ou détache le mauvais membre.

Approche recommandée :

• Identifiez le disque défaillant par serial et baie, pas par sdb.
• Utilisez zpool replace avec des chemins /dev/disk/by-id.
• Surveillez le resilver et les I/O système. Le resilver n’est pas un murmure en arrière-plan ; c’est un chariot élévateur.
• Vérifiez que zpool status revient à ONLINE, puis lancez un scrub pendant une fenêtre de maintenance si possible.

RAIDZ vdevs : le remplacement est simple ; les conséquences pas toujours

Avec RAIDZ, la pool peut rester en ligne avec un ou plusieurs disques manquants selon le niveau de parité (RAIDZ1/2/3).
Mais en dégradation, chaque lecture de données qui touchait le disque manquant peut nécessiter une reconstruction, ce qui sollicite les disques restants.
Le resilver ajoute encore des I/O. C’est ainsi qu’un « disque tombé » peut se transformer en « pourquoi trois disques font-ils des timeouts ».

La méthode est la même : zpool replace du membre. La posture opérationnelle change :

• N’exécutez pas un scrub et un resilver en même temps à moins d’aimer les longues nuits.
• Envisagez de réduire la charge pendant le resilver.
• Si un autre disque lance des erreurs, marquez une pause et décidez s’il faut sauvegarder/répliquer avant de continuer.

Baies hot-swap : faites confiance, mais vérifiez

Hot-swap n’est pas « brancher et prier ». C’est « hot-swap si votre backplane, HBA et OS sont d’accord ». Sur Proxmox, vous pouvez typiquement remplacer un disque à chaud, mais vous devez :

• Confirmer la LED de baie correcte (si disponible) ou utiliser un processus de mapping (serial ↔ baie).
• Insérer le nouveau disque et vérifier qu’il apparaît dans /dev/disk/by-id.
• Puis lancer zpool replace. Pas avant.

Cold swap (arrêt) : parfois le choix ennuyeux est le bon

Si vous êtes sur du matériel douteux (contrôleurs SATA grand public, backplanes instables, BIOS ancien ou historique de resets de lien),
un remplacement à froid peut réduire le risque. C’est aussi plus propre opérationnellement si la pool est déjà instable.
Vous refaites quand même les vérifications d’identités après le boot, car l’énumération peut changer.

Listes de contrôle / plan étape par étape (prêt production)

Checklist A : Plan de réponse “j’ai vu DEGRADED”

1. Capturer l’état actuel : zpool status -v et sauvegarder la sortie dans votre ticket/notes.
2. Vérifier si les erreurs augmentent : relancer zpool status après 2–5 minutes. Les compteurs READ/WRITE/CKSUM augmentent-ils ?
3. Vérifier les kernel logs pour resets/timeouts : journalctl -k -b.
4. SMART sur le disque suspect et sur les membres survivants du même vdev.
5. Décider si vous pouvez opérer en live ou si vous avez besoin d’une fenêtre de maintenance.

Checklist B : Étapes de remplacement sûres (membre mirror ou RAIDZ)

1. Identifier le membre défaillant par le nom affiché par zpool status (préférez by-id).
2. Le mapper au serial et à l’étiquette de baie via ls -l /dev/disk/by-id et votre inventaire chassis.
3. Insérer le disque de remplacement. Confirmer qu’il apparaît dans /dev/disk/by-id.
4. Vérifier que le disque de remplacement n’est pas plus petit que l’ancien : lsblk.
5. Exécuter zpool replace <pool> <old> <new>.
6. Surveiller le resilver : zpool status jusqu’à la fin. Surveillez la latence système.
7. Quand c’est ONLINE, consigner la durée du resilver et les erreurs observées.
8. Optionnel : lancer un scrub dans la prochaine fenêtre calme (pas immédiatement si le système est lourdement sollicité).

Checklist C : Validation post-remplacement

1. zpool status -v montre ONLINE et 0 erreurs connues sur les données.
2. SMART du nouveau disque montre une base propre (sauvegardez le rapport SMART).
3. Confirmer que les alertes sont claires dans Proxmox et votre monitoring.
4. Mettre à jour l’inventaire : mapping baie → serial, suivi de garantie et date de remplacement.

Checklist D : Si le resilver est lent ou bloqué

1. Vérifier si un autre disque affiche désormais des erreurs (SMART + kernel logs).
2. Vérifier la saturation : iostat -x et la charge des VM.
3. Envisager de mettre en pause les jobs non critiques (sauvegardes, réplications, gros mouvements de données).
4. Si les erreurs augmentent, stoppez les modifications et planifiez une coupure contrôlée avec des sauvegardes prêtes.

Erreurs courantes : symptômes → cause racine → correction

1) Pool toujours DEGRADED après remplacement

Symptôme : Vous avez remplacé un disque, mais zpool status montre encore DEGRADED et l’ancien nom de périphérique traîne.

Cause racine : Vous avez utilisé le mauvais identifiant (par ex. remplacé /dev/sdb mais ZFS suivait by-id), ou vous avez attaché sans remplacer.

Correction : Utilisez zpool status pour trouver la chaîne exacte, puis exécutez zpool replace pool <that-exact-old> <new-by-id>. Évitez /dev/sdX.

2) Le disque de remplacement est “trop petit” bien que même modèle

Symptôme : zpool replace renvoie une erreur “device is too small”.

Cause racine : Les fabricants varient silencieusement la capacité utilisable selon les révisions de firmware, ou l’ancien disque avait une taille signalée légèrement supérieure.

Correction : Utilisez un disque égal ou plus grand. Pour les pools de boot mirror, achetez directement la capacité supérieure plutôt que de jouer au bingo des numéros de modèle.

3) Le resilver rampe et le nœud est inutilisable

Symptôme : Latence VM élevée, iowait important, utilisateurs se plaignent, ETA du resilver n’en finit pas.

Cause racine : Conflit de charge (écritures VM + lectures/écritures du resilver), et peut-être un disque survivant marginal.

Correction : Réduisez la charge (pause des jobs lourds, migrer les VM non critiques), vérifiez SMART des disques survivants, et planifiez une fenêtre de maintenance. Si le disque survivant donne des erreurs, votre urgence réelle est « second disque en train de mourir ».

4) Vous avez retiré le mauvais disque et la pool est maintenant OFFLINE

Symptôme : La pool tombe, les VM s’arrêtent/plantent, et zpool status montre des périphériques manquants.

Cause racine : Erreur d’identification humaine : mapping baie non confirmé, instabilité des noms de périphériques, ou pas de procédure LED pour localiser.

Correction : Réinsérez le disque correct immédiatement. Si vous avez retiré un membre mirror sain, remettez-le d’abord. Puis réévaluez. C’est pourquoi il faut étiqueter les baies et enregistrer les serials.

5) Pool de boot Proxmox remplacée, mais le nœud ne boot pas

Symptôme : Après avoir remplacé un disque dans rpool, le système ne boote pas depuis le nouveau disque si l’ancien est retiré.

Cause racine : Le bootloader/entrée EFI n’a pas été installé ou miroir sur le nouveau périphérique. La redondance ZFS ne reflète pas automatiquement l’état du bootloader.

Correction : Assurez-vous que la configuration de boot Proxmox/EFI est répliquée sur les disques de boot. Validez cela en changeant temporairement l’ordre de boot BIOS ou en faisant un test de boot contrôlé.

6) Erreurs CKSUM alors que SMART semble sain

Symptôme : zpool status montre des erreurs checksum sur un périphérique, mais SMART paraît correct.

Cause racine : Souvent câblage, backplane, HBA ou problèmes d’alimentation provoquant une corruption des données en transit.

Correction : Reseat/remplacez les câbles, déplacez le disque vers un autre port/baie/contrôleur, vérifiez la stabilité du firmware HBA. Effacez les erreurs après correction et observez si elles reviennent.

Trois mini-récits d’entreprise tirés de la vie réelle

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

Une entreprise de taille moyenne exploitait Proxmox sur deux nœuds, chacun avec un mirror ZFS pour le boot et un RAIDZ séparé pour le stockage VM.
Un matin, un nœud signala DEGRADED. L’ingénieur on-call vit /dev/sdb d’un coup d’œil sur zpool status,
supposa que cela correspondait à « Baie 2 », et demanda à l’équipe facilities d’enlever ce disque.

Facilities fit exactement ce qu’on lui demanda, sauf que les baies n’étaient pas étiquetées et le châssis avait été recâblé lors d’un « nettoyage ».
Le disque extrait était le membre mirror sain, pas celui en erreur. La pool ne mourut pas instantanément parce que ZFS est poli — jusqu’à ce que ça n’aille plus.
Le nœud prit un coup de performance, puis un second disque lança des erreurs sous la charge de lecture supplémentaire.

La récupération fut douloureuse mais instructive : réinsérer le disque retiré, laisser la pool se stabiliser, puis refaire l’identification correctement en croisant
/dev/disk/by-id et les étiquettes physiques qu’ils créèrent pendant l’incident.
La solution durable fut simple : documenter le mapping baie→serial et arrêter d’utiliser les noms sdX.

L’erreur n’était pas « les gens font des erreurs ». C’était « les noms de périphérique sont stables ». Ils ne le sont pas. Pas même un bon jour.

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

Une autre organisation voulait des resilvers et scrubs plus rapides. Quelqu’un lut que « plus de parallélisme, c’est mieux » et tunna ZFS agressivement :
taux de scan plus élevés, plus d’opérations concurrentes, tout le folklore “faire monter le graphe”.
Ça avait l’air bien en labo au calme. En production, ça entra en collision avec des charges réelles : bases de données, sauvegardes, réplication.

Lors d’un événement dégradé, le resilver démarra à un débit impressionnant, puis le nœud commença à timeouter l’I/O des invités.
Le cluster VM ne planta pas; il devint lent comme de la mélasse. Les opérateurs essayèrent de réparer en redémarrant des services et migrant des VM,
ce qui ajouta de l’I/O. Le resilver ralentit encore. Plus de retries. Plus de douleur.

Ils se stabilisèrent en revenant sur l’« optimisation » et en laissant le resilver courir à un rythme soutenable,
priorisant la latence service sur les chiffres de benchmark. Après l’incident, ils gardèrent des valeurs conservatrices et créèrent un runbook :
pendant le resilver, mettre en pause les jobs non essentiels et traiter la latence stockage comme un SLO prioritaire.

La leçon : la vitesse du resilver n’est pas un chiffre de vanité. Le seul nombre qui compte est « terminé sans seconde panne pendant que les utilisateurs travaillaient ».

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

Une entreprise régulée exploitait des nœuds Proxmox avec mirrors ZFS et une habitude stricte : chaque baie avait une étiquette,
chaque étiquette correspondait à un serial enregistré, et chaque remplacement se faisait par by-id avec des captures d’écran de zpool status
collées dans le ticket.

Quand une pool se dégrada pendant une semaine de vacances, l’ingénieur on-call était un généraliste, pas un spécialiste stockage.
Il suivit le runbook : vérifier le statut ZFS, mapper le serial, valider SMART, confirmer le serial de remplacement,
puis seulement remplacer. Pas de fantaisie. Pas de raccourcis.

Le resilver s’acheva proprement. Un scrub ultérieur ne trouva pas d’erreurs. La revue post-incident fut courte parce qu’il n’y avait pas grand-chose à revoir.
Leur pratique « ennuyeuse » évita le désastre le plus courant : retirer le mauvais disque ou remplacer le mauvais membre vdev.

L’ennuyeux est sous-estimé. L’ennuyeux vous fait dormir.

FAQ

1) Dois-je utiliser l’interface Proxmox pour remplacer un disque, ou la CLI ?

Utilisez la CLI pour les opérations ZFS réelles. L’interface graphique est utile pour la visibilité, mais zpool status est la source de vérité,
et vous voulez des commandes et sorties copiables-collables pour vos notes d’incident.

2) Puis-je redémarrer pendant un resilver ?

Évitez-le. ZFS peut généralement reprendre un resilver, mais un reboot introduit des risques : renumérotation des périphériques, bizarreries HBA,
et la possibilité qu’un disque marginal ne revienne pas. Si vous devez redémarrer pour stabilité, faites-le intentionnellement et documentez l’état avant/après.

3) Quelle est la différence entre zpool replace et zpool attach ?

replace substitue un périphérique par un autre et déclenche un resilver. attach ajoute un nouveau périphérique à un mirror
(transformant un vdev mono-disque en mirror, ou élargissant un mirror). Pour un membre mirror défaillant, vous voulez presque toujours replace.

4) Dois-je lancer un scrub immédiatement après le remplacement ?

Pas immédiatement, sauf si vous êtes dans une fenêtre calme et pouvez tolérer la charge. Un resilver lit déjà beaucoup de données.
Planifiez un scrub après que le système se soit refroidi, particulièrement sur des pools RAIDZ.

5) Le disque apparaît comme UNAVAIL. Est-il mort ?

Pas nécessairement. UNAVAIL peut signifier que l’OS ne le voit pas (chemin/câble/contrôleur) ou que le disque est mort.
Vérifiez /dev/disk/by-id, les kernel logs, et SMART si le périphérique réapparaît.

6) Puis-je remplacer un disque par un plus grand et gagner de l’espace ?

Vous pouvez remplacer par des disques plus gros, mais l’espace utilisable n’augmente que quand tous les membres d’un vdev sont mis à niveau
et que ZFS autorise l’expansion. Les mirrors gagnent après que les deux faces sont plus grandes ; RAIDZ après que tous les disques du vdev sont plus grands.

7) Pourquoi ZFS montre des erreurs alors que les applications semblaient normales ?

Parce que ZFS peut corriger beaucoup d’erreurs de façon transparente grâce à la redondance et aux checksums. Ce n’est pas « tout va bien », c’est « on a intercepté la corruption ».
Traitez les erreurs corrigées comme un avertissement : quelque chose se dégrade.

8) Que faire si le disque survivant dans un mirror commence à montrer des erreurs SMART pendant le resilver ?

C’est le moment inconfortable : vous êtes peut-être dans une situation à deux pannes imminentes.
Si possible, réduisez la charge, priorisez la sauvegarde/réplication des données critiques, et réfléchissez si vous devez arrêter et exécuter un plan de récupération contrôlé.
Continuer peut fonctionner — mais vous jouez avec votre dernière copie saine dans ce vdev.

9) ZFS mirror automatiquement le bootloader Proxmox sur rpool ?

Pas de façon fiable tout seul. ZFS réplique les blocs de données ; l’amorçage dépend de l’installation du bootloader/EFI et des entrées firmware.
Après un remplacement de disques de boot, validez que chaque disque est capable de booter indépendamment si votre conception l’exige.

10) Est-il sûr de mettre un disque en “offline” avant de le retirer ?

Oui, quand vous retirez délibérément un membre (surtout en hot-swap). L’offline réduit les surprises en informant ZFS que le périphérique va disparaître.
Mais ne mettez jamais offline le dernier membre sain d’un vdev. Confirmez d’abord la topologie.

Conclusion : étapes suivantes une fois revenu à ONLINE

Passer de DEGRADED à ONLINE est la victoire tactique. La victoire stratégique est de faire en sorte que la prochaine panne de disque
soit ennuyeuse, rapide et ne réclame pas d’héroïsme.

1. Documenter l’incident : coller zpool status -v avant/après, la sortie SMART, et quel serial a été remplacé.
2. Résoudre la dette d’identification : étiqueter les baies, tenir un mapping serial→slot, et standardiser sur /dev/disk/by-id.
3. Vérifier le monitoring : alertes pour l’état des pools ZFS, attributs SMART critiques, et resets de lien kernel.
4. Planifier les scrubs : assez réguliers pour détecter la dégradation, mais pas si fréquents qu’ils stressent constamment les disques.
5. Pratiquer le runbook : le meilleur moment pour apprendre zpool replace n’est pas la première fois que votre pool se dégrade.

ZFS vous donne une chance de combattre. Ne la gâchez pas avec des approximations. Remplacez le bon disque, de la bonne manière, et gardez les dégâts collatéraux là où ils doivent être : nulle part.