J'avais créé deux partitions de disque dur de 2 To ( /dev/sdb1et /dev/sdc1) dans une matrice RAID 1 appelée à l' /dev/md0aide mdadmd'Ubuntu 12.04 LTS Precise Pangolin.
La commande sudo mdadm --detail /dev/md0utilisée pour indiquer les deux disques comme synchronisation active .
Ensuite, pour les tests, j'ai échoué, je l'ai /dev/sdb1supprimé, puis ajouté à nouveau avec la commandesudo mdadm /dev/md0 --add /dev/sdb1
watch cat /proc/mdstat a montré une barre de progression de la reconstruction de la baie, mais je ne passerais pas des heures à la regarder, j'ai donc supposé que le logiciel savait ce qu'il faisait.
Une fois que la barre de progression n'était plus affichée, cat /proc/mdstataffiche:
md0 : active raid1 sdb1[2](S) sdc1[1]
1953511288 blocks super 1.2 [2/1] [U_]
Et sudo mdadm --detail /dev/md0montre:
/dev/md0:
Version : 1.2
Creation Time : Sun May 27 11:26:05 2012
Raid Level : raid1
Array Size : 1953511288 (1863.01 GiB 2000.40 GB)
Used Dev Size : 1953511288 (1863.01 GiB 2000.40 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Mon May 28 11:16:49 2012
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
Name : Deltique:0 (local to host Deltique)
UUID : 49733c26:dd5f67b5:13741fb7:c568bd04
Events : 32365
Number Major Minor RaidDevice State
1 8 33 0 active sync /dev/sdc1
1 0 0 1 removed
2 8 17 - spare /dev/sdb1
On m'a dit que mdadm remplace automatiquement les disques supprimés par des pièces de rechange, mais qu'il /dev/sdb1n'est pas déplacé dans la position attendue, RaidDevice 1.
MISE À JOUR (30 mai 2012): Un badblockstest destructif en lecture-écriture de l'ensemble /dev/sdbn'a produit aucune erreur comme prévu; les deux disques durs sont nouveaux.
Depuis la dernière modification, j'ai assemblé le tableau avec cette commande:
sudo mdadm --assemble --force --no-degraded /dev/md0 /dev/sdb1 /dev/sdc1
Le résultat était:
mdadm: /dev/md0 has been started with 1 drive (out of 2) and 1 rebuilding.
La reconstruction semble se dérouler normalement:
md0 : active raid1 sdc1[1] sdb1[2]
1953511288 blocks super 1.2 [2/1] [U_]
[>....................] recovery = 0.6% (13261504/1953511288) finish=2299.7min speed=14060K/sec
unused devices: <none>
J'attends maintenant cette reconstruction, mais je m'attends /dev/sdb1à devenir une pièce de rechange comme les cinq ou six fois que j'ai essayé de reconstruire auparavant.
MISE À JOUR (31 mai 2012): Oui, c'est toujours une pièce de rechange. Pouah!
MISE À JOUR (01 juin 2012): J'essaie la commande suggérée par Adrian Kelly :
sudo mdadm --assemble --update=resync /dev/md0 /dev/sdb1 /dev/sdc1
En attendant la reconstruction maintenant ...
MISE À JOUR (02 juin 2012): Non, toujours une pièce de rechange ...
Mise à jour (04 Juin 2012): PB a une inquiétude que je négligé: peut - être /dev/sdc1se heurte à des erreurs d' E / S . Je n'avais pas pris la peine de vérifier /dev/sdc1car cela semblait fonctionner très bien et c'était tout neuf, mais les erreurs d'E / S vers la fin du lecteur sont une possibilité rationnelle.
J'ai acheté ces disques durs en vente, il ne serait donc pas surprenant que l'un d'entre eux soit déjà en panne. De plus, aucun d'eux ne prend en charge SMART , donc pas étonnant qu'ils soient si bon marché ...
Voici la procédure de récupération de données que je viens de créer et que je suis:
sudo mdadm /dev/md0 --fail /dev/sdb1afin que je puisse sortir/dev/sdb1.sudo mdadm /dev/md0 --remove /dev/sdb1à supprimer/dev/sdb1du tableau./dev/sdc1est monté à/media/DtkBk- Formater
/dev/sdb1en ext4. - Monter
/dev/sdb1sur/media/DtkBkTemp. cd /mediade travailler dans ce domaine.sudo chown deltik DtkBkTemppour me donner desdeltikdroits (nom d'utilisateur ) sur la partition.- Faites une copie de tous les fichiers et répertoires:
sudo rsync -avzHXShP DtkBk/* DtkBkTemp
MISE À JOUR (06 juin 2012): J'ai fait un badblockstest destructif en mode écriture de /dev/sdc, en suivant les procédures suivantes:
sudo umount /media/DtkBkpour permettre le démontage de la baie.sudo mdadm --stop /dev/md0pour arrêter le tableau.sudo badblocks -w -p 1 /dev/sdc -s -vpour effacer le disque dur suspect et, au cours du processus, recherchez les erreurs d'E / S. S'il y a des erreurs d'E / S, ce n'est pas un bon signe. J'espère que je peux obtenir un remboursement ...
J'ai maintenant confirmé qu'il n'y a aucun problème d'entrée / sortie sur les deux disques durs .
De toutes ces investigations, mes deux questions originales sont toujours d'actualité.
Mes questions sont:
- Pourquoi le disque de rechange ne devient-il pas une synchronisation active?
- Comment activer le disque de rechange?
/dev/sdc1à l'époque parce qu'il/dev/sdc1était lu pendant/dev/sdb1était en cours d'écriture et les secteurs défectueux/dev/sdb1auraient été remappés de manière transparente lors de l'écriture.watch -n 60 cat /proc/mdstatoù60est le nombre de secondes entre les rafraîchissements.J'ai eu exactement le même problème, et dans mon cas, j'ai découvert que le disque de raid actif souffrait d'erreurs de lecture lors de la synchronisation. Par conséquent, le nouveau disque a été synchronisé avec succès et a donc été conservé comme étant disponible.
Vous voudrez peut-être vérifier vos / var / log / messages et autres journaux système pour les erreurs. De plus, il peut également être judicieux de vérifier l'état SMART de votre disque:
1) Exécutez le test court:
2) Affichez les résultats du test:
Dans mon cas, cela a renvoyé quelque chose comme ceci:
J'ai dû démarrer une distribution en direct et copier manuellement les données du disque défectueux sur le nouveau (actuellement "de rechange").
la source
J'ai eu exactement le même problème et j'ai toujours pensé que mon deuxième disque, que je voulais rajouter à la matrice, avait des erreurs. Mais c'était mon disque d'origine qui avait des erreurs de lecture.
Vous pouvez le vérifier avec
smartctl -t short /dev/sdXet voir les résultats quelques minutes plus tard avecsmartctl -l selftest /dev/sdX. Pour moi, cela ressemblait à ceci:J'ai essayé de les réparer avec ce manuel . C'était amusant :-). Je sais que vous avez vérifié les deux disques pour les erreurs, mais je pense que votre problème est que le disque qui est toujours dans la matrice md a des erreurs de lecture, donc l'ajout d'un deuxième disque échoue.
Mise à jour
Vous devez en plus exécuter un
smartctl -a /dev/sdXSi vous voyez Current_Pending_Sector> 0 quelque chose ne va pas197 Current_Pending_Sector 0x0012 098 098 000 Old_age Always - 69
Pour moi, c'était définitivement le problème que j'ai supprimé un disque du raid juste pour tester et resynchroniser ne pouvait pas être fait en raison d'échecs de lecture. La synchronisation a été interrompue à mi-chemin. Quand j'ai vérifié mon disque qui était toujours dans le tableau RAID, smartctl a signalé des problèmes.
J'ai pu les corriger avec le manuel ci-dessus et j'ai vu le nombre de secteurs en attente réduit. Mais il y en avait trop et c'est une procédure longue et ennuyeuse, j'ai donc utilisé ma sauvegarde et restauré les données sur un autre serveur.
Comme vous n'avez pas eu l'occasion d'utiliser SMART, je suppose que votre auto-test n'a pas révélé ces secteurs cassés.
Pour moi, c'est une leçon apprise: vérifiez vos disques avant d'en retirer un de votre baie.
la source
J'ai rencontré un problème similaire et l'ai résolu en augmentant la quantité de disques RAID de 1 à 2.
la source
MISE À JOUR (24 mai 2015): Après trois ans, j'ai enquêté sur la véritable cause de la dégradation de la matrice RAID 1.
tl; dr: L'un des disques était défectueux, et je ne l'ai pas remarqué car je n'avais effectué qu'un test de surface complet sur le bon disque.
Il y a trois ans, je ne pensais pas à vérifier les journaux sur les problèmes d'E / S. Si j'avais pensé à vérifier
/var/log/syslog, j'aurais vu quelque chose comme ça quand j'aimdadmrenoncé à reconstruire le tableau:Pour obtenir cette sortie dans le journal, j'ai cherché le premier LBA problématique (14381058, dans mon cas) avec cette commande:
Pas étonnant que
mdj'abandonne! Il ne peut pas reconstruire un module RAID à partir d'un mauvais disque.Une nouvelle technologie (meilleure
smartmontoolscompatibilité matérielle?) M'a permis d'obtenir des informations SMART du lecteur, y compris les cinq dernières erreurs (sur 1393 jusqu'à présent):Ahh… ça le ferait.
Maintenant, j'ai résolu cette question en trois étapes faciles:
MISE À JOUR (19 juillet 2015): Pour tous ceux qui sont curieux, le lecteur a finalement manqué de secteurs pour remapper:
la source
Dans mon cas, c'était aussi un mauvais disque source. Bien qu'il semblait à l'époque comme il ne l'était pas (le / proc / mdstat a progressé au-dessus de 99,9% normalement - mais il a en fait échoué à 99,97%, ce qui concordait avec la fin de la synchronisation régulière). Vous devez donc vérifier la
dmesg(1)sortie - il vous dira s'il y a des erreurs de lecture.Vous pouvez voir les détails de mon cas dans le bogue Debian # 767243 . J'ai finalement réussi à terminer la synchronisation en écrasant de force quelques secteurs défectueux sur le disque source (qui étaient heureusement inutilisés dans mon cas, sinon il y aurait eu une perte de données)
la source
Tu pourrais essayer
pour mettre à jour les disques et les resynchroniser.
la source
/dev/sdb1n'est toujours pas devenu "actif" après avoir été reconstruit comme pièce de rechange.Je ne sais pas si cela fonctionnera puisque vous avez déjà
--addédité le disque mais--re-addsemble être l'option dont vous avez besoin.Ou peut-être avez-vous besoin de
--growl'appareil sur 2 disques actifsmdadm --grow -n 2? Non testé alors soyez prudent.la source
sudo mdadm --grow -n 2a été l'une des premières choses que j'ai faites, c'est pourquoisudo mdadm --detail /dev/md0montre deux emplacements. Désolé, ça ne marche pas.Je recommanderais de supprimer sdc1, de mettre à zéro le super bloc sur sdc1, puis de le rajouter.
la source