Il y a quelque temps, j'avais un système RAID5 à la maison. L'un des 4 disques est tombé en panne, mais après l'avoir retiré et remis en place, il semblait être correct, alors j'ai commencé une resynchronisation. Quand il a fini, j'ai réalisé, à ma grande horreur, que 3 disques sur 4 ont échoué. Mais je ne crois pas que ce soit possible. Il existe plusieurs partitions sur les disques, chaque partie d'une matrice RAID différente.
- md0 est une matrice RAID1 composée de sda1, sdb1, sdc1 et sdd1.
- md1 est une matrice RAID5 composée de sda2, sdb2, sdc2 et sdd2.
- md2 est une matrice RAID0 composée de sda3, sdb3, sdc3 et sdd3.
md0 et md2 signale tous les disques alors que md1 signale 3 échecs (sdb2, sdc2, sdd2). C'est ma compréhension que lorsque les disques durs échouent, toutes les partitions doivent être perdues, pas seulement celles du milieu.
À ce stade, j'ai éteint l'ordinateur et débranché les disques. Depuis lors, j'utilisais cet ordinateur avec un nouveau disque plus petit.
Y a-t-il un espoir de récupérer les données? Puis-je en quelque sorte convaincre mdadm que mes disques fonctionnent en fait? Le seul disque qui peut vraiment avoir un problème est sdc mais celui-là aussi est signalé par les autres baies.
Mise à jour
J'ai enfin eu la chance de connecter les anciens disques et de démarrer cette machine à partir de SystemRescueCd. Tout ce qui précède a été écrit de mémoire. Maintenant, j'ai des données solides. Voici la sortie demdadm --examine /dev/sd*2
/dev/sda2:
Magic : a92b4efc
Version : 0.90.00
UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
Creation Time : Sun May 30 21:48:55 2010
Raid Level : raid5
Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1
Update Time : Mon Aug 23 11:40:48 2010
State : clean
Active Devices : 3
Working Devices : 4
Failed Devices : 1
Spare Devices : 1
Checksum : 68b48835 - correct
Events : 53204
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 0 8 2 0 active sync /dev/sda2
0 0 8 2 0 active sync /dev/sda2
1 1 8 18 1 active sync /dev/sdb2
2 2 8 34 2 active sync /dev/sdc2
3 3 0 0 3 faulty removed
4 4 8 50 4 spare /dev/sdd2
/dev/sdb2:
Magic : a92b4efc
Version : 0.90.00
UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
Creation Time : Sun May 30 21:48:55 2010
Raid Level : raid5
Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1
Update Time : Mon Aug 23 11:44:54 2010
State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 1
Spare Devices : 1
Checksum : 68b4894a - correct
Events : 53205
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 1 8 18 1 active sync /dev/sdb2
0 0 0 0 0 removed
1 1 8 18 1 active sync /dev/sdb2
2 2 8 34 2 active sync /dev/sdc2
3 3 0 0 3 faulty removed
4 4 8 50 4 spare /dev/sdd2
/dev/sdc2:
Magic : a92b4efc
Version : 0.90.00
UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
Creation Time : Sun May 30 21:48:55 2010
Raid Level : raid5
Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1
Update Time : Mon Aug 23 11:44:54 2010
State : clean
Active Devices : 1
Working Devices : 2
Failed Devices : 2
Spare Devices : 1
Checksum : 68b48975 - correct
Events : 53210
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 2 8 34 2 active sync /dev/sdc2
0 0 0 0 0 removed
1 1 0 0 1 faulty removed
2 2 8 34 2 active sync /dev/sdc2
3 3 0 0 3 faulty removed
4 4 8 50 4 spare /dev/sdd2
/dev/sdd2:
Magic : a92b4efc
Version : 0.90.00
UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
Creation Time : Sun May 30 21:48:55 2010
Raid Level : raid5
Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1
Update Time : Mon Aug 23 11:44:54 2010
State : clean
Active Devices : 1
Working Devices : 2
Failed Devices : 2
Spare Devices : 1
Checksum : 68b48983 - correct
Events : 53210
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 4 8 50 4 spare /dev/sdd2
0 0 0 0 0 removed
1 1 0 0 1 faulty removed
2 2 8 34 2 active sync /dev/sdc2
3 3 0 0 3 faulty removed
4 4 8 50 4 spare /dev/sdd2
Il semble que les choses aient changé depuis le dernier démarrage. Si je lis correctement sda2, sdb2 et sdc2 fonctionnent et contiennent des données synchronisées et sdd2 est de rechange. Je me souviens clairement d'avoir vu 3 disques en panne, mais c'est une bonne nouvelle. Pourtant, le tableau ne fonctionne toujours pas:
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md125 : inactive sda2[0](S) sdb2[1](S) sdc2[2](S)
1875194880 blocks
md126 : inactive sdd2[4](S)
625064960 blocks
md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
64128 blocks [4/4] [UUUU]
unused devices: <none>
md0 semble avoir été renommé md127. md125 et md126 sont très étranges. Ils doivent être un tableau et non deux. Cela s'appelait autrefois md1. md2 a complètement disparu, mais c'était mon échange, donc je m'en fiche.
Je peux comprendre les différents noms et ça n'a pas vraiment d'importance. Mais pourquoi un tableau avec 3 disques de "synchronisation active" est-il illisible? Et que se passe-t-il avec sdd2 dans un tableau séparé?
Mise à jour
J'ai essayé ce qui suit après avoir sauvegardé les superblocs:
root@sysresccd /root % mdadm --stop /dev/md125
mdadm: stopped /dev/md125
root@sysresccd /root % mdadm --stop /dev/md126
mdadm: stopped /dev/md126
Jusqu'ici tout va bien. Puisque sdd2 est disponible, je ne veux pas encore l'ajouter.
root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c}2 missing
mdadm: cannot open device missing: No such file or directory
mdadm: missing has no superblock - assembly aborted
Apparemment, je ne peux pas faire ça.
root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c}2
mdadm: /dev/md1 assembled from 1 drive - not enough to start the array.
root@sysresccd /root % cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : inactive sdc2[2](S) sdb2[1](S) sda2[0](S)
1875194880 blocks
md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
64128 blocks [4/4] [UUUU]
unused devices: <none>
Cela n'a pas fonctionné non plus. Essayons avec tous les disques.
mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c,d}2
mdadm: /dev/md1 assembled from 1 drive and 1 spare - not enough to start the array.
root@sysresccd /root % cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : inactive sdc2[2](S) sdd2[4](S) sdb2[1](S) sda2[0](S)
2500259840 blocks
md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
64128 blocks [4/4] [UUUU]
unused devices: <none>
Pas de chance. Sur la base de cette réponse, je prévois d'essayer:
mdadm --create /dev/md1 --assume-clean --metadata=0.90 --bitmap=/root/bitmapfile --level=5 --raid-devices=4 /dev/sd{a,b,c}2 missing
mdadm --add /dev/md1 /dev/sdd2
Est-ce sûr?
Mise à jour
Je publie le script de l'analyseur de superbloc que j'ai utilisé pour créer ce tableau dans mon commentaire. Peut-être que quelqu'un le trouvera utile. Merci pour votre aide.
la source
mdadm --re-addn'est pas ce que vous cherchez. Avez-vous fait un test de mémoire récemment? Avez-vous un message de journal lié à l'échec de la baie?mdadm -A /dev/md1 /dev/sd{b,c,d}2(peut-être--force)? (Si ce n'est pas le cas, sauvegardez d'abord les superblocs.)/dev/sdd2peut être dans un tableau séparé malgré le même UUID quesd{a,b,c}2.Réponses:
Vérifiez d'abord les disques, essayez d'exécuter l'autotest intelligent
Cela peut prendre quelques heures, mais vérifiez l'état du test de chaque lecteur toutes les quelques minutes, c'est-à-dire
Si l'état d'un disque ne se termine pas en raison d'erreurs de lecture, ce disque doit être considéré comme dangereux pour le réassemblage md1. Après l'autotest, vous pouvez commencer à réassembler votre baie. Facultativement, si vous voulez être extrêmement prudent, déplacez les disques sur une autre machine avant de continuer (juste en cas de mauvais ram / contrôleur / etc).
Récemment, j'ai eu un cas exactement comme celui-ci. Un disque a échoué, j'ai rajouté dans la baie mais pendant la reconstruction, 3 des 4 disques ont échoué. Le contenu de / proc / mdadm était le même que le vôtre (peut-être pas dans le même ordre)
Mais j'ai eu de la chance et j'ai remonté le tableau avec ce
En regardant la sortie --examine que vous avez fournie, je peux dire que le scénario suivant s'est produit: sdd2 a échoué, vous l'avez supprimé et l'ajouté à nouveau, il est donc devenu un disque de rechange essayant de reconstruire. Mais lors de la reconstruction, sda2 a échoué, puis sdb2 a échoué. Le compteur d'événements est donc plus grand dans sdc2 et sdd2 qui sont les derniers disques actifs de la matrice (bien que sdd n'ait pas eu la chance de reconstruire et qu'il soit donc le plus obsolète de tous). En raison des différences dans les compteurs d'événements, --force sera nécessaire. Vous pouvez donc également essayer ceci
Pour conclure, je pense que si la commande ci-dessus échoue, vous devriez essayer de recréer le tableau comme ceci:
Si vous faites cela
--create, lamissingpartie est importante, n'essayez pas d'ajouter un quatrième lecteur dans la matrice, car alors la construction commencera et vous perdrez vos données . La création de la matrice avec un disque manquant ne changera pas son contenu et vous aurez la possibilité d'en obtenir une copie ailleurs (raid5 ne fonctionne pas de la même manière que raid1).Si cela ne parvient pas à mettre le tableau en place, essayez cette solution (script perl) ici Recréer un tableau
Si vous parvenez enfin à mettre le tableau en place, le système de fichiers sera impur et probablement corrompu. Si un disque tombe en panne pendant la reconstruction, il est prévu que la baie s'arrête et se bloque en ne faisant aucune écriture sur les autres disques. Dans ce cas, deux disques ont échoué, peut - être que le système effectuait des demandes d'écriture qui n'ont pas pu se terminer, il y a donc une petite chance que vous ayez perdu des données, mais aussi une chance que vous ne le remarquerez jamais :-)
edit: quelques éclaircissements ajoutés.
la source
mdadm --assemble /dev/md1 /dev/sd[abc]2 --forcetravaillé. Je vous remercie. Vous avez enregistré mes données! :) Je n'essaierai pas d'ajouter le quatrième disque car les 3 premiers ne sont pas aussi bons que je le pensais auparavant. L'autotest révélé a chacun 10 à 20 blocs illisibles. Je me sens stupide de ne pas avoir vérifié cela en premier.--assume-clean(vous l'avez fait), ce ne sera pas le cas.J'ai rencontré de nombreux problèmes lors de mon utilisation
mdadm, mais je n'ai jamais perdu de données. Vous devez éviter cette--forceoption ou l'utiliser avec beaucoup de prudence, car vous risquez de perdre toutes vos données. Veuillez poster votre/etc/mdadm/mdadm.confla source