Si vous avez été en mesure d'identifier le disque dur à l'origine du problème, je vous conseillerais de le remplacer immédiatement et de laisser votre matrice se reconstruire. SI vous utilisez Raid 5, ajoutez peut-être un disque de secours supplémentaire et laissez-le se construire sur Raid 6. Ensuite, le disque dur doit faire face aux problèmes pour que votre baie ne subisse pas de temps d'arrêt ni de dégradation des performances, et fonctionne des diagnostics dessus, y compris un balayage de surface pour identifier et marquer les zones à problèmes comme mauvaises.
Il est préférable d’avoir les zones douteuses marquées en permanence BAD de manière permanente plutôt que d’essayer de récupérer des données à partir d’entre elles et de les faire indiquer BON, alors que ces secteurs vont tout de suite tomber en panne.
L’article référencé ci-dessus s'apparente à la gestion d’un CHKDSK / R qui lit et teste minutieusement chaque secteur d’une unité et bloque les points critiques pour tenter de récupérer les données des points critiques et marque parfois le secteur comme "bon" et ne même appliquer à une matrice RAID. Dans ce cas, vous avez effectivement une matrice RAID, ce qui devrait être totalement inutile et non pas ce que vous voudriez faire. Ce serait une pression terrible sur tous vos lecteurs et ne résoudrait pas votre problème sous-jacent.
Dans tous les cas, je ne réintégrerais pas ce lecteur dans le tableau, car je suppose que l'intégrité est primordiale.
Vous pouvez facilement l’utiliser pour un système Un-Raid sans aucun risque réel, ce qui représente une sorte de mélange entre un JBOD et le Raid 4. Le service informatique utilise un lecteur pour la parité de tous les autres lecteurs qu’il traite comme un seul grand lecteur. Pas de segmentation. Ainsi, si un lecteur est supprimé, les données de ce lecteur sont toujours utilisables et peuvent être remplacées et reconstruites par un autre lecteur à partir des autres lecteurs et du lecteur de parité, comme le Raid 4.
