Najważniejsza korekta wynikająca z tego źródła jest taka, że macierz nie pozostała potwierdzoną macierzą RAID z „jednym uszkodzonym dyskiem”. Po uruchomieniu systemu przez użytkownika z każdym dyskiem osobno oba działały indywidualnie. Ponowne podłączenie obu dysków utworzyło [UU] w /proc/mdstat, co oznacza, że w tamtym momencie obaj członkowie RAID 1 byli obecni i zsynchronizowani.
Wątek rozszerzył się następnie o niestabilność SATA/połączenia/zasilania, awarie USB/monitora, uruchamianie w trybie awaryjnym, błędy NFS i przełączanie ZimaOS na drugi slot systemowy. Dane odzyskano, ale źródło nigdy nie potwierdza jednej ostatecznej przyczyny. Nie przedstawiaj tego jako prostego poradnika „wymień dysk X”.
Nie klikaj opcji Rozbij ani Formatuj, gdy odzyskanie danych jest nadal możliwe
Pierwsza rada społeczności była trafna z punktu widzenia bezpieczeństwa: jeśli dane są ważne, a rzeczywisty stan macierzy jest nieznany, destrukcyjne działania w interfejsie mogą utrudnić odzyskiwanie. Najpierw wykonaj kopię zapasową czytelnych danych.
Każdy dysk działał podczas testu osobno
Autor oryginalnego posta odłączał dyski pojedynczo i stwierdził, że każdy z nich zapewniał działającą ścieżkę do systemu/danych. To natychmiast osłabiło założenie, że jeden z dysków uległ fizycznej awarii.
Ponowne podłączenie obu dysków utworzyło sprawną macierz md [UU]
Opublikowany status pokazał md0 : aktywna macierz raid1 ... [2/2] [UU]. W tym momencie warstwa md systemu Linux uznawała obu członków za obecnych.
Dlatego późniejsza dyskusja skupiła się na stabilności kabli, portów SATA, kontrolera, adaptera/backplane’u i zasilania, a nie wyłącznie na metadanych RAID.
Niestabilność SATA/zasilania może maskować awarię RAID
Późniejsze źródło opisało szersze awarie wpływające na działanie SATA, USB i wyświetlacza. Sugestie społeczności obejmowały wymianę kabli SATA, testowanie różnych portów, unikanie zawodnych rozdzielaczy/adapterów oraz testy obciążeniowe z obserwowaniem, czy występują resetowania operacji wejścia/wyjścia.
Była to diagnostyka społeczności, a nie potwierdzona przez IceWhale wada sprzętowa.
Późniejsze problemy z trybem awaryjnym/NFS stanowiły odrębną warstwę
Po zmianie kabli i ponownym uruchomieniu system przeszedł w tryb awaryjny i zgłosił błędy związane z NFS/RPC. Próby społeczności mające na celu wyczyszczenie stanu NFS lub wyłączenie NFS nie doprowadziły do potwierdzonej naprawy.
Nie należy wnioskować, że NFS spowodował pierwotną niedostępność macierzy RAID; pojawił się później w systemie, który już doświadczał szerszej niestabilności.
System również przełączył się na drugi slot ZimaOS
Użytkownik zgłosił uruchomienie systemu z bloku/slota B zamiast A. Obecne wersje ZimaOS używają dwóch slotów systemowych na potrzeby odzyskiwania, więc przełączenie awaryjne może oznaczać, że jeden ze slotów systemowych nie przeszedł kontroli stanu lub uruchamiania, a nie że dane użytkownika na RAID zostały utracone.
Zobacz obecny model odzyskiwania ZimaOS z dwoma slotami.
Obecne wersje ZimaOS mają oficjalny proces naprawy RAID 1
ZimaOS 1.4.4 dodał naprawę RAID1 dla zdegradowanych/uszkodzonych macierzy oraz rozwiązał problem niedostępności wcześniej używanych dysków podczas odzyskiwania.
Przed zastosowaniem starych ręcznych poleceń modyfikujących mdadm użyj oficjalnej funkcji naprawy RAID1.
Metadane RAID są bardziej odporne w nowszych wydaniach ZimaOS
ZimaOS 1.6.0 dodał mechanizm zapisywania metadanych RAID, zaprojektowany do automatycznego ponownego rozpoznawania i montowania oryginalnej macierzy po ponownej instalacji systemu lub wymianie urządzenia. Usprawnia to proces odzyskiwania w porównaniu z okresem, którego dotyczyło źródło, czyli wersją 1.5.x.
Bezpieczniejsza kolejność obecnego procesu odzyskiwania
- Nie formatuj macierzy ani nie rozbijaj jej.
- Zidentyfikuj modele i numery seryjne dysków oraz bieżący stan RAID za pomocą diagnostyki tylko do odczytu.
- Natychmiast wykonaj kopię zapasową dostępnych danych.
- Sprawdź kable, porty, zasilanie, dane SMART oraz dzienniki wejścia/wyjścia i resetów jądra.
- Użyj obecnego interfejsu naprawy RAID, gdy macierz jest rzeczywiście zdegradowana.
- Odzyskiwanie systemu z użyciem slotów należy traktować oddzielnie od odzyskiwania danych RAID.
Wątek dotyczący odzyskiwania ostatecznie dotarł do opcji resetowania/odzyskiwania ZimaOS
Status md [UU] oznacza, że w tym momencie obaj członkowie RAID 1 byli obecni
Po ponownym podłączeniu obu dysków źródło wskazywało, że macierz jest aktywna i ma dwóch członków, a [UU]. Był to mocny dowód na to, że kopia lustrzana została wówczas pomyślnie ponownie złożona.
Nie wyjaśnia to, dlaczego macierz wcześniej wydawała się niedostępna ani dlaczego późniejsze problemy ze stabilnością SATA/USB/monitora nadal występowały.
Diagnostyka tylko do odczytu jest bezpieczniejsza niż ręczne polecenia naprawcze mdadm
Społeczność poprosiła o informacje o macierzy i jej stanie przed zasugerowaniem zmian. To właściwa kolejność: ustal, które urządzenia należą do macierzy, czy jest ona aktywna/zdegradowana oraz co zgłasza jądro, zanim dodasz/usuniesz elementy lub odtworzysz metadane.
Nie kopiuj mdadm --create, wymuszonego montowania lub polecenia czyszczenia superbloku z innego przypadku z systemem Linux do macierzy zawierającej jedyną kopię danych.
Skopiuj ważne dane, gdy tylko macierz stanie się dostępna w trybie odczytu
Użytkownik źródłowy odzyskał dostęp. W tym momencie priorytetem powinno być skopiowanie niezastąpionych danych do niezależnego magazynu, zanim będą kontynuowane eksperymenty z kablami, kontrolerami, gniazdami systemowymi, NFS-em lub reinstalacją.
RAID 1 zapewnia nadmiarowość, ale niestabilny host lub kontroler może sprawić, że oba elementy macierzy staną się jednocześnie niedostępne.
Gdy jednocześnie pojawiają się problemy z SATA, USB i wyświetlaniem, poszerz diagnostykę
Późniejsze objawy nie układały się już w prostą historię awarii jednego dysku. Przerywane wykrywanie SATA, problemy z USB oraz problemy z monitorem/uruchamianiem mogą wskazywać na kable, zasilanie, kontroler, oprogramowanie układowe płyty głównej lub inną niestabilność platformy.
Przed wielokrotnym odbudowywaniem RAID przetestuj sprawne zasilanie i kable oraz uprość konfigurację sprzętową.
Odzyskiwanie gniazda systemowego i odzyskiwanie RAID to odrębne procesy
ZimaOS może uruchamiać się z alternatywnych gniazd systemowych na potrzeby odzyskiwania systemu operacyjnego. Przejście na gniazdo B może naprawić problem z gniazdem systemowym lub go ominąć, ale samo nie naprawia zdegradowanej macierzy.
Skorzystaj z aktualnego modelu odzyskiwania systemu ZimaOS, gdy gniazdo systemu operacyjnego jest również niesprawne.
Odłącz dyski danych podczas reinstalacji systemu operacyjnego, jeśli wymaga tego plan odzyskiwania
Społeczność źródłowa zaleciła odizolowanie dysków RAID podczas czystej reinstalacji systemu, aby zmniejszyć ryzyko wybrania lub zmodyfikowania niewłaściwego dysku. Jeśli obecne wsparcie IceWhale przedstawi plan reinstalacji, najpierw oznacz każdy dysk i zabezpiecz metadane pamięci masowej oraz kopie zapasowe.
Najczęściej zadawane pytania dotyczące odzyskiwania RAID 1
Czy w źródle jednoznacznie stwierdzono, że jeden z dysków jest uszkodzony?
Nie. Oba dyski później działały niezależnie, a macierz wyświetlała [UU] po ponownym podłączeniu.
Czy źródło wskazało jedną ostateczną przyczynę?
Nie. Nakładały się problemy z RAID-em, niestabilnością SATA/zasilania, uruchamianiem NFS i gniazdami systemowymi.
Czy obecny ZimaOS obsługuje naprawę RAID1?
Tak. IceWhale dodało oficjalną procedurę naprawy RAID1 w wersji 1.4.4.
