Jakiś czas temu miałem w domu system RAID5. Jeden z 4 dysków zawiódł, ale po wyjęciu i ponownym włożeniu go wydawało się, że jest OK, więc rozpocząłem ponowną synchronizację. Kiedy się skończyło, ku mojemu przerażeniu zdałem sobie sprawę, że 3 na 4 dyski zawiodły. Jednak nie wierzę, że to możliwe. Na dyskach znajduje się wiele partycji, a każda część innej macierzy RAID.
- md0 jest macierzą RAID1 złożoną z sda1, sdb1, sdc1 i sdd1.
- md1 jest macierzą RAID5 złożoną z sda2, sdb2, sdc2 i sdd2.
- md2 to macierz RAID0 złożona z sda3, sdb3, sdc3 i sdd3.
md0 i md2 zgłasza wszystkie dyski w górę, a md1 raporty 3 nie powiodły się (sdb2, sdc2, sdd2). Zrozumiałem, że w przypadku awarii dysków twardych wszystkie partycje powinny zostać utracone, a nie tylko środkowe.
W tym momencie wyłączyłem komputer i odłączyłem dyski. Od tego czasu korzystałem z tego komputera z nowym, mniejszym dyskiem.
Czy jest jakaś nadzieja na odzyskanie danych? Czy mogę jakoś przekonać mdadm, że moje dyski faktycznie działają? Jedynym dyskiem, który może naprawdę mieć problem, jest sdc, ale ten jeden jest zgłaszany przez inne tablice.
Aktualizacja
W końcu miałem okazję podłączyć stare dyski i uruchomić tę maszynę z SystemRescueCd. Wszystko powyżej zostało zapisane z pamięci. Teraz mam twarde dane. Oto wynik działaniamdadm --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
Wygląda na to, że wszystko się zmieniło od ostatniego uruchomienia. Jeśli czytam to poprawnie, sda2, sdb2 i sdc2 działają i zawierają zsynchronizowane dane, a sdd2 jest zapasowy. Wyraźnie pamiętam 3 nieudane dyski, ale to dobra wiadomość. Jednak tablica nadal nie działa:
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>
Nazwa md0 wydaje się być przemianowana na md127. md125 i md126 są bardzo dziwne. Powinny być jedną tablicą, a nie dwiema. Kiedyś nazywało się to md1. md2 już nie ma, ale to była moja zamiana, więc mnie to nie obchodzi.
Rozumiem różne nazwy i to naprawdę nie ma znaczenia. Ale dlaczego tablica z 3 dyskami z „aktywną synchronizacją” jest nieczytelna? A co jest z tym, że sdd2 jest w osobnej tablicy?
Aktualizacja
Po utworzeniu kopii zapasowej superbloków próbowałem:
root@sysresccd /root % mdadm --stop /dev/md125
mdadm: stopped /dev/md125
root@sysresccd /root % mdadm --stop /dev/md126
mdadm: stopped /dev/md126
Jak na razie dobrze. Ponieważ sdd2 jest zapasowy, nie chcę go jeszcze dodawać.
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
Najwyraźniej nie mogę tego zrobić.
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>
To też nie działało. Spróbujmy ze wszystkimi dyskami.
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>
Brak szczęścia. Na podstawie tej odpowiedzi planuję spróbować:
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
Czy to jest bezpieczne?
Aktualizacja
Publikuję skrypt parsera superbloku, którego użyłem do stworzenia tej tabeli w moim komentarzu. Może ktoś uzna to za przydatne. Dziękuję za twoją pomoc.
źródło
mdadm --re-add
nie tego szukasz. Czy zrobiłeś ostatnio test pamięci? Czy masz komunikat dziennika związany z awarią tablicy?mdadm -A /dev/md1 /dev/sd{b,c,d}2
(być może--force
)? (Jeśli nie, najpierw wykonaj kopię zapasową superbloków.)/dev/sdd2
można znaleźć się w osobnej tablicy, mimo że mam taki sam identyfikator UUID jaksd{a,b,c}2
.Odpowiedzi:
Najpierw sprawdź dyski, spróbuj uruchomić inteligentny autotest
Może to potrwać kilka godzin, ale sprawdzaj status testu każdego dysku co kilka minut, tj
Jeśli status dysku zgłasza, że nie został ukończony z powodu błędów odczytu, dysk ten należy uznać za niebezpieczny dla ponownego złożenia md1. Po zakończeniu autotestu możesz rozpocząć próbę ponownego złożenia tablicy. Opcjonalnie, jeśli chcesz zachować szczególną ostrożność, przenieś dyski na inną maszynę przed kontynuowaniem (na wypadek złego RAM / kontrolera / itp.).
Ostatnio miałem przypadek dokładnie taki jak ten. Jeden dysk się nie powiódł, ponownie dodałem do tablicy, ale podczas przebudowy 3 z 4 dysków uległo awarii. Zawartość / proc / mdadm była taka sama jak twoja (być może nie w tej samej kolejności)
Miałem jednak szczęście i dzięki temu zmontowałem tablicę
Patrząc na dostarczone przez ciebie wyjście --examine, mogę stwierdzić, że wydarzyło się następujący scenariusz: sdd2 nie powiódł się, usunąłeś go i dodałeś ponownie, więc stał się on dyskiem zapasowym, który próbuje się odbudować. Ale podczas przebudowy sda2 nie powiodło się, a następnie sdb2 nie powiodło się. Tak więc licznik zdarzeń jest większy w sdc2 i sdd2, które są ostatnimi aktywnymi dyskami w macierzy (chociaż sdd nie miał szansy na przebudowę, więc jest najbardziej przestarzały ze wszystkich). Z powodu różnic w licznikach zdarzeń konieczne będzie użycie --force. Możesz także spróbować tego
Podsumowując, myślę, że jeśli powyższe polecenie nie powiedzie się, powinieneś spróbować odtworzyć tablicę w następujący sposób:
Jeśli to zrobisz
--create
,missing
część jest ważna, nie próbuj dodawać czwartego dysku do tablicy, ponieważ wtedy rozpocznie się budowa i stracisz dane . Utworzenie tablicy z brakującym dyskiem nie zmieni jej zawartości i będziesz mieć szansę na uzyskanie kopii w innym miejscu (raid5 nie działa tak samo jak raid1).Jeśli to nie przywołuje tablicy, wypróbuj to rozwiązanie (skrypt perla) tutaj Odtwarzanie tablicy
Jeśli w końcu uda Ci się przywołać tablicę, system plików będzie nieczysty i prawdopodobnie uszkodzony. Jeśli jeden dysk ulegnie awarii podczas przebudowy, oczekuje się, że tablica zatrzyma się i zawiesi nie dokonując żadnych zapisów na innych dyskach. W tym przypadku dwa dyski uległy awarii, być może system wykonywał żądania zapisu, których nie udało się ukończyć, więc istnieje niewielka szansa na utratę części danych, ale także szansa, że nigdy tego nie zauważysz :-)
edycja: dodano pewne wyjaśnienia.
źródło
mdadm --assemble /dev/md1 /dev/sd[abc]2 --force
pracował Dziękuję Ci. Zapisałeś moje dane! :) Nie będę próbował dodawać czwartego dysku, ponieważ pierwsze 3 nie są tak dobre, jak wcześniej myślałem. Każdy z autotestu ma 10-20 nieczytelnych bloków. Czuję się głupio, że najpierw tego nie sprawdziłem.--assume-clean
(zrobiłeś), nie będzie.Podczas korzystania napotkałem wiele problemów
mdadm
, ale nigdy nie straciłem danych. Powinieneś unikać tej--force
opcji lub używać jej bardzo ostrożnie, ponieważ możesz stracić wszystkie swoje dane. Proszę zamieścić/etc/mdadm/mdadm.conf
źródło