Odzysk danych · RAID 6 / SHR-2

Odzyskiwanie danych z RAID 6 i Synology SHR-2

RAID 6 toleruje awarię dwóch dysków, ale ta ochrona kończy się w momencie, gdy rebuild zaczyna pracować na dyskach z błędami, opóźnieniami albo nieaktualnymi metadanymi. Na dużych nośnikach odbudowa potrafi trwać dziesiątki godzin i obciąża każdy pozostały dysk. Przy ważnych danych bezpieczniejszą drogą jest obrazowanie wszystkich członków i rekonstrukcja offline z kopii, a nie eksperymenty na oryginalnej macierzy.

Rekonstrukcja P i Q parity offline
Synology SHR-2, QNAP, ZFS RAIDZ2
Naprawa dysków przed klonowaniem
Rozliczenie po wyniku
RAID 6 jest zdegradowany i zaczął się rebuild? Zatrzymaj go.

Rebuild zdegradowanej macierzy RAID 6 z dużymi dyskami potrafi pogorszyć sytuację, jeśli którykolwiek z pozostałych nośników ma błędy, timeouty albo jest dyskiem nieaktualnym po wcześniejszym wypadnięciu z macierzy. Jeżeli dane są jedyną kopią, najrozsądniej zatrzymać dalsze operacje, zachować kolejność dysków i skonsultować przypadek zanim kontroler zacznie automatycznie przebudowywać lub sprawdzać spójność.
Podstawy

Dual parity - jak RAID 6 różni się od RAID 5

RAID 5 używa jednego bloku parity XOR na każdy stripe - pozwala odtworzyć dane z jednego brakującego dysku. RAID 6 dodaje drugi, niezależny blok parity obliczany innym algorytmem. Dwa niezależne równania pozwalają rozwiązać układ z dwiema niewiadomymi - czyli odtworzyć dane z dwóch brakujących dysków jednocześnie.

Parity P to bitowe XOR wszystkich bloków danych w stripe - ten sam algorytm co RAID 5. Pozwala odtworzyć jeden brakujący blok.

Parity Q to kod korekcji błędów Reed-Solomon obliczany w skończonym polu Galois GF(2^8). Każdy blok danych dostaje inny mnożnik (potęgę elementu generatora), co sprawia że Q jest liniowo niezależne od P. Dwa niezależne równania - dwie niewiadome do rozwiązania.

Oba bloki parity rotują po wszystkich dyskach zamiast siedzieć na dedykowanych dyskach parity. Przy rekonstrukcji offline trzeba precyzyjnie zidentyfikować kierunek rotacji, rozmiar bloku i algorytm Q - błędna identyfikacja daje matematycznie poprawne ale kompletnie nieczytelne dane.

Minimalna liczba dysków: 4 (2 na dane, 2 na parity). Pojemność użytkowa: (N-2) × rozmiar najmniejszego dysku.

Stripe w RAID 6 (4 dyski, left-symmetric)
Stripe 1
D0
D1
P
Q
Stripe 2
D2
P
Q
D3
Stripe 3
P
Q
D4
D5
Po awarii 2 dysków
Stripe 1
dead
dead
P ✓
Q ✓
P i Q razem tworzą układ dwóch równań - wystarczają do rekonstrukcji dwóch brakujących bloków.
RAID 6 vs RAID 5 - co ważne przy odzysku
  • → RAID 5: rekonstrukcja 1 dysku, algorytm XOR
  • → RAID 6: rekonstrukcja 2 dysków, P (XOR) + Q (Reed-Solomon)
  • → Identyfikacja algorytmu Q konieczna do rekonstrukcji
  • → Błędny algorytm Q: dane wyglądają poprawnie ale są uszkodzone
  • → Minimalna macierz: 4 dyski (RAID 5: 3)
Synology

SHR-2 - Synology Hybrid RAID z tolerancją dwóch dysków

W Synology użytkownik bardzo często nie widzi napisu "RAID 6". W panelu DSM pojawia się raczej SHR-2, pula pamięci, Volume Crashed albo informacja o zdegradowanym woluminie. Z punktu widzenia odzysku najważniejsza nie jest nazwa z panelu, tylko układ dysków, metadane mdadm, warstwa LVM oraz system plików.

SHR-2 to Synology Hybrid RAID z tolerancją dwóch dysków. Przy dyskach tej samej pojemności zachowuje się praktycznie jak RAID 6. Przy dyskach różnych pojemności Synology potrafi dzielić przestrzeń na kilka grup i lepiej wykorzystać większe dyski, ale dla odzysku oznacza to dodatkową warstwę logiczną do przeanalizowania.

Typowy stos w Synology SHR-2 wygląda tak: mdadm RAID 6 - LVM - Btrfs albo EXT4. Dlatego przy awarii nie wystarczy "odpalić jeden dysk". Trzeba odtworzyć cały układ, kolejność dysków, warstwy wolumenów i dopiero wtedy analizować system plików.

To jest ważne szczególnie przy zgłoszeniach typu: Synology pokazuje Volume Crashed, pula pamięci uległa awarii, SHR-2 zdegradowany po wymianie dysku, rebuild zatrzymał się w połowie albo NAS przestał widzieć dwa dyski.

SHR-2 w DSM a RAID 6 pod spodem

DSM może pokazywać "SHR (with 2-drive fault tolerance)", ale pod spodem nadal analizujemy metadane mdadm, kolejność członków, LVM i Btrfs/EXT4. Oryginalny NAS pomaga, ale nie jest warunkiem odzysku - kluczowe są dyski i ich kolejność.
SHR vs SHR-2

SHR z tolerancją jednego dysku odpowiada najczęściej układom zbliżonym do RAID 5. SHR-2 daje tolerancję dwóch dysków i jest odpowiednikiem RAID 6. W obu przypadkach po awarii kluczowe jest zatrzymanie rebuildu, zachowanie kolejności dysków i praca na kopiach posektorowych.

Największe zagrożenie

Dlaczego rebuild RAID 6 może być ryzykowny

Rebuild zdegradowanej macierzy RAID 6 wymaga odczytu każdego sektora wszystkich pozostałych dysków pod ciągłym, intensywnym obciążeniem I/O. Przy 6 dyskach po 8 TB to odczyt 40 TB danych po kolei, bez przerwy. Przy 8 TB dyskach na zwykłym sprzęcie - 24 do 48 godzin. Przy 16 TB dyskach - 48 do 72+ godzin.

W tym czasie macierz pracuje w stanie obniżonej tolerancji. Dyski tej samej partii, kupione razem, mające podobną liczbę godzin pracy i identyczne warunki pracy, są szczególnie narażone na ujawnienie słabych sektorów, timeoutów albo awarii mechanicznej właśnie podczas tak intensywnego odczytu.

Jeden URE (unrecoverable read error) na ocalałym dysku podczas rebuildu po jednym padniętym - RAID 6 z Q parity sobie z tym poradzi: drugi blok parity wypełni ten stripe i rebuild idzie dalej. Ale jeśli padnie kolejny dysk mechanicznie podczas rebuildu - macierz ma już zero tolerancji i każdy następny błąd odczytu to utrata danych.

Hot spare nie eliminuje ryzyka rebuildu

Hot spare skraca czas zanim rebuild się zacznie - ale sam rebuild nadal wymaga pełnego odczytu wszystkich dysków pod obciążeniem. Jeśli hot spare uruchomi automatyczny rebuild na macierzy gdzie drugi dysk jest już marginalny, rebuild może go pchnąć za krawędź.
Czas rebuildu i ryzyko URE
6 × 8 TB, jeden padł 24-48h rebuildu
6 × 16 TB, jeden padł 48-72+ h rebuildu
Spec. URE (consumer SATA) 1 błąd / 10¹⁴ bitów
40 TB odczytu przy rebuildu ~3.2 × 10¹⁴ bitów
Dyski enterprise SAS 10× lepsza spec.
Jeden URE podczas rebuildu to nie koniec

Jeśli macierz ma jeden padły dysk i podczas rebuildu trafi na URE na ocalałym - Q parity pokryje ten stripe i rebuild idzie dalej. Eskalacja do poważnej utraty danych następuje gdy drugi dysk pada mechanicznie podczas rebuildu - wtedy brak parity do pokrycia błędów.
Typowe przypadki

Scenariusze awarii RAID 6 - co się stało i co zrobić

Jeden dysk padł - macierz zdegradowana, dane dostępne
Klasyczny przypadek - RAID 6 działa z jednym padłym dyskiem, dane są dostępne bo Q parity kompensuje. Nie spiesz się z rebuildem jeśli nie masz pewności co do stanu pozostałych dysków. Sprawdź SMART wszystkich członków macierzy zanim zdecydujesz o rebuildzie.
Sprawdź SMART. Jeśli inne dyski mają rosnące błędy - zanim rebuild, skontaktuj się z laboratorium.
Dwa dyski padły - macierz offline, brak dostępu
Dwa dyski to maksimum tolerancji RAID 6. Macierz nie działa. Dalsze próby uruchamiania są ryzykowne. Rekonstrukcja offline z kopii posektorowych - każdy dysk osobno, potem wirtualne złożenie macierzy z obliczeniem P i Q parity dla brakujących bloków.
Wyłącz. Nie próbuj rebuildu. Oznacz dyski numerami slotów i skontaktuj się z laboratorium.
Rebuild się uruchomił i zatrzymał w połowie - co teraz?
Rebuild zatrzymany w połowie to stripes które są częściowo zapisane z nową parity, częściowo stare. Każda próba restartu buildu może nadpisać dobre bloki parity rekonstrukcją z niepełnych danych. Natychmiastowe wyłączenie i obrazowanie wszystkich dysków - stan dysków w momencie zatrzymania jest punktem wyjścia do rekonstrukcji.
Wyłącz natychmiast. Nie restartuj rebuildu. Każda sekunda to ryzyko nadpisania poprawnych bloków.
Stale drive wymuszony online - parity przepisane
Dysk wypadł z macierzy i przez jakiś czas nie był synchronizowany. W logach i dokumentacji taki członek bywa określany jako stale. Wymuszenie go online przez Import Foreign Config, storcli force-online albo mdadm --assemble --force może sprawić, że kontroler potraktuje nieaktualne bloki jako poprawne i przeliczy P/Q parity na podstawie mieszaniny starych oraz nowych danych. Parity może potem wyglądać matematycznie spójnie, ale pliki będą niespójne.
Wyłącz zanim kontroler zakończy consistency check. Każdy przejrzany stripe to nadpisane parity.
Dysk SMR wyrzucony podczas rebuildu (WD Red DM-SMR)
Dyski DM-SMR, np. część modeli WD Red EFAX, podczas rebuildu dostają długotrwały ciągły zapis. Wewnętrzne zarządzanie pasmami SMR i przepisywanie stref może nie nadążać, przez co pojawiają się timeouty, bardzo niska wydajność albo błędy typu IDNF. Kontroler może uznać taki dysk za niesprawny i wyrzucić go w trakcie odbudowy, pogarszając stan całej macierzy.
Nie używaj konsumenckich DM-SMR jako replacement, jeśli dane są ważne. Jeśli taki dysk już wypadł w trakcie rebuildu - nie restartuj procesu w ciemno.
Seagate IronWolf SC60 - zdrowy dysk wyrzucony jako wadliwy
Wybrane modele Seagate IronWolf 10 TB i 12 TB z firmware SC60 mają błąd write-cache. Gdy DSM lub TrueNAS wyłącza write cache dla integralności danych (standard), SC60 powoduje poważne spowolnienia I/O i timeouty. Kontroler RAID interpretuje timeout jako awarię i wyrzuca dysk - który fizycznie jest zdrowy. Po podłączeniu do PC-3000 można to zdiagnozować, zidentyfikować buggy firmware i wykonać obraz z pominięciem problematycznej ścieżki.
Sprawdź wersję firmware IronWolf przed założeniem awarii fizycznej.
Ważna różnica

Jednoczesna vs sekwencyjna awaria dwóch dysków

Awaria jednoczesna - zwykle bardziej przewidywalna

Przepięcie, zwarcie backplane albo wspólne zdarzenie może zatrzymać dwa dyski w tym samym momencie logicznym. Jeżeli pozostałe P i Q parity są nadal zsynchronizowane z danymi na ocalałych dyskach, rekonstrukcja jest zwykle bardziej przewidywalna: mamy dwa niezależne równania i dwie niewiadome na stripe. To nadal nie jest "prosty przypadek", bo dochodzi stan fizyczny nośników, system plików i ewentualne błędy odczytu, ale od strony logiki RAID jest to korzystniejszy scenariusz niż stale drive.

Awaria sekwencyjna - poważniejsza

Pierwszy dysk wypada z macierzy. Macierz działa dalej w trybie zdegradowanym, przyjmuje zapisy. Dane pierwszego dysku "zamrażają się" w momencie wypadnięcia. Po jakimś czasie pada drugi dysk. Administrator widzi dwie awarie i próbuje wymusić pierwszy dysk online jako stopgap.

Kontroler akceptuje nieaktualne bloki pierwszego dysku, oblicza od nowa P i Q parity na podstawie mieszaniny aktualnych i przestarzałych danych. Parity jest spójne matematycznie - ale pliki mają stare dane tam gdzie pierwszy dysk był nieaktualny. I ta nieprawidłowa parity jest teraz "poprawna" z punktu widzenia kontrolera.

Po awarii sekwencyjnej nie wymuszaj pierwszego dysku online

Jeśli macierz działała przez jakiś czas bez pierwszego dysku, jego dane są nieaktualne. Wymuszenie go online uruchamia consistency check który "koryguje" aktualną parity do stanu z nieaktualnego dysku. Dane sprzed wypadnięcia są poprawnie odzwierciedlone, ale wszystko co było zapisane po wypadnięciu - przepadło z parity.

Przy odzysku porównujemy event countery w metadanych mdadm, znaczniki czasu transakcji i per-stripe sums parity żeby zidentyfikować które bloki na pierwszym dysku są nieaktualne i wykluczyć je z rekonstrukcji.
Event count w mdadm

mdadm śledzi stan macierzy przez licznik Event Count który inkrementuje się przy każdej zmianie stanu. Dysk który wypadł z macierzy ma niższy event count niż reszta. mdadm normalnie odrzuca dyski z dużo niższym event count. Flaga --force omija tę ochronę. Dlatego fraza mdadm --assemble --force w historii przypadku jest dla nas ważną informacją diagnostyczną, a nie sugestią do samodzielnego testowania na oryginalnych dyskach.

Jak pracujemy

Proces odzysku z RAID 6 krok po kroku

1
Dokumentacja i audyt konfiguracji
Model NAS-a lub kontrolera, liczba dysków, kolejność w slotach, wersja firmware, komunikaty z panelu, historia zdarzeń. Identyfikacja typu macierzy (mdadm, ZFS RAIDZ2, sprzętowy kontroler), parametrów stripe i czy był wykonywany rebuild lub import foreign config.
2
Naprawa dysków z uszkodzeniami fizycznymi
Dyski z awarią głowic, PCB lub silnika wymagają naprawy przed klonowaniem - wymiana głowic w komorze laminarnej, naprawa elektroniki. Celem jest uczynienie dysku czytelnym na tyle żeby ukończyć kopię posektorową.
3
Kopie posektorowe 1:1 każdego dysku
PC-3000 Data Extractor, tryb write-blocked - żaden zapis na oryginał nie jest możliwy. Dyski z błędami odczytu klonowane wieloma przebiegami: czytelne obszary najpierw, potem wielokrotne próby trudnych sektorów. Wszystkie dalsze operacje na kopiach.
4
Wykrywanie parametrów macierzy
Rozmiar stripe, kolejność dysków, kierunek rotacji parity (left-sync, left-async, right-sync, right-async), offset danych. Przy mdadm - odczyt z superbloku. Przy sprzętowych kontrolerach - analiza wzorców w surowych danych. Przy RAID 6: dodatkowo identyfikacja algorytmu Q (generator GF(2^8)) przez porównanie obliczonego Q syndrome z zapisanymi blokami Q na kopiach.
5
Rekonstrukcja wirtualna macierzy offline
Złożenie kopii dysków w wirtualną macierz RAID 6 z wykrytymi parametrami. Walidacja przez sprawdzenie spójności P i Q parity na próbnych stripe'ach i weryfikację że superblock i struktury katalogów systemu plików parsują się poprawnie. Błędy odczytu na kopiach pokrywane przez obliczenie P i Q bez dotykania oryginałów.
6
Analiza systemu plików i ekstrakcja
Montowanie systemu plików na złożonym obrazie (EXT4, Btrfs, XFS, ZFS, NTFS). Przy Synology SHR-2 z LVM - dodatkowa warstwa LVM między mdadm a systemem plików. Przy uszkodzonych metadanych - rekonstrukcja inode, journal replay, file carving po sygnaturach.
7
Weryfikacja i przekazanie
Lista odzyskanych plików i katalogów do akceptacji przed płatnością. Możesz zapytać o konkretne pliki lub katalogi. Płatność po akceptacji wyniku.
Środowiska

RAID 6 w Synology, QNAP, ZFS i na kontrolerach

Synology DSM · SHR-2
mdadm RAID 6 + LVM + Btrfs / EXT4
SHR-2 to mdadm z dual parity i LVM na wierzchu. Parametry macierzy są w superbloku mdadm na każdym dysku - dostępne bez oryginalnego NAS-a. System plików Btrfs ma własne sumy kontrolne bloków, co pomaga przy częściowych uszkodzeniach. EXT4 wymaga rekonstrukcji journal przy awarii zasilania w trakcie zapisu.
QNAP QTS / QuTS hero
mdadm RAID 6 / ZFS RAIDZ2
QTS używa mdadm analogicznie do Synology. QuTS hero (wyższy tier) używa ZFS RAIDZ2 - inaczej niż klasyczny RAID 6: ZFS używa zmiennej szerokości stripe i wbudowanych sum kontrolnych, co komplikuje rekonstrukcję ale ułatwia walidację. Import zdegradowanego poolu ZFS z flagą -f jest ryzykowny.
TrueNAS / FreeNAS
ZFS RAIDZ2
TrueNAS używa ZFS RAIDZ2 - dual parity z checksumami na poziomie bloków. Zdegradowany pool RAIDZ2 nie importuje bez quorum, scrub na uszkodzonym poolu jest ryzykowny. Dane na dyskach są dostępne - rekonstrukcja odbywa się na obrazach posektorowych każdego dysku.
Linux mdadm (standalone)
Software RAID 6
Parametry w superbloku mdadm - chunk size, kolejność dysków, layout i UUID - często da się odczytać bez składania macierzy. Samo mdadm --examine jest inną operacją niż wymuszone składanie przez --force. Przy uszkodzonych superblokach parametry wykrywa się z wzorców danych na kopiach posektorowych. mdadm RAID 6 z Btrfs lub EXT4 to częsty stack serwerów i NAS DIY.
Dell PERC / Broadcom MegaRAID
Sprzętowy RAID 6 - NVRAM + DDF
Konfiguracja w NVRAM kontrolera i w DDF (Disk Data Format) na dyskach. Import Foreign Configuration przy tym samym modelu kontrolera zazwyczaj działa. Przy innym modelu lub producencie - parametry trzeba wykrywać analitycznie. Stale drive w Dell PERC: "Import Foreign Config" z wypadniętym dyskiem = ryzyko backward resync.
HP Smart Array / Adaptec
Sprzętowy RAID 6
HP Smart Array używa własnego formatu metadanych na dyskach. Dyski przeniesione do tego samego modelu kontrolera zazwyczaj rozpoznają się przez Foreign Import. HP i Adaptec stosują własne algorytmy rotacji parity - przy rekonstrukcji na innym kontrolerze lub offline wymagana identyfikacja layout-u.
Unikaj

Czego nie robić po awarii RAID 6

Poniższe działania nie zawsze niszczą dane od razu, ale potrafią mocno pogorszyć sytuację. Największy problem w RAID 6 to nie sama awaria dwóch dysków, tylko późniejszy rebuild, wymuszony import, consistency check albo praca z dyskiem stale.

  • Nie wymuszaj rebuildu zdegradowanej macierzy, jeśli pozostałe dyski mają błędy SMART, timeouty albo niestabilny odczyt
  • Nie importuj Foreign Configuration w ciemno, jeżeli nie wiesz, czy któryś dysk nie był wcześniej stale
  • Nie używaj mdadm --assemble --force na oryginalnych dyskach z niższym event count bez kopii posektorowych
  • Nie restartuj przerwanego rebuildu w ciemno - część stripe'ów może być w stanie pośrednim
  • Nie wkładaj konsumenckich dysków DM-SMR jako zamienników w RAID 6, jeśli dane są ważne
  • Nie uruchamiaj consistency check po wymuszeniu stale drive online - może utrwalić niespójny stan parity
  • Nie inicjalizuj macierzy od nowa na dyskach z danymi
  • Nie wykonuj testów zapisu na oryginalnych dyskach - najpierw kopie, potem rekonstrukcja
Zgłoszenie

Co warto napisać przy awarii RAID 6 / SHR-2

Nie musisz znać wszystkich parametrów macierzy. Wystarczy krótki opis: ile było dysków, jaki był NAS lub kontroler, co stało się przed awarią i jaki komunikat widzisz w panelu. Jeżeli dyski są już wyjęte z obudowy, dobrze jest zachować ich kolejność albo oznaczyć numery slotów.

Pomocne są zdjęcia ekranu z DSM/QTS/iDRAC/WebBIOS, komunikaty typu Volume Crashed, Degraded, Foreign Configuration, informacja o przerwanym rebuildzie albo o użyciu mdadm --force. Jeżeli tego nie masz, to nie problem - większość parametrów można ustalić podczas diagnozy na kopiach posektorowych.

Najważniejsze minimum: nie mieszaj dysków między slotami, nie inicjalizuj macierzy od nowa i nie uruchamiaj kolejnego rebuildu, jeśli dane są jedyną kopią. Resztę da się ustalić w rozmowie lub podczas diagnozy.
Wycena

Jak wyceniamy odzysk z RAID 6 i SHR-2

Nie podaję tutaj sztywnej ceny, bo RAID 6 może oznaczać kilka zupełnie różnych przypadków: prostą utratę konfiguracji, dwa dyski z błędami odczytu, przerwany rebuild, stale drive po wymuszonym imporcie albo kilka nośników wymagających naprawy przed klonowaniem.

Wycena zależy głównie od liczby dysków, stanu każdego nośnika, typu kontrolera lub NAS-a, systemu plików oraz historii zdarzeń: rebuild, hot spare, Foreign Config, consistency check, mdadm --force, wymiana dysku albo migracja między urządzeniami.

Najpierw wykonujemy diagnozę i ustalamy, czy dane można złożyć z kopii posektorowych. Po diagnozie dostajesz konkretną wycenę oraz informację, jaki zakres odzysku jest realny. Aktualne zasady diagnozy i rozliczeń są w cenniku oraz formularzu zgłoszenia.

Najczęstsze pytania

FAQ - RAID 6 i SHR-2

RAID 6 toleruje awarię dwóch dysków. Problem zaczyna się wtedy, gdy podczas rebuildu pojawiają się kolejne błędy odczytu, timeouty albo trzeci dysk zaczyna fizycznie odmawiać pracy. Przy dużych dyskach największym ryzykiem jest długie obciążenie pozostałych nośników i praca na członkach, które mogły wypaść z macierzy w różnym czasie.
Dla użytkownika Synology SHR-2 to wygodna nazwa w DSM. Pod spodem najczęściej pracujemy z mdadm RAID 6, LVM i Btrfs albo EXT4. Przy dyskach tej samej pojemności SHR-2 zachowuje się praktycznie jak RAID 6. Przy różnych pojemnościach dochodzi dodatkowa warstwa przydziału przestrzeni, którą trzeba uwzględnić przy rekonstrukcji.
Jeśli masz kopię zapasową danych - możesz ryzykować rebuild. Jeśli danych nie ma nigdzie indziej - nie zalecam. Rebuild zdegradowanej macierzy z dużymi dyskami to 24-72 godziny ciągłego obciążenia I/O, a dyski tej samej partii mają podwyższone ryzyko awarii właśnie podczas tak intensywnego odczytu. Skontaktuj się zanim zdecydujesz.
Stale drive to dysk, który wypadł z macierzy i przez jakiś czas nie przyjmował zapisów. Jego event count albo metadane są starsze niż w pozostałych członkach. Wymuszenie go online przez Import Foreign Config, storcli force-online albo mdadm --assemble --force może spowodować, że macierz zacznie przeliczać parity na podstawie nieaktualnych bloków. Dane mogą wtedy wyglądać logicznie spójnie, ale zawierać stare fragmenty.
Volume Crashed po utracie dwóch dysków to utrata tolerancji RAID 6 - macierz nie montuje się bez rekonstrukcji. Dane na pozostałych dyskach są nienaruszone. Rekonstrukcja offline z kopii posektorowych, identyfikacja parametrów z superbloku mdadm, złożenie wirtualnej macierzy i wyciągnięcie danych z Btrfs lub EXT4. Powodzenie zależy od stanu fizycznego ocalałych dysków.
Nie polecam używania konsumenckich DM-SMR jako zamienników w RAID 6, jeżeli dane są ważne. Podczas rebuildu taki dysk dostaje długi ciągły zapis, a jego wewnętrzne przepisywanie pasm SMR może powodować bardzo duże opóźnienia. Kontroler może uznać to za awarię i wyrzucić dysk. Dotyczyło to m.in. części modeli WD Red EFAX, np. WD40EFAX, WD60EFAX i WD20EFAX.
Rekonstrukcja offline to proces w którym każdy dysk jest obrazowany osobno przez kanał write-blocked, a wirtualna macierz jest składana z kopii - bez dotykania oryginałów. Błąd odczytu na kopii można obsłużyć wielokrotnym odczytem, pominięciem sektora lub obliczeniem z P i Q parity - bez ryzyka kolejnej awarii sprzętowej. Rebuild in-place wymaga od kontrolera odczytu każdego sektora wszystkich dysków pod obciążeniem na oryginalnym sprzęcie.
Nie dokładnie. Obydwa tolerują awarię dwóch dysków, ale implementacja jest różna. RAIDZ2 używa zmiennej szerokości stripe (każdy stripe może mieć inną szerokość zależnie od rozmiaru zapisu) i wbudowanych sum kontrolnych na poziomie każdego bloku. Klasyczny RAID 6 (mdadm) ma stały stripe i nie ma sum kontrolnych - musi ufać temu co dysk zwraca. RAIDZ2 jest trudniejszy do rekonstrukcji offline, ale sumy kontrolne ułatwiają walidację poprawności odzysku.
Czasem tak, ale dużo zależy od tego, który dysk był stale, czy system plików został zamontowany do zapisu i czy po wymuszeniu ruszył rebuild albo consistency check. Sama informacja, że było użyte mdadm --assemble --force, jest cenna diagnostycznie. Najlepiej nie wykonywać kolejnych prób na oryginalnych dyskach i od razu przejść do kopii posektorowych.
Tak, w wielu przypadkach oryginalny NAS nie jest konieczny. Najważniejsze są dyski, ich kolejność oraz stan metadanych mdadm/LVM i systemu plików. Oryginalne urządzenie lub zrzuty ekranu z DSM mogą przyspieszyć diagnozę, ale rekonstrukcję wykonuje się z kopii posektorowych dysków.
Wystarczy: liczba dysków, model NAS-a lub kontrolera, komunikat błędu, czy był rebuild, wymiana dysku, hot spare, Foreign Configuration, consistency check albo mdadm --force. Jeśli dyski są wyjęte, warto zachować kolejność slotów. Nie musisz znać stripe size, layoutu ani algorytmu Q - to ustala się podczas diagnozy.

Zobacz też

RAID 6 lub SHR-2 nie działa?

Opisz ile dysków padło, jaki NAS lub kontroler, czy był rebuild lub import foreign config. Odpiszę z oceną sytuacji - zazwyczaj tego samego dnia.

Zadzwoń Wyślij nośnik