Co się dzieje podczas rebuildu zdegradowanego RAID 5
Gdy jeden dysk pada w RAID 5, macierz wchodzi w tryb zdegradowany. Dane są nadal dostępne - kontroler oblicza brakujące dane z pozostałych dysków i parity przy każdym odczycie. Macierz działa, ale bez redundancji: każdy kolejny błąd to utrata całości.
Rebuild to próba odtworzenia danych brakującego dysku na nowym nośniku. Kontroler musi odczytać każdy sektor każdego ocalałego dysku, wyliczyć XOR parity i zapisać wynik na nowym dysku. Przy 4-dyskowym RAID 5 z dyskami 16 TB - to odczyt 48 TB danych pod ciągłym, maksymalnym obciążeniem I/O. Na nowoczesnych dużych dyskach taki rebuild trwa 24 do 72 godzin.
Przez cały ten czas macierz ma zero tolerancji na kolejną awarię. Jeden błąd odczytu na jednym z ocalałych dysków, jeden dysk wyrzucony przez kontroler z powodu timeout - i macierz przechodzi z "degraded" w "failed". Dane z każdego stripe który w tym momencie był rekonstruowany są bezpowrotnie utracone.
RAID 5 był projektowany w epoce dysków mierzonych w gigabajtach. Przy dyskach 8, 12, 16 TB wolumen odczytu podczas rebuildu regularnie przekracza progi URE dla consumer dysków. RAID 6 (dual parity) lub RAID 10 (mirror) są właściwymi konfiguracjami dla dużych dysków jeśli zależy nam na przeżyciu rebuildu.
URE - nieczytelne sektory które czekają na rebuild
Każdy dysk twardy ma specyfikację URE (Unrecoverable Read Error) - statystyczną górną granicę prawdopodobieństwa wystąpienia sektora którego nie można odczytać mimo prób korekcji ECC.
Consumer SATA (WD Blue, Seagate Barracuda, Toshiba P300): 1 URE na 10¹⁴ bitów, czyli ok. 12,5 TB. Enterprise SAS (WD Ultrastar, Seagate Exos): 1 URE na 10¹⁵ bitów, czyli ok. 125 TB - dziesięć razy lepiej.
To są górne granice spec, nie harmonogram. Większość dysków przechodzi przez 12,5 TB bez jednego URE. Błędy skupiają się na starych, marginalnych dyskach - nie rozkładają się równomiernie. Ale przy rebuildie zdegradowanego RAID 5 na dużych dyskach statystyka działa przeciwko nam.
| Pojemność dysku | Odczyt przy rebuildie (4-dysk RAID 5) | Oczekiwane URE (consumer spec) | Oczekiwane URE (enterprise spec) |
|---|---|---|---|
| 4 TB | 12 TB | ~1.0 | ~0.1 |
| 8 TB | 24 TB | ~1.9 | ~0.2 |
| 16 TB | 48 TB | ~3.8 | ~0.4 |
| 20 TB | 60 TB | ~4.8 | ~0.5 |
Wartości to górne granice spec - nie gwarantowane liczby. W praktyce większość dysków nie trafia w te progi. Ale przy starzejących się dyskach z tej samej partii obciążonych rebuild I/O ryzyko mechanicznej awarii jest realniejszym zagrożeniem niż czyste statystyki URE.
Jeśli URE trafi podczas rebuildu zdegradowanego RAID 5 - kontroler nie może zrekonstruować tego stripe bo brakuje dwóch źródeł jednocześnie (brakujący dysk + nieczytelny sektor na ocalałym). Dane z tego stripe są utracone. Co dzieje się z resztą macierzy zależy od kontrolera:
- Dell PERC, LSI MegaRAID (nowoczesne): "puncture" - oznacza stripe jako nieodwracalnie uszkodzony i kontynuuje rebuild. Macierz wchodzi online z jednym uszkodzonym strefą.
- HP Smart Array P-series, starsze kontrolery: abort - przerywa rebuild i loguje POST Error 1784 lub 1786. Volume offline.
- Linux mdadm: zapisuje nieczytelne LBA do Bad Block Log i kontynuuje.
- Consumer NAS (Synology, QNAP), Intel RST: abort - przerywa rebuild i wyświetla "Volume Crashed".
W żadnym z tych przypadków to nie jest dobry wynik. Ale abort jest szczególnie podstępny - zostawia macierz w mieszanym stanie parity.
Mieszany stan parity - najgorszy scenariusz po przerwanym rebuildie
Gdy rebuild jest przerywany w połowie, kontroler zapisał już nową parity do niektórych stripe'ów, a inne mają jeszcze starą parity sprzed rebuildu. Macierz jest teraz w stanie mieszanym - część stripe'ów ma parity obliczone z nowym dyskiem, część ma parity sprzed jego pojawienia.
Jeśli teraz wymusisz macierz online (Force Online, Force Import, Set Foreign Config Good) - kontroler prezentuje wolumin gdzie mniej więcej 40% stripe'ów (te zrebuildowane) ma matematycznie inną parity niż pozostałe 60%. Pliki które zajmują stripe'y po obu stronach tej granicy są uszkodzone. Volume może się zamontować, system nie raportuje błędów, ale dane są cicho uszkodzone.
Każda operacja na mieszanym stanie parity poszerza uszkodzenia. fsck, chkdsk, xfs_repair na uszkodzonej macierzy interpretuje niespójność parity jako uszkodzenie systemu plików i usuwa katalogi albo skraca pliki. Drugi rebuild powtarza pełne obciążenie I/O na dyskach które właśnie właśnie wykazały problemy. Wyłącz i nie dotykaj.
Rebuild zatrzymał się na 30%, 90%, 95% albo 99%
Jeśli rebuild RAID zatrzymuje się zawsze w podobnym miejscu, procent zwykle nie jest przypadkowy. Kontroler dochodzi do konkretnego zakresu LBA na jednym z pozostałych dysków i trafia na fragment, którego nie potrafi stabilnie odczytać. Może to być pasmo bad sektorów, słabnąca głowica, timeout dysku bez TLER albo problem z dyskiem SMR użytym jako zamiennik.
Rebuild zatrzymany na 30% oznacza, że problem pojawił się mniej więcej w pierwszej części przestrzeni adresowej. Rebuild zatrzymany na 90%, 95% lub 99% najczęściej oznacza, że kontroler doszedł prawie do końca zakresu i dopiero tam trafił na problematyczny obszar. To nadal jest awaria, nie "prawie sukces".
Ponowne uruchomienie rebuildu zwykle nie naprawia sytuacji. Kontroler ponownie przejdzie przez te same sektory, ponownie obciąży wszystkie dyski i może doprowadzić do kolejnego wyrzucenia dysku z macierzy. Jeśli dane są ważne, bezpieczniejsza ścieżka to kopie posektorowe członków macierzy i rekonstrukcja wirtualna z obrazów.
RAID 5 startuje rebuild po wymianie jednego dysku. Proces dochodzi do 95% i zatrzymuje się z błędem odczytu na innym dysku. To nie znaczy, że odzyskano 95% danych. Oznacza to, że macierz została częściowo przebudowana, część parity może być już zapisana w nowym stanie, a końcówka woluminu może zawierać sektory, których kontroler nie potrafi odczytać.
TLER, ERC, CCTL - dlaczego consumer dyski są wyrzucane z RAID
Kontrolery RAID oczekują, że dysk odpowie w ciągu kilku sekund. Dell PERC ma timeout 8-20 sekund. LSI MegaRAID podobnie. Jeśli dysk nie odpowie w tym oknie - kontroler uznaje go za padły i wyrzuca z macierzy.
Consumer dyski (WD Blue, Seagate Barracuda, Toshiba P300) nie mają TLER (Time-Limited Error Recovery). Gdy natrafiają na zły sektor, wchodzą w wewnętrzną pętlę retry która może trwać 30 sekund do 2 minut. Dysk jest fizycznie sprawny i aktywnie próbuje odczytać sektor. Ale kontroler czeka 8-20 sekund, traci cierpliwość, reset busu i wyrzuca sprawny dysk z macierzy. Rebuild się kończy, macierz "failed" - a dysk, który to spowodował był w doskonałym stanie fizycznym.
NAS-grade i enterprise dyski mają TLER/ERC/CCTL który limituje wewnętrzne retry do ok. 7 sekund. Jeśli sektor jest nieczytelny w tym oknie - dysk raportuje błąd natychmiast. Kontroler może wtedy użyć parity do rekonstrukcji brakującego bloku i kontynuować rebuild bez wyrzucania dysku.
smartctl -l scterc /dev/sdX - odczyt aktualnego TLER w decysekundach
smartctl -l scterc,70,70 /dev/sdX - ustawienie 7-sekundowego limitu (na dyskach które to obsługują)
echo 180 > /sys/block/sdX/device/timeout - wydłużenie timeout Linux block layer do 180s (workaround dla consumer dysków bez TLER w mdadm)
Dyski SMR - duże ryzyko wyrzucenia podczas rebuildu
Drive-Managed SMR (DM-SMR) to osobna klasa problemu. Dyski SMR zapisują dane w nakładających się ścieżkach (shingled tracks) i mają małą strefę CMR jako write cache. Gdy ta strefa się zapełni, dysk musi zatrzymać I/O, żeby przepisać nagromadzone dane do stref SMR. Taka pauza może trwać kilka lub kilkanaście sekund.
Rebuild RAID to długotrwałe sekwencyjne zapisy na nowy dysk. Jeśli dyskiem zastępczym jest DM-SMR, istnieje spore prawdopodobieństwo, że podczas rebuildu zapełni się jego cache i dysk zacznie wykonywać wewnętrzne przepisywanie stref. Kontroler z timeoutem 7-20 sekund może zobaczyć ciszę, uznać ją za awarię i wyrzucić dysk z macierzy.
To nie oznacza, że każdy dysk SMR zawsze wypadnie w każdej konfiguracji. Oznacza natomiast, że przy ważnych danych i dużej macierzy użycie DM-SMR jako replacement jest bardzo złym pomysłem - szczególnie w RAID 5, RAID 6, SHR-1 i SHR-2.
WD20EFAX (2 TB) · WD40EFAX (4 TB) · WD60EFAX (6 TB)
Seagate Barracuda: ST2000DM008, ST4000DM004
Toshiba L200, P300
Bezpieczne alternatywy CMR: WD Red Plus, WD Red Pro, WD Gold, Seagate IronWolf, Seagate IronWolf Pro, Toshiba N300.
Stale drive i import Foreign Configuration
Dysk, który wypadł z macierzy staje się "stale" - jego dane zatrzymały się w momencie wypadnięcia, a macierz dalej przyjmowała zapisy bez niego. Każdy zapis który trafił na macierz po wypadnięciu dysku nie istnieje na tym dysku.
Jeśli później wstawisz ten dysk z powrotem i kontroler zaproponuje "Import Foreign Configuration" (Dell PERC), "Force Online" (MegaRAID) lub mdadm --assemble --force (Linux) - kontroler potraktuje nieaktualne bloki tego dysku jako autorytatywne i przeliczy parity P i Q na podstawie mieszaniny aktualnych i nieaktualnych danych. Parity będzie matematycznie spójne. Consistency check nie wykryje błędów. Ale dane na stripe'ach gdzie stale dysk miał nieaktualne bloki będą uszkodzone - zawierając wartości sprzed jego wypadnięcia.
Ta korupcja jest cicha. Volume się montuje, pliki są widoczne, system nie raportuje błędów. Uszkodzenia wychodzą dopiero wtedy, gdy konkretny plik jest otwierany - czasem tygodnie lub miesiące po zdarzeniu.
Zrób zdjęcie ekranu BIOS-a z informacją o Foreign Config. Wyłącz serwer. Nie klikaj Import, Clear ani Force - dopóki nie masz kopii posektorowych wszystkich dysków lub nie skonsultujesz z laboratorium. Raz zaakceptowany Import nie jest odwracalny.
Write hole - niespójność parity po awarii zasilania
Zapis w RAID 5 dotyczy każdego dysku w stripe: nowe dane i nowa parity. Jeśli zasilanie zgaśnie między zapisem danych a zapisem nowej parity - stripe zostaje z nowym danymi i starą parity. Lub z nową parity i starymi danymi. Kontroler nie wie który blok jest aktualny.
Kontrolery enterprise z battery-backed write cache (BBWC) lub flash-backed write cache (FBWC) obsługują to: cache przeżywa utratę zasilania, kontroler odtwarza zapisy przy następnym uruchomieniu. Consumer NAS (Synology, QNAP, Buffalo) nie mają BBWC - ich ochrona write hole polega na journalingu systemu plików (EXT4, Btrfs) który nie pokrywa bloków parity.
Gdy write-hole stripe jest odczytywany podczas rebuildu - parity nie zgadza się z danymi. Kontroler oblicza brakujący blok z niespójnych wejść i produkuje bzdury. Te bzdury trafiają na nowy dysk jako część rebuildu. Rebuild kończy się bez błędów - ale konkretne pliki są cicho uszkodzone.
Synology i QNAP - przycisk "Napraw" nie zawsze jest bezpieczny
W serwerach Synology i QNAP odbudowa macierzy często wygląda jak prosty przycisk w panelu: "Repair", "Napraw", "Rebuild", "Recover" albo komunikat o wymianie dysku. Problem polega na tym, że pod spodem nadal działa zwykły mechanizm RAID: mdadm, LVM, Btrfs, EXT4, czasem SHR-1 lub SHR-2. Panel upraszcza opis, ale nie zmienia ryzyka zapisu na dyskach.
Jeśli widzisz "Volume Crashed", "Storage Pool Degraded", "Pula pamięci uległa awarii", "Failed", "Repair" albo QNAP proponuje inicjalizację puli, nie zakładaj, że to tylko kosmetyczna naprawa konfiguracji. Taki przycisk może uruchomić rebuild, resync, zmianę superbloków mdadm, zapis metadanych LVM albo próbę naprawy systemu plików na niestabilnym obrazie macierzy.
Przed kliknięciem warto ustalić: który dysk wypadł pierwszy, czy wymieniono dysk na nowy, czy rebuild już się rozpoczął, czy w panelu był komunikat o bad sectorach i czy macierz używa SHR-1, SHR-2, RAID 5, RAID 6 lub RAID 10. Jeśli nie wiesz - to normalne. W takiej sytuacji lepiej zachować kolejność dysków i zrobić diagnozę, niż klikać kolejne opcje w panelu NAS.
To panele do zarządzania działającą macierzą. Gdy macierz jest niespójna, ma błędy odczytu albo rebuild już się nie udał, automatyczna naprawa może pogorszyć stan danych. Najpierw kopie dysków, potem rekonstrukcja.
Co zamiast rebuildu - bezpieczna ścieżka
Bezpieczna ścieżka zawsze zaczyna się od kopii posektorowych każdego dysku z osobna - zanim cokolwiek innego.
Krok 1: Kopia posektorowa każdego dysku
PC-3000 Data Extractor w trybie write-blocked, lub ddrescue z mapfile na Linuxie. Dyski z błędami odczytu klonowane wieloma przebiegami: najpierw czytelne sektory, potem próby trudnych. Mapfile rejestruje stan każdego sektora - jeśli dysk pada w trakcie, kolejna próba wznawia od miejsca przerwania.
Komenda ddrescue dla słabego dysku: ddrescue -d -n -r0 /dev/sdX image.bin map.log
Najpierw bulk pass bez scrapingu (-n), potem scraping: ddrescue -d -r3 /dev/sdX image.bin map.log
Krok 2: Wirtualna rekonstrukcja macierzy z kopii
Kopie dysków są importowane do oprogramowania DR (PC-3000 Data Extractor RAID Edition, R-Studio, UFS Explorer) i macierz jest składana wirtualnie. Można próbować różnych parametrów (chunk size, rotacja parity, kolejność dysków) bez ryzyka nadpisania czegokolwiek. Zła próba - po prostu próbujemy inaczej. Na oryginalnych dyskach nie ma żadnych zapisów.
Co daje wirtualna rekonstrukcja vs rebuild in-place
- ✓ Oryginalne dyski nigdy nie są zapisywane - stan jest zamrożony przy przyjęciu
- ✓ Błąd odczytu na kopii = powtórny odczyt lub pominięcie bez konsekwencji
- ✓ Zła kombinacja parametrów = po prostu próba z innymi ustawieniami
- ✓ Stale drive można zidentyfikować i wykluczyć z rekonstrukcji przed złożeniem
- ✓ Mieszany stan parity po przerwanym rebuildie można obsłużyć per-stripe
- ✗ Rebuild in-place: każdy błąd jest nieodwracalny, każde złe ustawienie niszczy dane
Komendy, które niszczą macierz - lista zakazana
Po nieudanym rebuildie lub padniętej macierzy poniższe komendy i operacje pojawiają się na forach i w bazach wiedzy producentów jako "jak naprawić". Każda z nich pisze na dyski i może definitywnie zniszczyć dane.
Dlaczego różne kontrolery RAID zachowują się inaczej?
Ten sam problem może wyglądać inaczej zależnie od kontrolera i systemu. Dell PERC i LSI MegaRAID mogą pokazać "Foreign Configuration", "Offline" albo "Punctured stripe". HPE Smart Array może oznaczyć logical drive jako failed i zgłosić błędy POST. Linux mdadm będzie operował na superblokach, event count, Bad Block Log i stanie członków macierzy. Synology i QNAP pokażą uproszczony komunikat w panelu, np. "Volume Crashed" lub "Storage Pool Degraded".
Dlatego sama informacja "RAID się nie odbudował" nie wystarcza do oceny sprawy. Ważne jest, jaki był NAS lub kontroler, ile dysków było w macierzy, który dysk wypadł pierwszy, czy był hot spare, czy kliknięto rebuild, repair, force online, import foreign config albo clear foreign config.
W laboratorium nie próbujemy od razu "ożywić" kontrolera. Najpierw zabezpiecza się dyski, wykonuje kopie posektorowe i dopiero z obrazów analizuje metadane: DDF, RIS, mdadm superblock, LVM, Btrfs, EXT4, NTFS albo VMFS. To pozwala sprawdzić wiele wariantów złożenia macierzy bez zapisu na oryginalnych nośnikach.
Statusy kontrolera - co oznaczają
Kiedy możesz to naprawić sam
Nie każdy nieudany rebuild wymaga laboratorium. Kilka scenariuszy gdzie administrator może sobie poradzić samodzielnie:
- Rebuild padł z powodu chwilowego błędu (loose cable, port): SMART wszystkich dysków jest czysty, błąd dotyczył timeoutu a nie URE. Sprawdź kable, przestaw dysk na inny port, spróbuj rebuildu. Zrób obrazy dysków jako środek ostrożności.
- Masz zweryfikowane backup danych: przywróć z backupu. To zawsze prawidłowa odpowiedź jeśli backup jest aktualny i sprawdzony.
- RAID 6 lub RAID 10 - rebuild się nie udał ale volume jest jeszcze dostępny: skopiuj dane natychmiast zanim sytuacja się pogorszy.
- mdadm RAID 5 - pojedynczy URE na jednym sektorze: użyj ddrescue do obrazowania dotkniętego dysku z pominięciem złego sektora, potem składaj macierz z obrazów.
We wszystkich innych przypadkach - jeśli dane są jedyną kopią i nie ma backupu - laboratorium jest bezpieczniejszą opcją niż kolejna próba rebuildu.
FAQ
Powiązane
RAID padł lub rebuild się nie udał?
Nie klikaj nic więcej.
Opisz model NAS-a lub kontrolera, typ RAID, ile dysków padło i co zrobiłeś dotąd. Odpiszę z oceną sytuacji - zazwyczaj tego samego dnia.