Il y a des moments dans la vie d’un homelab où tout fonctionne parfaitement.
- Les VM tournent.
- Les conteneurs Docker ronronnent.
- Les sauvegardes se font.
- Proxmox est content.
- Et toi aussi.Puis un matin… CLAC. Un disque décide que sa carrière dans l’informatique est terminée.
Pas de préavis. Pas de pot de départ. Pas même un petit mail :
« Bonjour, après réflexion, j’ai décidé de poursuivre mon chemin professionnel dans un autre serveur. »
Non. Il meurt. Et là, tu regardes ton pool ZFS avec cette petite boule dans le ventre :
« Bon… maintenant, je fais quoi ? »
C’est exactement ce que nous allons voir ici.
L’objectif de cet article est de montrer comment remplacer un disque défectueux dans un pool ZFS sous Proxmox VE, étape par étape, sans transformer ton serveur en barbecue électronique.
Et surtout, on va essayer de comprendre ce que l’on fait, plutôt que de simplement copier-coller trois commandes trouvées sur un forum à 3h17 du matin.
ZFS, c’est quoi exactement ?
Avant de commencer à taper des commandes qui ressemblent à des incantations Linux, petit retour au calme. ZFS est un système de fichiers et de gestion de stockage qui permet notamment de créer des pools de stockage redondants. Dans Proxmox, on peut notamment utiliser différentes configurations comme :
mirrorraidz1raidz2- etc.
L’idée générale est simple :
Plusieurs disques travaillent ensemble pour former un espace de stockage.
Et selon la configuration choisie, la perte d’un disque peut être encaissée par le pool. Mais attention à une confusion très importante : ZFS n’est pas une sauvegarde.
La redondance permet de continuer à fonctionner malgré certaines pannes matérielles. Une sauvegarde, elle, permet notamment de récupérer des données supprimées, corrompues ou perdues dans d’autres circonstances.
Donc oui :
ZFS peut sauver ton serveur d’un disque mort.
Mais non :
ZFS ne va pas récupérer le fichier que tu as supprimé à 14h32 parce que tu pensais que c’était un vieux fichier temporaire.
Ça, c’est une autre aventure. 😏
Le scénario
Imaginons que notre pool s’appelle :
Raid5Et qu’un disque vient de rendre l’âme.
Notre mission est donc :
Disque HS
↓
Nouveau disque
↓
Remplacement dans ZFS
↓
Resilvering
↓
Pool ONLINEEt si tout se passe bien :
☕ café
😌 soulagement
🖥️ serveur toujours vivant
Étape 1 : Identifier le problème
La première chose à faire n’est surtout pas de retirer des disques au hasard. On commence par demander à ZFS ce qu’il pense de la situation.
Dans le Shell de Proxmox :
zpool statusCette commande permet notamment d’identifier le pool concerné et l’état de ses disques.
On cherche notamment :
UNAVAIL
ou
FAULTEDLe document de procédure utilise par exemple un pool appelé Raid5 et un identifiant de disque défectueux : 1554042950987981658
Pourquoi cette étape est importante ?
Parce que ZFS ne raisonne pas simplement en disant :
« Le disque sdb est mort. »
Il possède ses propres identifiants pour les périphériques.
Et c’est justement là qu’il faut éviter une erreur classique.
Étape 2 : Installer le nouveau disque
On installe physiquement le nouveau disque dans le serveur.
À ce stade, on pourrait se dire :
« Cool, il est là, je lance
zpool replaceet terminé. »
Doucement, cowboy. Avant de lui confier une nouvelle vie, on va vérifier et nettoyer le disque depuis Proxmox.
Dans l’interface Web : Votre nœud → Disques
On sélectionne le nouveau disque. Puis : Wipe Disk
Cette opération permet de supprimer les anciennes informations de partition présentes sur le disque.
Pourquoi nettoyer le disque ?
Parce qu’un disque qui sort d’une autre machine peut avoir encore :
- des partitions ;
- d’anciennes informations de stockage ;
- une ancienne configuration ;
- bref, tout un tas de souvenirs dont notre nouveau pool ZFS n’a absolument rien à faire.
On repart donc sur une base propre.
Étape 3 : Trouver le vrai nom du nouveau disque
Et maintenant arrive un petit piège très classique sous Linux.
Vous allez parfois voir votre disque sous une forme comme :
/dev/sdbLe problème ?
Les noms comme sda, sdb, sdc peuvent dépendre de la manière dont les périphériques sont détectés.
Pour notre opération, on veut donc utiliser un identifiant plus précis.
On ouvre le Shell de Proxmox.
Puis :
ls -l /dev/disk/by-id/ | grep sdXBien entendu, il faut remplacer sdX par le disque correspondant.
Par exemple :
ls -l /dev/disk/by-id/ | grep sdbon chercher un identifiant du type :
wwn-0x...ou :
ata-...Pourquoi utiliser cet identifiant ?
Parce que nous voulons être absolument certains du disque que nous allons donner à ZFS. Et quand on parle de stockage, « normalement c’est le bon disque » n’est pas une stratégie particulièrement rassurante.
Étape 4 : Identifier le disque mort
On retourne maintenant à notre commande préférée :
zpool statusOn récupère deux informations importantes :
1. Le nom du pool
Dans notre exemple :
Raid52. L’identifiant du disque défectueux
Par exemple :
1554042950987981658Ces informations seront utilisées dans la commande de remplacement.
Et là, franchement : Prenez votre temps. C’est probablement la partie la plus importante de toute la procédure. On ne veut surtout pas remplacer le mauvais disque.
Étape 5 : Le moment où on tape la commande magique
Nous avons maintenant :
- notre pool ;
- l’identifiant de l’ancien disque ;
- l’identifiant du nouveau disque.
On peut donc lancer le remplacement.
La structure générale est :
zpool replace <nom_du_pool> <ID_ancien_disque> /dev/disk/by-id/<ID_nouveau_disque>Dans notre exemple :
zpool replace Raid5 1554042950987981658 /dev/disk/by-id/wwn-0x50026b728269f4b6Et là… On respire. Parce qu’une commande ZFS lancée trop vite avec un mauvais disque, ce n’est pas exactement le genre de chose qu’on veut faire pour commencer sa journée.
Mais qu’est-ce qu’on vient de demander à ZFS ?
La commande peut sembler assez obscure.
Alors décortiquons-la.
zpool replaceOn dit à ZFS :
« Je veux remplacer un périphérique dans mon pool. »
Puis :
Raid5C’est le nom du pool concerné.
Ensuite :
1554042950987981658C’est l’identifiant de l’ancien disque défectueux.
Et enfin :
/dev/disk/by-id/wwn-0x50026b728269f4b6C’est le chemin vers le nouveau disque.
En gros :
« ZFS, prends ce disque neuf et utilise-le pour remplacer celui qui vient de décider de rejoindre le paradis des HDD. »
Étape 6 : Et maintenant… le Resilvering
C’est ici que ZFS commence réellement son travail. La reconstruction démarre automatiquement.
Ce processus est appelé le : Resilvering
Le terme est un peu bizarre, mais l’idée est relativement simple. ZFS va reconstruire sur le nouveau disque les données nécessaires afin de rétablir la redondance du pool.
Et là, il va falloir… attendre.
Oui.C’est probablement la partie la plus difficile pour un administrateur système. Parce que techniquement, il ne reste plus grand-chose à faire.
Mais psychologiquement le 99% est capable de devenir le chiffre le plus intéressant de votre journée. 😂
Suivre la reconstruction
Pour suivre l’état du pool depuis le Shell :
zpool status Raid5Vous pouvez également passer par l’interface Web de Proxmox : Votre nœud → Disques → ZFS → votre pool
Pendant ce temps : NE PAS PANIQUER
C’est probablement le meilleur conseil que je puisse donner. Le serveur peut continuer à fonctionner pendant la reconstruction, selon la configuration et l’état du pool. Mais le pool est en train de travailler pour retrouver sa situation normale.
Donc :
Ce n’est pas le moment idéal pour faire trois changements de configuration, déplacer 14 VM et décider que finalement Docker devrait tourner sur un autre stockage.
On laisse travailler la machine. Et on surveille.
Et quand le Resilvering arrive à 100 % ?
Là… 🎉, normalement, l’ancien disque défectueux est retiré de la configuration et le pool retrouve son état normal et le pool repasse en :
ONLINEEt franchement, voir :
ONLINEaprès avoir regardé un disque mourir… C’est une petite dose de bonheur informatique.
Le résumé express
Si vous devez retenir uniquement la procédure, elle ressemble à ça :
1. Vérifier l’état du pool
zpool status2. Installer le nouveau disque
Puis, dans Proxmox :
Nœud → Disques → nouveau disque → Wipe Disk
3. Trouver son identifiant
ls -l /dev/disk/by-id/ | grep sdX4. Identifier le pool et le disque HS
zpool status5. Remplacer le disque
zpool replace <pool> <ancien_ID> /dev/disk/by-id/<nouveau_ID>6. Surveiller
zpool status <pool>7. Attendre la fin du Resilvering
Et espérer que le café soit encore chaud.
Les erreurs que j’éviterais absolument
❌ Se fier uniquement à sda, sdb, sdc
Avant de remplacer un disque, vérifiez son identifiant. on utilise justement /dev/disk/by-id/ afin d’identifier précisément le nouveau périphérique.
❌ Se précipiter
Un remplacement de disque n’est pas une course.
Prenez quelques secondes pour vérifier :
Quel est mon pool ?
Quel est le disque HS ?
Quel est mon nouveau disque ?Si vous avez un doute : STOP. Mieux vaut passer cinq minutes à vérifier qu’une journée à expliquer pourquoi les données ont disparu.
❌ Oublier les sauvegardes
C’est probablement le point le plus important. La redondance protège contre certaines pannes matérielles. Elle ne remplace pas une stratégie de sauvegarde.
Donc : RAID ≠ Backup . Et oui… Même dans un magnifique homelab avec ZFS, Proxmox, 256 Go de RAM, trois GPU et suffisamment de Docker pour alimenter un petit cloud privé… un backup reste un backup.
Alors, est-ce compliqué ?
Techniquement ? Pas vraiment.
La procédure est relativement courte :
Identifier
↓
Nettoyer
↓
Identifier précisément
↓
Remplacer
↓
Resilver
↓
ONLINELe plus compliqué n’est finalement pas la commande. Le plus compliqué, c’est de savoir exactement quel disque on manipule avant de lancer la commande. Et ça, c’est une règle qui dépasse largement ZFS.
Conclusion : le disque est mort, vive le disque !
Un disque dur ou SSD qui meurt, ce n’est jamais très agréable. Mais si votre pool ZFS est correctement configuré et que la redondance permet d’encaisser la panne, le remplacement peut rester une opération relativement maîtrisable.
Dans notre cas, la procédure consiste essentiellement à :
- nettoyer le nouveau disque ;
- identifier précisément le nouveau périphérique ;
- identifier le pool ;
- identifier le disque défectueux ;
- lancer
zpool replace;- surveiller le resilvering ;
- attendre que le pool repasse
ONLINE.
Et surtout… ne pas paniquer. Parce que dans le monde du homelab, il existe une règle universelle :
Quand quelque chose clignote en rouge, commence par respirer.
Et une deuxième :
Quand quelque chose fonctionne parfaitement depuis six mois, commence à faire tes sauvegardes.
Parce que oui… Le serveur peut avoir du ZFS. Le serveur peut avoir du RAID. Le serveur peut avoir des snapshots. Le serveur peut avoir des sauvegardes automatiques. Mais le jour où tu commences une phrase par :
« Normalement, ça devrait fonctionner… »
…c’est probablement là que le véritable boss final vient de spawn. 😈
CtrlAltPlay — 1 / Serveur — 0.
Et maintenant… ☕ On peut retourner jouer avec notre homelab.
