mdadm raid5 odzyskać awarię podwójnego dysku - z niespodzianką (kolejność dysków)

Pozwolę sobie najpierw przyznać, że popełniłem błędy i że mam kopię zapasową większości danych RAID, ale nie wszystkich . Nadal mam nadzieję na odzyskanie reszty danych. Nie mam pieniędzy, by zabrać dyski do firmy zajmującej się odzyskiwaniem.

Błąd nr 0, brak kopii zapasowej w 100%. Wiem.

Mam mdadmsystem RAID5 4x3 TB. Dyski / dev / sd [be], wszystkie z jedną partycją /dev/sd[b-e]1. Wiem, że RAID5 na bardzo dużych dyskach jest ryzykowny, ale i tak to zrobiłem.

Ostatnie wydarzenia

RAID ulega degradacji po awarii dwóch dysków. Jeden dysk [/ dev / sdc] naprawdę zniknął, drugi [/ dev / sde] wrócił po cyklu zasilania, ale nie został automatycznie ponownie dodany do RAID. Zostałem więc z 4 urządzeniami RAID z tylko 2 aktywnymi dyskami [/ dev / sdb i / dev / sdd].

Błąd nr 1, nieużywanie kopii dysków DD do przywracania RAID. Nie miałem dysków ani czasu. Błąd nr 2, nie tworzenie kopii zapasowej superbloku i mdadm -Epozostałych dysków.

Próba odzyskania

Zmontowałem RAID w trybie zdegradowanym z

mdadm --assemble --force /dev/md0, using /dev/sd[bde]1.

Miałem wtedy dostęp do swoich danych. Zastąpiłem /dev/sdczapasowym; pusty; identyczny napęd.

Usunąłem stary /dev/sdc1z RAID

mdadm --fail /dev/md0 /dev/sdc1

Błąd nr 3, nie robienie tego przed wymianą dysku

Następnie podzieliłem nowy na partycje /dev/sdci dodałem go do RAID.

mdadm --add /dev/md0 /dev/sdc1

Następnie zaczął przywracać RAID. ETA 300 minut. Śledziłem ten proces /proc/mdstatdo 2%, a potem poszedłem zrobić inne rzeczy.

Sprawdzanie wyniku

Kilka godzin (ale mniej niż 300 minut) później sprawdziłem proces. Zatrzymał się z powodu błędu odczytu /dev/sde1.

Tutaj naprawdę zaczynają się kłopoty

Następnie usunąłem /dev/sde1RAID i ponownie go dodałem. Nie pamiętam, dlaczego to zrobiłem; było późno.

mdadm --manage /dev/md0 --remove /dev/sde1
mdadm --manage /dev/md0 --add /dev/sde1

Jednak /dev/sde1teraz oznaczone jako zapasowe. Postanowiłem więc odtworzyć całą tablicę, używając --assume-clean, używając tego, co uważałem za właściwą kolejność, i z /dev/sdc1brakiem.

mdadm --create /dev/md0 --assume-clean -l5 -n4 /dev/sdb1 missing /dev/sdd1 /dev/sde1

To działało, ale system plików nie został rozpoznany podczas próby zamontowania. (Powinien to być EXT4).

Kolejność urządzeń

Następnie sprawdziłem ostatnio utworzoną kopię zapasową /proc/mdstati znalazłem kolejność dysków.

md0 : active raid5 sdb1[0] sde1[4] sdd1[2] sdc1[1]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

Potem przypomniałem sobie, że RAID stracił dysk około rok temu i wyzdrowiałem z niego, zastępując wadliwy dysk zapasowym. To mogło nieco zaszyfrować kolejność urządzeń ... więc nie było napędu [3], ale tylko [0], [1], [2] i [4].

Próbowałem znaleźć kolejność dysków za pomocą skryptu Permute_array: https://raid.wiki.kernel.org/index.php/Permute_array.pl, ale nie znalazłem właściwej kolejności.

pytania

Mam teraz dwa główne pytania:

1. Spieprzyłem wszystkie superbloki na dyskach, ale dałem tylko:

   mdadm --create --assume-clean
   

   polecenia (więc nie powinienem był nadpisywać samych danych /dev/sd[bde]1. Czy mam rację, że teoretycznie RAID można przywrócić [zakładając, że /dev/sde1jest to w porządku], jeśli tylko znajdę odpowiednią kolejność urządzeń?

2. Czy ważne /dev/sde1jest podanie numeru urządzenia [4] w macierzy RAID? Kiedy go tworzę

   mdadm --create /dev/md0 --assume-clean -l5 -n4 \
     /dev/sdb1 missing /dev/sdd1 /dev/sde1
   

   ma przypisany numer [3]. Zastanawiam się, czy ma to znaczenie przy obliczaniu bloków parzystości. Jeśli okaże się to ważne, jak mogę odtworzyć tablicę z /dev/sdb1[0]brakującym [1] /dev/sdd1[2] /dev/sde1[4]? Gdybym mógł to uruchomić, mógłbym uruchomić go w trybie awaryjnym, dodać nowy dysk /dev/sdc1i pozwolić mu ponownie zsynchronizować.

W porządku, jeśli chcesz mi wskazać, że to może nie był najlepszy sposób działania, ale przekonasz się, że zdałem sobie z tego sprawę. Byłoby wspaniale, gdyby ktoś miał jakieś sugestie.

Aby odpowiedzieć na twoje pytania,

1. Czy można to przywrócić?

   • Pierwsza rzecz jest pierwsza - ZATRZYMAJ się, usiądź i pomyśl trochę. Tak, algorytm, wielkość porcji i kolejność dysków są niezbędne do uzyskania dowolnego systemu plików, który był obecny, do prawidłowego ponownego złożenia. Ale skoro nadpisałeś superbloki, masz teraz próbę i błąd.
   • Po drugie, czy jest jakiś sposób na odzyskanie poprzedniego układu dysku? Zawsze robię plik mdadm -detail> backupfile, aby zachować układ dysku w bezpiecznym miejscu. Sprawdź dmesg, / var / log pod kątem wszelkich dowodów na to, jak dyski zostały skonfigurowane podczas nalotu.
   • Wreszcie, jeśli dopasujesz poprzedni rozmiar porcji i kolejność dysków, być może uszkodziłeś superblok ext4 - istnieją sposoby szybkiego skanowania w poszukiwaniu innych superbloków (i istnieje sprytny program o nazwie TestDisk, który skanuje w poszukiwaniu superbloków istniejących systemów plików i próbuje je przeglądać ręcznie: http://www.cgsecurity.org/wiki/Main_Page )

2. Ponieważ sdc jest nowy, kontynuowałbym próbę montażu ręcznie za pomocą brakującej klauzuli, i tak, sde musi być w odpowiedniej kolejności, aby mógł się złożyć w trybie zdegradowanym. Po znalezieniu prawidłowego układu - skopiuj wszystkie dane z tablicy i zacznij od nowa, dokumentując układ (abyś nie napotkał ponownie tego problemu).

Powodzenia

Zanim zrobisz WSZYSTKO, przechwyć „mdadm -examine / dev / sdX1” dla każdego napędu znajdującego się w tablicy i „mdadm --detail / dev / md0”, powinieneś być w stanie określić dokładny układ.

Musiałem to zrobić sam, aby odzyskać tablicę Synology w osobnym pytaniu:

Jak odzyskać macierz mdadm na serwerze Synology NAS z dyskiem w stanie „E”?

Edytuj: Przepraszam, właśnie zobaczyłem, że powiedziałeś, że straciłeś superbloki na wszystkich dyskach.

Twoje późniejsze polecenia WYGLĄDAJ poprawnie. Najprostszą opcją może być uruchomienie kreacji przy każdym możliwym zamówieniu, a następnie sprawdzenie, czy można zamontować i uzyskać dostęp do systemu plików tylko do odczytu.

To pytanie jest stare i jestem pewien, że nikt nie może ci teraz pomóc, ale dla innych osób czytających:

najbardziej niebezpiecznym błędem, jaki popełniłeś, nie jest numer, który miałeś popełnić:

mdadm --create ...

na oryginalnych dyskach, zanim będziesz przygotowany wiedząc, co robić. Spowodowało to zastąpienie metadanych, więc nie masz zapisu kolejności dysków, przesunięcia danych, wielkości porcji itp.

Aby wyjść z tego, musisz ponownie zastąpić je prawidłowymi wartościami. Najprościej jest to sprawdzić na metadanych, ale już to zniszczyłeś. Następnym sposobem jest zgadnięcie. Odgadnij różne kombinacje takiego polecenia, z różnymi wartościami dla dowolnej opcji oprócz tego, co wiesz (4 urządzenia, poziom 5), a także z inną kolejnością dysków:

mdadm --create /dev/md0 --assume-clean --metadata=1.2 --raid-devices=4 --level=5 --layout=... --chunk=512 --data-offset=128M /dev/sdb1 missing /dev/sdd1 /dev/sde1

Ale ponieważ NIE znasz poprawnego wyniku, ponownie nie powinieneś uruchamiać go na starych dyskach, niszcząc je dalej, popełniając ten sam fatalny błąd. Zamiast tego użyj nakładki; na przykład ta procedura powinna działać, aby zapewnić bezpieczeństwo oryginałów.

Po znalezieniu argumentów, które tworzą działającą tablicę, którą można fsck lub zamontować i zweryfikować (np. Sprawdzić sumę kontrolną pliku wystarczająco dużą, aby objąć wszystkie elementy raidu jak iso, którą powinieneś był zapisać wraz z sumą kontrolną / pgp podpis lub rozpakuj -t lub gunzip -ta duże archiwum)