Jak odzyskać uszkodzoną macierz RAID5 Linuksa?

17

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.

linux  software-raid  data-recovery  raid5 
— stribika
źródło
Chyba mdadm --re-addnie tego szukasz. Czy zrobiłeś ostatnio test pamięci? Czy masz komunikat dziennika związany z awarią tablicy?
— Gilles „SO- przestań być zły”
@Gilles: Nie mam dzienników sprzed awarii, ponieważ były przechowywane w uszkodzonej tablicy. I nie sądzę, żebym mógł to naprawić za pomocą standardowego interfejsu mdadm. Każda operacja, która wymaga ponownej synchronizacji, jest niemożliwa dla 1 z 4 dysków. Myślę, że 3 „nieudane” dyski zawierają wystarczającą ilość informacji, aby przywrócić wszystko. Na przykład mogę je odczytać za pomocą dd. „Dobry” może być niezsynchronizowany. Zrobię memtest, ale ta maszyna działa teraz idealnie z nowym dyskiem.
— stribika 10.03.11
2
Czy próbowałeś zatrzymać tablicę i ponownie złożyć nową za pomocą mdadm -A /dev/md1 /dev/sd{b,c,d}2(być może --force)? (Jeśli nie, najpierw wykonaj kopię zapasową superbloków.)
— Gilles „SO- przestań być zły”
@Gilles: Zaktualizowałem swoje pytanie o aktualne informacje. Czego potrzebuję dokładnie wykonać kopię zapasową? Pierwsze kilka bloków dysków czy jest do tego specjalne narzędzie?
— stribika
@stribika: Superblok jest ostatnim pełnym blokiem 64kB wyrównanym do granicy 64kB na partycji. Nie mam pojęcia, jak /dev/sdd2można znaleźć się w osobnej tablicy, mimo że mam taki sam identyfikator UUID jak sd{a,b,c}2.
— Gilles „SO- przestań być zły”

Odpowiedzi:

12

Najpierw sprawdź dyski, spróbuj uruchomić inteligentny autotest

for i in a b c d; do
    smartctl -s on -t long /dev/sd$i
done

Może to potrwać kilka godzin, ale sprawdzaj status testu każdego dysku co kilka minut, tj

smartctl -l selftest /dev/sda

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)

md1 : inactive sdc2[2](S) sdd2[4](S) sdb2[1](S) sda2[0](S)

Miałem jednak szczęście i dzięki temu zmontowałem tablicę 

mdadm --assemble /dev/md1 --scan --force

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

mdadm --assemble /dev/md1 /dev/sd[abc]2 --force

Podsumowując, myślę, że jeśli powyższe polecenie nie powiedzie się, powinieneś spróbować odtworzyć tablicę w następujący sposób:

mdadm --create /dev/md1 --assume-clean -l5 -n4 -c64 /dev/sd[abc]2 missing

Jeśli to zrobisz --create, missingczęść 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.

— forcefsck
źródło
mdadm --assemble /dev/md1 /dev/sd[abc]2 --forcepracował 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.
— stribika
Dzięki za wyczerpującą odpowiedź. Nagrodzony 50 powtórzeniami ode mnie.
— 0xC0000022L
Permute_array.pl działał dla mnie świetnie. Uwaga dla innych użytkowników: tablica urządzeń, którą spodziewa się zobaczyć, obejmuje wszystkie dyski, w tym wszelkie dyski martwe, które mogły zostać usunięte.
„Jeśli wykonasz -create, brakująca część jest ważna, nie próbuj dodawać czwartego napędu do tablicy, ponieważ wtedy rozpocznie się budowa i stracisz swoje dane.” - BS. Jeśli podałeś --assume-clean(zrobiłeś), nie będzie.
— poige
1

Podczas korzystania napotkałem wiele problemów mdadm, ale nigdy nie straciłem danych. Powinieneś unikać tej --forceopcji lub używać jej bardzo ostrożnie, ponieważ możesz stracić wszystkie swoje dane. Proszę zamieścić/etc/mdadm/mdadm.conf

— Glendyr
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.