Skip to content

Zdegradowana macierz RAID 5 lub RAID 6 z awarią drugiego dysku podczas odbudowy (dlaczego nigdy nie należy uruchamiać CHKDSK lub fsck, klonowania sektora ddrescue i zestawu mdadm tylko do odczytu)

Numery alarmowe różnią się w zależności od kraju. Na tej stronie używany jest numer 911, numer obowiązujący w Stanach Zjednoczonych i Kanadzie. W wielu innych krajach używany jest numer 112, 999 lub inny. Znajdź numer dla swojego kraju.

Wymiana uszkodzonego dysku twardego na zdegradowany RAID 5 lub RAID 6 serwer pamięci masowej, Synology DiskStation, QNAP NAS, Linux mdadm macierz lub Dell PERC /KM Smart Array /LSI MegaRAID kontroler sprzętowy tylko do oglądania drugiego pozostałego rzutu dysku członkowskiego UNC (Niekorygowalny błąd odczytu) uszkodzone sektory, Pending Sectorslub wyłącz tryb offline pod adresem 42% odbudowy parzystości to jedna z najniebezpieczniejszych awarii pamięci masowej w przedsiębiorstwach i domowych laboratoriach. W jednoparzystości RAID 5 tablica (N - 1 odporność na uszkodzenia), matematyczna rekonstrukcja XOR dysku zastępczego wymaga odczytu każdego pojedynczego sektora (LBA 0 do końcowego LBA) w 100 procentach pozostałych N - 1 członek jeździ jednocześnie. Kiedy nowoczesny, o dużej pojemności 8 TB do 24 TB dyski helowe (zakupione z tej samej partii produkcyjnej i poddane identycznym godzinom działania temperatury i wibracji) przechodzą wieloterabajtowy odczyt sekwencyjny, wykrywając pojedynczą ukrytą wadę nośnika (URE) lub słaba głowica odczytująca na drugim dysku powoduje, że kontroler RAID przerywa przebudowę, wyrzuca drugi dysk jako Faulty / Crashed i zaznacz całą pulę pamięci Offline / Crashed / Superblock Event Count Mismatch.

Nie panikuj i nie wymuszaj ponownej przebudowy ani nie uruchamiaj narzędzi do naprawy systemu plików (fsck, e2fsck, xfs_repairlub Windowsa CHKDSK). Nawet gdy wjedzie drugi raz RAID 5 (lub trzeci przejazd RAID 6) rozwija się 50 do 5,000 uszkodzonych sektorów i zostaje wyrzucony z tablicy, 99,9999 procent sektorów na tym „uszkodzonym” drugim dysku jest nadal w 100% czytelnych. Poprzez natychmiastowe zatrzymanie macierzy i klonowanie każdego niestabilnego dysku członkowskiego sektor po sektorze na sprawne dyski zapasowe przy użyciu GNU ddrescue i składanie sklonowanych obrazów w Read-Only / --assume-clean tryb nakładki (mdadm + dmsetup nakładki pętli Copy-on-Write), możesz bezpiecznie zamontować system plików i skopiować praktycznie każdy plik w nienaruszonym stanie. Aby zapoznać się ze specyfikacją urządzenia NAS i awariami kontrolera sprzętowego, przeczytaj nasze towarzyszące przewodniki Utrata wielu dysków RAID 5 lub RAID 6 Synology, QNAP lub TrueNAS, Śmierć karty kontrolera RAID i import zagranicznej konfiguracji, i Awaria macierzy RAID NAS i odzyskiwanie ZFS/Btrfs. Jeśli awaria serwera ma wpływ na systemy bezpieczeństwa lub infrastrukturę medyczną, skontaktuj się z lokalnym numerem alarmowym (911 w Stanach Zjednoczonych i Kanadzie, 112 w całej Unii Europejskiej, 999 w Wielkiej Brytanii) lub sprawdź nasz katalog numery alarmowe.

Zrób to teraz

  1. Natychmiast przerwij wszelkie aktywne odbudowy parzystości lub wyczyść i całkowicie wyłącz macierz (lub odłącz zasilanie płyty montażowej SATA/SAS, jeśli dysk wydaje mechaniczne dźwięki klikania lub zgrzytania):
  2. Dlaczego kontynuowanie opóźnionej odbudowy niszczy tablicę: Kiedy na dysku członkowskim natknie się na łatkę z uszkodzonym sektorem (LBA limit czasu odczytu) lub ma pogarszającą się głowicę odczytu/zapisu (media scratch), pozostawienie kontrolera RAID na wiele godzin w celu ponawiania prób sektorów, powoduje rozdrobnienie mikroskopijnej powłoki talerza magnetycznego w pył na całym cylindrze gąsienicy, zamieniając możliwy do odzyskania 20-sector usterkę, która doprowadziła do katastrofalnego zderzenia głowicy pełnego talerza.
  3. Nigdy nie biegaj CHKDSK /f, fsck -y, e2fsck, btrfs check --repairlub xfs_repair na uszkodzonej, niezsynchronizowanej lub częściowo odbudowanej macierzy RAID:
  4. Dlaczego CHKDSK i fsck spowodować 100% trwałe zniszczenie danych w niezsynchronizowanej macierzy RAID: Jeśli dysk 2 zostanie usunięty we wtorek, a dysk 3 zostanie usunięty podczas czwartkowej odbudowy, mdadm lub sprzętowy RAID Event Counter (Update Time) na tych dwóch dyskach różni się tysiącami transakcji. Jeśli na siłę złożysz tablicę z niedopasowanymi generacjami dysków lub brakującymi paskami i zezwolisz fsck lub CHKDSK aby zapisać do tablicy, moduł sprawdzający system plików widzi uszkodzone drzewa i-węzłów spowodowane przez źle wyrównane paski RAID, usuwa miliony prawidłowych wpisów do katalogów lost+foundi zastępuje dobre paski danych z uszkodzoną parzystością na każdym dysku w macierzy.
  5. Nigdy nie klikaj "Create Array", "Initialize"lub "Clear Configuration" w sprzętowym BIOS-ie RAID i NIGDY nie uruchamiaj mdadm --create bez --assume-clean oraz kopia przy zapisie (COW) nakładka pętli:
  6. Prowadzenie standardu mdadm --create (bez --assume-clean i dopasowując dokładny rozmiar fragmentu, układ i przesunięcie danych) natychmiast rozpoczyna zapisywanie nowych pasków parzystości na wszystkich dyskach, niszcząc superblok systemu plików i drzewa B, jeśli jakikolwiek pojedynczy parametr (512K vs. 64K kawałek, left-symmetric vs. left-asymmetriclub 2048s vs. 262144s przesunięcie danych) jest błędne nawet o jeden sektor.
  7. Oznacz każde fizyczne gniazdo dysku twardego (Bay 0 / Bay 1 / Bay 2 / Bay 3 i numer seryjny) za pomocą trwałego znacznika lub taśmy PRZED wyciągnięciem pojedynczego napędu z obudowy:
  8. Zapisz dokładny numer wnęki i numer seryjny na górnej etykiecie każdego napędu. Znajomość kolejności wnęki fizycznej i jej sprawdzenie mdadm --examine metadane oszczędzają godziny późniejszej rekonstrukcji kolejności pasków.
  9. Klonuj uszkodzone dyski sektor po sektorze na nowe, sprawne dyski GNU ddrescue (z plikiem mapy) przez bezpośrednie porty SATA/HBA płyty głównej PRZED próbą montażu RAID:
  10. Nigdy nie próbuj składać ani montować macierzy RAID, korzystając z samego fizycznie umierającego dysku. Podłącz uszkodzony dysk do dysku SATA/AHCI lub LSI innego niż RAID IT-Mode Port HBA na ratunkowej stacji roboczej z systemem Linux, wyłącz automatyczne montowanie systemu operacyjnego i uruchom ddrescue -f -n /dev/sdX /dev/sdY rescue_driveX.map więc zdrowe, szybkie sektory są ewakuowane w pierwszym przejściu, zanim dotkną stref uszkodzonych sektorów.
  11. ** Zmontuj sklonowane dyski Read-Only tryb (mdadm --assemble --readonly lub używając dmsetup / losetup RAM/nakładki plików)**:
  12. Umieszczając jednorazową kopię do zapisu (COW) na wierzchu każdego sklonowanego dysku członkowskiego, możesz przetestować zamontowanie macierzy, odtworzyć plik ext4 lub XFS journal lub nawet przetestuj wirtualną rekonstrukcję gwarantując, że zero bajtów zostanie kiedykolwiek zmodyfikowane na Twoich klonach dysku.

Danger

Pułapka „Niewłaściwa siła napędowa” (Stale Drive Overwriting Fresh Drives): Załóżmy, że masz 4 dyski RAID 5 (Disk 1, Disk 2, Disk 3, Disk 4). Disk 3 uległ awarii 6 miesięcy temu i nigdy go nie wymieniłeś (działanie uszkodzone przez 6 miesięcy). Dzisiaj, Disk 2 tworzy 100 uszkodzonych sektorów i wypada. Nigdy nie zmuszaj 6-miesięcznego dziecka na siłę Disk 3 z powrotem do trybu online, aby odbudować Disk 2. Jeśli używasz Disk 1 + Disk 3 (6 months stale) + Disk 4 aby odbudować lub zamontować tablicę, każdy plik utworzony lub zmodyfikowany w ciągu ostatnich 6 miesięcy zostanie uszkodzony i stanie się nieczytelnym śmieciem binarnym. Musisz klonować Disk 2 (dysk, który uległ awarii dzisiaj) z ddrescue i montujDisk 1 + Cloned Disk 2 + Disk 4.


Drzewo decyzyjne: ratowanie macierzy RAID 5 lub RAID 6 w przypadku awarii drugiego dysku podczas odbudowy

Postępuj zgodnie z poniższym procesem odzyskiwania pamięci do celów kryminalistycznych, aby odzyskać macierz bez utraty ani jednego pozostałego paska:

flowchart TD
    Start["RAID 5 (drugi dysk) lub RAID 6 (trzeci dysk) ulega awarii/przestaje w trybie offline podczas odbudowy"] --> StopNow["KROK 1: Natychmiast przerwij odbudowę i wyłącz macierz (zapobiegaj zarysowaniu talerza na uszkodzonym dysku)"]

    StopNow --> SoundCheck{"Czy uszkodzony napęd powodował głośne klikanie, piszczenie lub zgrzytanie?"}

    SoundCheck -->|"TAK: Mechaniczne uderzenie/starcie głowicy"| CleanRoom["ZATRZYMAJ: Nie włączaj ponownie napędu. Wysyłaj TYLKO dysk uszkodzony mechanicznie (plus 1 sprawny dysk w celach informacyjnych) do laboratorium w pomieszczeniu czystym w celu skopiowania obrazu na klon"]

    SoundCheck -->|"NIE: Obraca się płynnie, błąd z powodu uszkodzonych sektorów (UNC / Oczekiwanie / Przekroczenie limitu czasu)"| LabelDrives["KROK 2: Oznacz każdy dysk dokładnym numerem wnęki i numerem seryjnym -> Połącz się ze stacją roboczą z systemem Linux za pośrednictwem bezpośredniego interfejsu SATA / karty HBA w trybie IT"]

    LabelDrives --> InspectMeta["Uruchom polecenia „mdadm --examine /dev/sd*” i „smartctl -a /dev/sd*” na wszystkich dyskach (czas aktualizacji rekordu, licznik zdarzeń, rola, rozmiar porcji, układ, przesunięcie danych)"]

    InspectMeta --> CloneDrives["KROK 3: Sklonuj każdy uszkodzony dysk/dysk z uszkodzonym sektorem na zdrowy dysk zapasowy, używając polecenia „ddrescue -f -n” (najpierw szybkie przejście, następnie zeskrobanie pliku mapy)"]

    CloneDrives --> PickFreshest["Zidentyfikuj dyski N-1 (RAID 5) lub N-2 (RAID 6) za pomocą NAJWYŻSZEGO/NAJNOWSZEGO licznika „zdarzeń” (nigdy nie mieszaj przestarzałego, starego, upuszczonego dysku z nowymi dyskami)"]

    PickFreshest --> CowOverlay["KROK 4: Utwórz nakładki z funkcją kopiowania przy zapisie (COW) w pętli tylko do odczytu / „dmsetup” na sklonowanych dyskach, tak aby oryginalne klony nie mogły być modyfikowane"]

    CowOverlay --> AssembleRO["Uruchom polecenie „mdadm --assemble --force --readonly” na urządzeniach nakładkowych -> Zamontuj system plików tylko do odczytu („mount -o ro,noload”) -> Skopiuj wszystkie krytyczne dane do pamięci zewnętrznej"]

Faza 1: Zrozumienie, dlaczego drugi dysk ulega awarii podczas odbudowy RAID (XOR Parity Math & Event Counters)

Aby zrozumieć, dlaczego macierz uległa awarii w trakcie przebudowy i dlaczego dane nadal można odzyskać, sprawdź, jak to zrobić RAID 5 i RAID 6 faktycznie działają na dysku.

1. Jak XOR rekonstrukcja parytetu działa i dlaczego 1 uszkodzony sektor przerywa całą przebudowę

Na 4-biegu RAID 5 tablica (Drive A, Drive B, Drive C, Drive D), dane są dzielone na porcje o stałym rozmiarze (zwykle 64 KB lub 512 KB) rozłożony na dyskach, gdzie jeden fragment w każdym rzędzie zawiera parzystość XOR (P): $\(\text{Parity } P = A \oplus B \oplus C\)$ Jeśli Drive C kończy się całkowitym niepowodzeniem i wstawiasz puste miejsce Replacement Drive C_new, kontroler RAID musi zrekonstruować każdy pasek C_new obliczając: $\(C_{\text{zrekonstruowany}} = A \oplus B \oplus P\)$ - Co się stanie, kiedy Drive B trafia w jeden nieczytelny 4 KB sektor (UNC błąd) o godz 42% przebudowy: - Aby obliczyć ten pojedynczy 4 KB zablokuj C_new, kontroler musi mieć ważny odczyt Drive A, Drive B, i Drive D. - Kiedy Drive B zwraca sprzęt Read Error (Sense Key 03h / 11h Unrecovered Read Error) po 7 sekundach (TLER / ERC przekroczenia limitu czasu), kontrolery RAID dla klientów indywidualnych i przedsiębiorstw są często programowane z katastrofalnym zachowaniem domyślnym: zamiast pomijać ten pojedynczy 4 KB sektorze, rejestrując blok zerowy i kończąc drugi 99.9999% przebudowy, zaznacza kontroler RAID Drive B jako FAILED / OFFLINE i przerywa całą przebudowę. - W tej chwili w Twojej macierzy znajdują się dwa dyski oznaczone jako „Awaria” (Drive C co było tylko 42% odbudowany i Drive B który faktycznie ma 99.99998% zdrowe sektory i tylko 12 uszkodzone sektory).

2. Dlaczego Event Counters (Update Time) określ, których dysków należy użyć do odzyskiwania

Za każdym razem A RAID 5 lub RAID 6 tablica zapisuje dane lub zmienia stan (np. wypadanie dysku), metadane RAID (mdadm superblok lub sprzęt DDF metadane) zwiększa 64-bitowy Events licznik na wszystkich aktualnie aktywnych dyskach.

Porównaj mdadm --examine moc wyjściowa typowego 4-napędowego RAID 5 katastrofa gdzie sdb wczoraj się nie udało (Events: 10450) i sdc wypadło podczas dzisiejszej odbudowy (Events: 10892):

Dysk fizyczny Rola w tablicy Update Time Events Licznik Zdrowie fizyczne i jego zawartość
/dev/sda (Zatoka 1) Active device 0 Today 14:22:10 10892 100% zdrowe i aktualne: Zawiera każdy zapis aż do dokładnie sekundy, w której dzisiaj nastąpiła awaria przebudowy.
/dev/sdb (Zatoka 2) spare / faulty (Zastąpiony nowym dyskiem) Yesterday 09:15:00 10450 (Nieaktualne) Wczorajszy błąd: brakujące 29 godzin zapisów w bazie danych LUB zastąpiony nowym dyskiem, który jest 42% odbudowany (Reshape/Rebuild Pos).
/dev/sdc (Zatoka 3) faulty (Spadł o godz 42% odbudować) Today 14:22:09 10890 (Wyłączone o 2) 99,999% Zdrowy i aktualny: Wyrzucony tylko 1 sekundę wcześniej /dev/sda i /dev/sdd ponieważ podczas odczytu przebudowy trafiło 8 uszkodzonych sektorów.
/dev/sdd (Zatoka 4) Active device 3 Today 14:22:10 10892 100% zdrowe i aktualne: Zawiera każdy zapis aż do dokładnie sekundy, w której dzisiaj nastąpiła awaria przebudowy.
  • Złota zasada odzyskiwania RAID z powyższej tabeli:
  • Zauważ to /dev/sda (10892), /dev/sdc (10890) i /dev/sdd (10892) wszystkie mają praktycznie identyczne Events liczniki od Today 14:22.
  • Kiedy już sklonujemy /dev/sdc na zdrowy dysk za pomocą ddrescue (odzyskując 99,9999% sektorów i wypełniając zerami 8 nieczytelnych sektorów), możemy wymusić montaż /dev/sda + Cloned /dev/sdc + /dev/sdd (ignorując częściowo przebudowany /dev/sdb całkowicie). Ta kombinacja trzech dysków daje nam 100% spójność i degradację co do sekundy RAID 5 tablica z zerowym rozrywaniem pasków.

Faza 2: Krok po kroku klonowanie sektora uszkodzonego dysku za pomocą GNU ddrescue

Zanim dotkniesz mdadm lub dowolne narzędzie do montażu RAID, musisz sklonować dyski, które spowodowały błędy odczytu, na sprawne dyski zamienne o równej lub większej pojemności bajtów.

Krok 1: Przygotuj środowisko ratunkowe dla systemu Linux i wyłącz automatyczny montaż

  1. Uruchom stację roboczą z systemem Linux (lub uruchom serwer z działającej pamięci USB, takiej jak SystemRescue system-rescue.org lub Ubuntu Live Server) z dyskami podłączonymi do standardowych portów SATA na płycie głównej lub LSI HBA w IT Mode (Przejście inne niż RAID).
  2. Zapobiegaj automatycznemu składaniu lub montowaniu uszkodzonej macierzy RAID podczas uruchamiania systemu Linux:
  3. Podczas uruchamiania SystemRescue lub Ubuntu Live sprawdź cat /proc/mdstat. Jeśli Linux automatycznie zmontował częściowy plik md urządzenie w tle, przed wykonaniem obrazowania natychmiast zatrzymaj je w trybie awaryjnym tylko do odczytu:
    mdadm --stop /dev/md*
    
  4. Identyfikuj każdy dysk według dokładnego modelu, numeru seryjnego i rozmiaru bajtu (nigdy nie zgaduj /dev/sdX litery, ponieważ Linux przypisuje litery dysków przy ponownym uruchomieniu):
    lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,FSTYPE
    
    Napisz jakie /dev/sdX odpowiada Twojemu ulegającemu awarii dysku źródłowego (na przykład /dev/sdc, seryjny WCC4E12345) i które /dev/sdY to Twój nowy, pusty dysk docelowy (na przykład /dev/sdf, seryjny ZGG9988776).

Krok 2: Uruchom etap 2 GNU ddrescue protokół klonowania (zawsze używaj pliku Mapfile)

Nigdy nie używaj standardu dd (dd if=/dev/sdc of=/dev/sdf) na uszkodzonym dysku RAID: standard dd albo przerywa pracę w pierwszym uszkodzonym sektorze, albo przesuwa przesunięcia wyjściowe, jeśli sync jest źle skonfigurowany i nie pamięta, które sektory zakończyły się sukcesem. GNU ddrescue (gddrescue package) wykorzystuje inteligentny plik mapy stanu wieloprzebiegowego:

  1. Przebieg 1: Szybki klon bez skrobania (-n flaga), aby najpierw uratować 99,99% zdrowych sektorów:
    ddrescue -f -n -b 4096 /dev/sdc /dev/sdf /root/raid_bay3_sdc.map
    
  2. -f: Umożliwia zapis bezpośrednio na urządzeniu blokującym /dev/sdf (sprawdź to trzykrotnie /dev/sdc jest źródłem i /dev/sdf jest pustym celem).
  3. -n (--no-scrape): Mówi ddrescue aby natychmiast przeskoczyć dowolny obszar wolnego lub uszkodzonego sektora bez konieczności niszczenia głowicy odczytującej, ratując wszystkie zdrowe gigabajty przy maksymalnej prędkości (150 to 250 MB/s), zanim stan dysku się pogorszy.
  4. /root/raid_bay3_sdc.map: Zapisuje dokładny postęp sektora co 30 sekund. Nawet jeśli uszkodzony dysk zostanie zablokowany i będzie wymagał włączenia zasilania, należy ponownie uruchomić dokładnie to samo polecenie za pomocą polecenia .map plik jest wznawiany dokładnie w sektorze, w którym został zatrzymany.
  5. Przejście 2: Ukierunkowane odwrócenie/przycinanie (-d -r1), aby odzyskać marginalne uszkodzone sektory:
  6. Po zakończeniu przejścia 1 (pct rescued: 99.99%), zmniejsz limit czasu polecenia SCSI jądra, aby każdy uszkodzony sektor szybko ulegał awarii (5 seconds zamiast czekać 30 to 180 seconds na sektor):
    echo 5 > /sys/block/sdc/device/timeout
    
  7. Uruchom Pass 2 z bezpośrednim dostępem do dysku (-d) i 1 ponowna próba (-r 1):
    ddrescue -f -d -r 1 -b 4096 /dev/sdc /dev/sdf /root/raid_bay3_sdc.map
    
  8. Wyłącz, odłącz pierwotną awarię /dev/sdc jedź i odstaw bezpiecznie na półkę: Od tego momentu będziesz pracować wyłącznie ze swoim zdrowym klonem (/dev/sdf) i inne zdrowe dyski członkowskie.

Faza 3: Bezpieczny montaż RAID tylko do odczytu przy użyciu funkcji kopiowania przy zapisie (COW) nakładki i mdadm

Teraz, gdy masz już zdrowe klony dysków, nigdy nie uruchamiaj mdadm --assemble --force bezpośrednio na surowych dyskach bez ochronnej funkcji kopiowania przy zapisie (COW) nakładka lub --readonly flaga. Dlaczego? Ponieważ --force zapisuje superbloki RAID na dyskach i jeśli dziennik systemu plików (ext4 / XFS) odtwarza się automatycznie na wierzchowcu przy użyciu niewłaściwej kombinacji napędu, trwale zmienia twoje klony.

Krok 1: Sprawdź metadane RAID na wszystkich dyskach członkowskich (mdadm --examine)

Biegnij mdadm --examine na każdym dysku członkowskim (lub partycji, np. /dev/sda1 lub /dev/sda3 na dyskach Synology/QNAP NAS) i zapisz dane wyjściowe w pliku tekstowym:

mdadm --examine /dev/sd[a,b,d,f]* > /root/raid_metadata_audit.txt
cat /root/raid_metadata_audit.txt
Przyjrzyj się czterem krytycznym polom dla każdego napędu: 1. Array UUID: Sprawdź, czy wszystkie dyski należą do dokładnie tej samej puli RAID. 2. Device Role: Pokazuje dokładny indeks pasków (Active device 0, Active device 1, Active device 2, Active device 3). 3. Update Time & Events: Zidentyfikuj N - 1 dyski (dla RAID 5) lub N - 2 dyski (dla RAID 6), które mają najwyższy/najbliższy udział Events liczyć. 4. Raid Level, Layout, Chunk Size, i Data Offset: Zapisz dokładnie te liczby (np. Raid Level : raid5, Layout : left-symmetric, Chunk Size : 512K, Data Offset : 262144 sectors).

Krok 2: Utwórz nieniszczącą kopię przy zapisie (COW) Nakładki mapowania urządzeń (overlay-create)

Aby zagwarantować 100 procent bezpieczeństwa, tak aby nawet w przypadku siłowego złożenia układu i uruchomienia mount, na fizycznych dyskach twardych nie są kiedykolwiek zapisywane żadne bajty, utwórz pętlę dm-snapshot Nakładki typu „kopiuj przy zapisie” w /tmp (lub na zewnętrznym dysku magazynującym):

# Create a small sparse COW file + loop device for each member partition (e.g., sda3, sdf3, sdd3)
mkdir -p /root/cow
for dev in sda3 sdf3 sdd3; do
    truncate -s 20G /root/cow/${dev}.cow
    loop_base=$(losetup --find --show --read-only /dev/${dev})
    loop_cow=$(losetup --find --show /root/cow/${dev}.cow)
    sz=$(blockdev --getsz /dev/${dev})
    echo "0 $sz snapshot $loop_base $loop_cow P 8" | dmsetup create ovl_${dev}
done
- Co to robi: Masz teraz wirtualne urządzenia blokowe /dev/mapper/ovl_sda3, /dev/mapper/ovl_sdf3, i /dev/mapper/ovl_sdd3. Podstawowe dyski fizyczne (sda3, sdf3, sdd3) są zablokowane --read-only w warstwie bloku jądra. Wszelkie napisy wykonane przez mdadm --force, LVM lub powtórka dziennika systemu plików trafiają nieszkodliwie do jednorazowego użytku /root/cow/*.cow pliki. Jeśli coś pójdzie nie tak, po prostu usuń nakładki i utwórz je ponownie w ciągu 2 sekund.

Krok 3: Wymuś montaż macierzy na urządzeniach nakładkowych i zamontuj tylko do odczytu

  1. Zbierz najświeższe N - 1 urządzenia nakładki za pomocą --assemble --force:
    mdadm --assemble --force --verbose /dev/md99 /dev/mapper/ovl_sda3 /dev/mapper/ovl_sdf3 /dev/mapper/ovl_sdd3
    
  2. Dlaczego pomijamy przestarzały/w połowie przebudowany dysk (sdb3): Zmuszanie mdadm do montażu z 3 nowoczesnymi dyskami (sda3, sklonowany sdf3, i sdd3) przynosi /dev/md99 online w czystym, zdegradowanym trybie ([U_UU]) używając dokładnie najnowszego Events stan, podczas gdy ddrescue już uratowałem dane z sdf3.
  3. Aktywuj LVM (vgchange), jeśli Twój serwer NAS lub serwer korzysta z LVM na macierzach RAID (Synology SHR, QNAP, Proxmox, Ubuntu):
    pvscan
    vgscan
    vgchange -ay
    lvs
    
    (Jeśli Twój serwer Synology NAS korzysta z Btrfs na LVM lub Synology Hybrid RAID, teraz zobaczysz /dev/vg1000/lv lub /dev/vg1/volume_1 się pojawić.)
  4. Zamontuj system plików w ścisłym trybie tylko do odczytu i natychmiast usuń najważniejsze pliki:
    mkdir -p /mnt/raid_rescue
    # For ext4:
    mount -o ro,noload /dev/md99 /mnt/raid_rescue
    # (Or if noload refuses due to dirty journal, mount the COW overlay normally so the journal replays into the disposable COW file)
    mount -o ro /dev/md99 /mnt/raid_rescue
    # For Btrfs (Synology NAS):
    mount -t btrfs -o ro,usebackuproot,nologreplay /dev/vg1000/lv /mnt/raid_rescue
    
  5. ** Najpierw skopiuj najważniejsze foldery rsync na zewnętrzny dysk zapasowy**:
    rsync -avP --ignore-errors /mnt/raid_rescue/ /mnt/external_backup_usb/
    

Faza 4: Ratowanie sprzętowych kontrolerów RAID (Dell PERC, LSI MegaRAID, HP Smart Array, Adaptec) i pule ZFS/Btrfs

Co by było, gdyby twoja tablica była zarządzana nie przez Linuksa mdadm, ale za pomocą karty sprzętowego kontrolera RAID (Dell PERC H730/H740/H755, Broadcom / LSI MegaRAIDlub HP Smart Array), który teraz raportuje Virtual Disk Offline lub Foreign Configuration Found po czkawce podczas drugiego dysku podczas przebudowy?

1. Sprzętowe karty RAID (Dell PERC, LSI MegaRAID, HP Smart Array)

  1. Nigdy nie klikaj "Clear Foreign Configuration" lub "Initialize Virtual Disk":
  2. W Dellu PERC /LSI MegaRAID BIOS-u (Ctrl+R lub HII Narzędzie konfiguracyjne UEFI), Clear usuwa metadane RAID z dysków i Initialize zastępuje paski danych.
  3. Jeśli zdrowy dysk na chwilę utraci tryb offline z powodu luźnego kabla płyty montażowej lub przekroczenia limitu czasu, Import Foreign Configuration próbuje przywrócić dysk; jeśli jednak jeden dysk padł kilka tygodni temu, a drugi dzisiaj, importowanie obu dysków lub wymuszanie połączenia nieaktualnego dysku za pośrednictwem BIOS-u kontrolera może spowodować uszkodzenie macierzy.
  4. ** Bezpieczna metoda rekonstrukcji oprogramowania dla sprzętowej macierzy RAID (DDF Metadane / dmraid / R-Studio / UFS Explorer)**:
  5. Sprzętowe karty RAID przechowują standard SNIA DDF (Disk Data Format) metadane w końcowych sektorach na końcu każdego dysku twardego i rozłóż dane na dyskach, zaczynając od sektora 0 (lub po małym przesunięciu nagłówka) przy użyciu standardu 64 KB, 128 KB, 256 KBlub 512 KB rozmiary kawałków (Left-Asymmetric lub Left-Symmetric).
  6. Zamiast grać z destrukcyjnym sprzętowym BIOS-em karty RAID:
    1. Oznacz wszystkie dyski numerami gniazd i podłącz je do standardowego SATA / innego niż RAID IT-Mode Karta HBA na stacji roboczej odzyskiwania.
    2. Sklonuj dysk z uszkodzonym sektorem za pomocą GNU ddrescue jak pokazano w fazie 2.
    3. Otwórz sklonowane dyski w UFS Explorer RAID Recovery lub R-Studio Technician lub zmontuj je w trybie tylko do odczytu w systemie Linux, używając dmsetup / mdadm --build: te narzędzia automatycznie wykrywają LSI / PERC / HP kolejność pasków, wielkość porcji (64K/512K) i rotację parzystości w 100% pamięci tylko do odczytu, bez konieczności pozwalania sprzętowej karcie RAID na zapisanie ani jednego bajtu na dyskach.

2. TrueNAS/ZFS (RAID-Z1 / RAID-Z2) i Synology Btrfs Awarie szorowania/resilvera

Jeśli Twoja pula używa OpenZFS (RAID-Z1 lub RAID-Z2) na TrueNAS lub Proxmox i rzut drugim dyskiem CKSUM / READ błędy podczas a zpool replace resrebrzenie: 1. Dlaczego ZFS radzi sobie z uszkodzonymi sektorami podczas ponownego srebra lepiej niż sprzętowy RAID, a kiedy nadal się zawiesza: - W przeciwieństwie do naiwnych sprzętowych kart RAID, które umieszczają cały dysk w jednym uszkodzonym sektorze, ZFS kontynuuje ponowne wykrywanie przeszłości zlokalizowanej READ błędy i rejestruje tylko określone uszkodzone ścieżki plików w zpool status -v. - Jeśli jednak drugi uszkodzony dysk zawiesza magistralę SATA/SAS (I/O timeout / miotanie głową) lub całkowicie wyłącza się (UNAVAIL / FAULTED), basen wchodzi SUSPENDED stan (pool I/O is currently suspended). 2. Jak uratować a SUSPENDED lub FAULTED ZFS RAID-Z1 / RAID-Z2 basen: - Wyłącz czysto, sklonuj uszkodzony dysk na zdrowy dysk zastępczy, używając GNU ddrescue -f -n (Etykiety partycji ZFS zawierają dokładny plik vdev Identyfikator GUID na początku i na końcu dysku, dzięki czemu klon surowego sektora jest automatycznie rozpoznawany przez ZFS jako oryginał vdev członek). - Odłącz fizycznie umierający dysk, zostaw ddrescue klon podłączony i zaimportuj pulę ZFS w ścisłym trybie tylko do odczytu (readonly=on) bez rozpoczynania transakcji zapisu i wznawiania resilvera:

zpool import -o readonly=on -f -R /mnt/zfs_rescue tank
- Importowanie za pomocą -o readonly=on uniemożliwia ZFS zapisywanie nowych uberbloków lub prób naprawiania zapisów w tle, umożliwiając bezpieczne kopiowanie każdego zestawu danych poprzez zfs send lub rsync przed odbudowaniem basenu od zera.


Często zadawane pytania

Dlaczego powiedziałeś NIGDY nie uciekaj CHKDSK lub fsck kiedy moja macierz RAID zostanie zamontowana z błędami systemu plików po utracie dysku?

Działa na jednym samodzielnym dysku twardym CHKDSK lub fsck naprawia drobne niespójności w katalogach. Na wielodyskowa macierz RAID 5 lub RAID 6, w której doszło do utraty dwóch dysków lub przerwanej odbudowy, błędy systemu plików są prawie zawsze spowodowane przez Nieprawidłowe ustawienie paska RAID lub przestarzały dysk członkowski wymuszający połączenie z Internetem (czyli każdy 3 lub 4 64KB część danych jest odczytywana z dysku niewłaściwej generacji). Jeśli pozwolisz CHKDSK /f lub fsck -y działa na źle wyrównanej lub niezsynchronizowanej macierzy RAID, błędnie interpretuje miliony prawidłowych plików jako uszkodzone metadane, obcina drzewa katalogów, zrzuca nienazwane fragmenty do zagubiony + znalezionyi zapisuje nowe bloki parzystości na wszystkich dyskach, co sprawia, że matematycznie niemożliwe jest późniejsze ponowne złożenie prawidłowej kombinacji dysków. Zawsze montuj przez Kopia przy zapisie tylko do odczytu (KROWA) nakładki pierwszy.

Co się stanie, jeśli częściowo zregenerowany dysk zamienny (42% ukończone) ORAZ drugi dysk, który uległ awarii 42% OBYDWIE potrzebowali danych? Czy mogę je połączyć?

Tak. Jest to klasyczny ratunek RAID typu „Split-Horizon / Hybrid Clone”. Załóżmy Jedź 2 zmarł całkowicie w poniedziałek, włożyłeś Nowy dysk 2i odbudowa się udała 42% (LBA 3 500 000 000) wcześniej Jedź 3 doznał śmiertelnego uderzenia głową o godz LBA 3 500 000 000. Zauważ, co tak naprawdę masz: dla pierwsze 42% tablicy (0% do 42%), Nowy dysk 2 został już w 100% odbudowany. Więc po pierwsze 42% z asortymentu LBA, masz do dyspozycji kompletny zestaw pasków Dysk 1 + Nowy dysk 2 + Dysk 4 (leczenie uległo awarii Jedź 3 jako brakujący dysk). A jeśli Jedź 3 miał tylko zlokalizowaną łatę dotyczącą uszkodzonych sektorów pod adresem 42% (i można go odczytać z 43% do 100% przez ddrescue), używasz Dysk 1 + Sklonowany dysk 3 + Dysk 4 dla pozostałych 58% tablicy.

Dlaczego drugie dyski tak często ulegają awarii w trakcie przebudowy RAID 5?

Łączą się dwie rzeczywistości inżynieryjne RAID5 przebudowuje słynące z awarii podwójnych dysków: (1) Identyczne starzenie wsadowe: Większość użytkowników kupuje od 4 do 8 identycznych dysków twardych od tego samego sprzedawcy tego samego dnia (to samo oprogramowanie sprzętowe, ta sama partia fabryczna, ta sama partia silnika wrzeciona) i uruchomić je obok siebie w dokładnie tej samej temperaturze przez 35 000 godzin; gdy napęd 1 ulegnie zużyciu, dyski 2 i napęd 3 będą miały dni od osiągnięcia tego samego progu zużycia mechanicznego. (2) Ukryte, nienaprawialne błędy odczytu (URE): W normalnej codziennej pracy, 95% zimnych sektorów archiwalnych dysku twardego nie jest odczytywanych przez wiele miesięcy, więc ukryte uszkodzone sektory pozostają nieodkryte. A RAID5 odbudowa wymusza ciągłość 100% odczyt powierzchni każdego sektora na każdym pozostałym dysku (40 do 100 terabajtów ciągłego odczytu), natychmiast ujawniając wszelkie ukryte uszkodzone sektory, które narosły w ciągu ostatniego roku.

Skąd mam wiedzieć, na które pliki miało wpływ kilka nieczytelnych uszkodzonych sektorów ddrescue musiałeś wypełnić zero?

GNU ddrescue zawiera wbudowane narzędzie kryminalistyczne o nazwie ddrescuelog i ddru_ntfsfindbad / debugowanie który odwzorowuje dokładny zakres nieodzyskanego sektora LBA od Twojego .mapa plik (stan = '-' uszkodzone sektory) poprzez obliczenia paskowe RAID bezpośrednio do tabeli i-węzłów systemu plików. Kiedy już wiesz które 4KB bloki zostały wypełnione zerami podczas klonowania, możesz zapytać debugowanie (sprawdzę i sprawdź na wew4) lub btrfs sprawdza wewnętrzne rozwiązanie logiczne wydrukować dokładną listę 2 lub 3 nazw plików, które nakładały się na te uszkodzone sektory, potwierdzając ze 100% matematyczną pewnością, że każdy inny plik na wieloterabajtowym serwerze jest całkowicie nieuszkodzony.


Powiązane przewodniki


Źródła i oficjalne wytyczne

  • Wiki o Linuxie Raid (raid.wiki.kernel.org/index.php/Linux_Raid & Recovering_a_failed_software_RAID): Oficjalne jądro mdadm Protokół odzyskiwania, kopiowanie przy zapisie mapowania urządzeń (dm-snapshot) Nakładki i Events Kontrpojednanie.
  • GNU ddrescue Oficjalny podręcznik inżynieryjny (gnu.org/software/ddrescue/manual/ddrescue_manual.html): Wielofazowy, nieskrobujący (-n) i bezpośredni dostęp (-d) Algorytmy odzyskiwania sektora dla uszkodzonych nośników magnetycznych.
  • Oficjalna baza wiedzy Synology (kb.synology.com/en-global/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC): Montaż mdadm + LVM2 + Btrfs / ext4 Woluminy NAS w trybie tylko do odczytu w systemach Ubuntu Rescue.
  • Stowarzyszenie Przemysłu Sieci Magazynowych (SNIA): Wspólny format danych na dysku RAID (DDF) Specyfikacja przenoszenia metadanych sprzętowego kontrolera RAID.