Procédure de remplacement des disques NAS domestiques pour des identifiants d’appareil stables et une vérification

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

L’approche la plus sûre consiste à traiter les numéros de série des cartes et les identifiants persistants, à remplacer un seul membre confirmé, puis à vérifier la reconstruction et la charge de travail d’origine comme une suite de contrôles observables, et non comme une commande unique.

Sur un NAS domestique Linux utilisant ZFS, mdraid ou Btrfs, le risque pratique est de devoir remplacer un disque NAS sans confondre les lettres de périphériques Linux changeantes. Enregistrez l’identité actuelle et le point de récupération, commencez par le discriminateur le moins intrusif, interprétez les résultats de réussite et d’échec avant de modifier une autre variable, et arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable risque d’être exposée. Le processus ci-dessous ne se termine qu’une fois que la charge de travail d’origine fonctionne ou que les éléments réunis atteignent un seuil nécessitant une escalade.

Créer une carte de remplacement reliant les numéros de série aux baies

Enregistrez l’état de la baie ou du pool, la topologie des périphériques, l’identité SMART, l’emplacement dans le boîtier, le numéro de série, le WWN et le lien symbolique /dev/disk/by-id de chaque membre. Les lettres de périphériques Linux peuvent changer après un redémarrage ou une connexion à chaud ; /dev/sdX est donc une observation valable pour ce démarrage, et non l’identité durable à utiliser dans l’enregistrement du remplacement.

Un guide pratique consacré aux serveurs domestiques ZFS montre comment effectuer un remplacement avec un chemin by-id persistant et surveiller la resilverisation plutôt que de faire confiance à une lettre de périphérique temporaire. Le même principe d’identité s’applique à mdraid et Btrfs, même si leurs commandes de remplacement diffèrent.

Faites correspondre deux fois le membre défaillant indiqué par le logiciel avec l’étiquette physique : une fois avant la mise hors ligne et une nouvelle fois avant le retrait du matériel. Arrêtez-vous si le relais du numéro de série est absent, si deux baies signalent la même identité de pont ou si le pool ne peut pas tolérer la mise hors ligne d’un autre membre.

Préparer le remplacement sans réduire prématurément la redondance

Vérifiez que le nouveau disque possède au moins autant de secteurs utilisables, qu’il utilise le format de secteurs attendu et qu’il réussit les contrôles de santé de base en dehors de la baie lorsque cela est possible. Enregistrez son numéro de série et son chemin by-id avant l’insertion. Pour les membres chiffrés ou amorçables, conservez également la disposition des partitions, les clés et les métadonnées d’amorçage requises par la plateforme concernée.

Consultez la discussion de ZimaSpace sur les différentes tailles de secteurs dans un miroir ZFS lorsqu’un disque de remplacement signale une taille de secteur logique ou physique différente. La capacité indiquée sur le boîtier ne suffit pas ; la taille réelle, les attentes concernant ashift ou l’alignement, la table de partitions et les règles de la plateforme NAS déterminent si le remplacement est valide.

Ne remplacez qu’un seul périphérique à la fois. Si l’ancien disque est toujours lisible et que la plateforme prend en charge l’ajout avant le retrait, cela peut préserver la redondance ; sinon, mettez le membre confirmé hors ligne, éteignez le système lorsque le châssis ne prend pas en charge le remplacement à chaud et étiquetez immédiatement le disque retiré.

Démarrer et surveiller la reconstruction propre à la plateforme

Utilisez l’identité du membre du pool ou de la baie affichée par sa propre commande d’état, associée au nouveau chemin by-id persistant. Ne collez pas une commande générique sans vérifier la topologie : le remplacement d’un miroir ZFS, l’ajout d’un membre mdraid et le remplacement d’un périphérique Btrfs reposent sur des machines à états et des sémantiques d’échec différentes.

Surveillez la progression, les erreurs de lecture, les réparations de sommes de contrôle, les changements SMART, la température et les réinitialisations du contrôleur. Un autre compte rendu indépendant du remplacement insiste sur l’enregistrement du numéro de série du disque défaillant et sur l’attente de la fin de la resilverisation avant de remplacer le membre suivant.

Si le nouveau disque disparaît, si les erreurs augmentent sur un membre survivant ou si la reconstruction redémarre à plusieurs reprises, arrêtez les charges non essentielles et préservez les journaux. Ne retirez pas un autre disque, n’effacez pas les erreurs et ne forcez pas la fin du processus tant que le composant défaillant et la redondance actuelle ne sont pas compris.

Vérifier le NAS réparé avant de mettre l’ancien disque hors service

Une barre de progression arrivée à son terme est nécessaire, mais pas suffisante. Confirmez que le pool ou la baie est sain, que chaque membre prévu utilise l’identité persistante attendue, qu’aucune partition ne reste sous-dimensionnée et que les montages planifiés, les partages, les conteneurs et les sauvegardes résistent à deux redémarrages.

Exécutez le contrôle d’intégrité ou le scrub de la plateforme après la reconstruction, conformément à son processus sécurisé, puis restaurez un fichier représentatif et reproduisez la charge de travail à l’origine de la panne. Vérifiez que les compteurs d’erreurs restent stables pendant des lectures et écritures prolongées.

Gardez l’ancien disque hors ligne et étiqueté jusqu’à ce que le nouveau membre ait réussi une charge de travail normale et un cycle de sauvegarde. La récupération est terminée lorsque la topologie, les contrôles de données, l’état des périphériques et les chemins applicatifs sont tous validés ; déclenchez une escalade si l’identité reste ambiguë ou si un membre survivant développe de nouvelles erreurs pendant la reconstruction.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.