Odzyskiwanie danych z RAID 10 - mirror, striping i pary mirrorów
RAID 10 łączy mirrorowanie i striping - każda para dysków trzyma identyczne dane, pary są rozłożone przez striping. Tolerancja awarii zależy nie od liczby padniętych dysków, ale od tego które padły: dwa dyski z różnych par to brak problemu, dwa dyski z tej samej pary to brak dostępu do całej macierzy.
Rebuild zdegradowanej pary mirrorów wymaga pełnego odczytu ocalałego dysku pod ciągłym obciążeniem. Jeśli ten dysk ma latentne błędy sektorów lub jest z tej samej partii co padły - rebuild może spowodować drugą awarię w tej samej parze, co oznacza utratę wszystkich danych tej pary. Oznacz dyski numerami slotów i skontaktuj się z laboratorium zanim rebuild dobiegnie końca.
Jak działa RAID 10 - stripe of mirrors
RAID 10 to zagnieżdżona macierz: najpierw mirrorowanie wewnątrz par dysków, potem striping tych par względem siebie. Stąd alternatywna nazwa RAID 1+0 - RAID 1 (mirror) jest na dole, RAID 0 (stripe) jest na górze.
W 4-dyskowym RAID 10 mamy dwie pary mirrorów. Dysk A1 i A2 trzymają identyczne dane (para A). Dysk B1 i B2 trzymają identyczne dane (para B). Nowe zapisy są dzielone na bloki i rozkładane naprzemiennie: blok 1 idzie do pary A, blok 2 do pary B, blok 3 do pary A itd. Pojemność użytkowa to 50% całkowitej - dwa dyski z czterech są przeznaczone na kopie.
W 6-dyskowym RAID 10 mamy trzy pary. W 12-dyskowym - sześć par. Każda para to niezależne lustro w ramach większego zestawu stripe.
Kluczowa zasada: macierz traci dostęp do danych gdy którakolwiek para straci obydwa dyski. Jeden padły dysk z każdej pary - macierz działa. Dwa padłe dyski z tej samej pary - macierz offline.
W praktyce najważniejsze jest ustalenie par mirrorów. RAID 10 nie pada od samej liczby uszkodzonych dysków, tylko od tego, czy któraś para lustrzana straciła oba swoje nośniki. RAID 01 istnieje jako odwrotna konstrukcja, ale spotyka się go rzadko - zwykle wystarczy traktować go jako ciekawostkę i nie mylić z typowym RAID 10.
RAID 10 w serwerach, NAS i stacjach roboczych
RAID 10 spotyka się najczęściej tam, gdzie liczy się szybkość i odporność na awarię pojedynczego dysku w parze: serwery baz danych, hosty wirtualizacji, większe serwery plików, macierze pod monitoring, stacje robocze do montażu wideo i środowiska VM.
Może działać na kontrolerze Dell PERC, HP Smart Array, LSI MegaRAID, Adaptec, w Linux mdadm, Windows Storage Spaces, ZFS albo w systemach NAS. Użytkownik często widzi tylko komunikat Degraded, Failed, Foreign Configuration albo informację, że wolumin przestał się montować.
Przy zgłoszeniu wystarczy opisać z jakiego urządzenia pochodzą dyski, ile ich było, które sloty zgłaszały błąd i czy był uruchamiany rebuild. Parametry takie jak chunk size, kolejność dysków, pary mirrorów i system plików można ustalić podczas diagnozy na kopiach posektorowych.
Ile awarii przeżyje RAID 10 - matematyka wzorców
RAID 10 z N dyskami ma K = N/2 par mirrorów. Macierz przeżywa dowolną konfigurację awarii pod warunkiem, że każda para zachowuje co najmniej jeden sprawny dysk. Liczy się wzorzec awarii - które dyski padły - nie sama liczba.
W 4-dyskowym RAID 10 (2 pary): dwie awarie mogą być w dwóch różnych parach (bezpiecznie) lub w tej samej parze (utrata całości). Z 6 możliwych kombinacji awarii dwóch dysków, 4 są bezpieczne.
W 8-dyskowym RAID 10 (4 pary): trzy awarie mogą ocalić macierz jeśli każda jest w innej parze - 32 z 56 możliwych wzorców. To dużo, ale 24 wzorce niszczą macierz.
Ważne zastrzeżenie: tabela zakłada, że awarie są niezależne i losowe. W praktyce dyski tej samej partii produkcyjnej, z podobną liczbą godzin pracy, mogą padać korelacyjnie - często w tej samej parze jeśli były kupione razem. To czyni statystykę tabeli optymistyczną wobec rzeczywistości.
Dlatego przy RAID 10 sama informacja „padły dwa dyski” nie wystarcza do oceny sytuacji. Kluczowe jest to, czy były to dyski z tej samej pary lustrzanej, czy z dwóch różnych par. W pierwszym przypadku trzeba ratować przynajmniej jeden dysk z uszkodzonej pary. W drugim zwykle nadal istnieje pełna kopia każdego fragmentu danych.
Producenci sprzedają dyski w zestawach. Klient kupuje cztery dyski do RAID 10 - dostaje dyski z tej samej partii produkcyjnej, z tym samym firmware, z tymi samymi głowicami. Parując je w mirrorze, umieszcza najsłabszych kandydatów do awarii obok siebie. Gdy jeden padnie, drugi jest pod maksymalnym obciążeniem I/O podczas rebuildu - i jest z tej samej partii.
Zasada przy budowaniu RAID 10: partnerzy mirrorów z różnych partii, kupieni w różnym czasie.
| Konfiguracja RAID 10 | 2 losowe awarie | 3 losowe awarie | 4 losowe awarie |
|---|---|---|---|
| 4 dyski, 2 pary | 4 z 6 wzorców - oba muszą być w różnych parach | Niemożliwe - przy 2 parach 3 awarie zawsze niszczą jedną parę | Niemożliwe |
| 8 dysków, 4 pary | 24 z 28 wzorców | 32 z 56 wzorców - każda awaria w innej parze | 16 z 70 wzorców |
| 12 dysków, 6 par | 60 z 66 wzorców | 160 z 220 wzorców | 240 z 495 wzorców |
| 24 dyski, 12 par | 264 z 276 wzorców | 1760 z 2024 wzorców | 7920 z 10626 wzorców |
Wzorce zakładają niezależne, losowo rozmieszczone awarie. Korelowane awarie partyjne (ta sama para, podobny wiek dysków) są w praktyce częstsze niż wynika z tabeli.
Dlaczego dwa dyski w parze mirrorów mogą się różnić
Powszechne założenie: oba dyski w parze mirrorów zawsze mają identyczne dane, więc można użyć dowolnego z nich. To założenie jest błędne przy środowiskach z write-back caching - a właśnie w takich środowiskach (bazy danych, wirtualizacja, serwery plików z dużym ruchem) RAID 10 jest najczęściej stosowany.
Przy write-back caching kontroler potwierdza zapis hosta zanim dane trafią na talerze dysków. Oba dyski w parze flushują dane na talerze w odstępie milisekund - ale jeśli w tym oknie nastąpi nieoczekiwane wyłączenie zasilania, crash kontrolera lub przepięcie, jeden dysk może mieć zapis którego drugi jeszcze nie otrzymał.
Jeden dysk jest świeży (fresh) - ma ostatni commit zapisu. Drugi jest nieaktualny (stale) - zatrzymał się chwilę wcześniej. Mirror failover przełącza na dysk który żyje - ale nie gwarantuje że obydwa miały ten sam ostatni stan transakcji.
Jeśli przy rekonstrukcji macierzy użyjemy nieaktualnego dysku z jednej pary i świeżego z innej - złożona macierz ma niespójne generacje danych między parami: nagłówki systemu plików nie zgadzają się z danymi, bazy danych mają torn pages, kontenery VMDK odmówią montowania.
- mdadm (software RAID): event counter w superbloku - dysk z wyższym event count był ostatni w synchronizacji
- NTFS: $LogFile i numery sekwencji aktualizacji $MFT - wskazują który dysk commitował ostatnią transakcję metadanych
- EXT4 / XFS: stan journal i liczniki mount/write w superbloku - identyfikacja który dysk był ostatnio zapisywany
- Sprzętowe kontrolery: znaczniki czasu w metadanych DDF lub RIS, numery sekwencji i stan par mirrorów
Rekonstrukcja uruchamiana wyłącznie na kopiach posektorowych pozwala próbować różnych kombinacji (świeży/nieaktualny dysk z pary) bez ryzyka. Złą próbę można po prostu powtórzyć z innym wyborem. Przy rebuildie in-place na oryginalnych dyskach - zła decyzja jest nieodwracalna.
Wykrywanie chunk size i par mirrorów bez kontrolera
Chunk size (rozmiar bloku, stripe unit) to ilość danych zapisywanych do jednej pary mirrorów przed przejściem do następnej. Typowe wartości: 64 KiB (domyślny Dell PERC), 128 KiB, 256 KiB (domyślny HP Smart Array), 1 MiB przy macierzach zoptymalizowanych pod duże pliki.
Gdy oryginalny kontroler jest martwy i nie ma eksportu konfiguracji, chunk size i przypisania par mirrorów muszą być wykryte z surowych obrazów dysków. Metody:
Skanowanie entropii
Skompresowane i zaszyfrowane obszary mają bliską jednostkowej entropię Shannona. Pliki tekstowe, metadane systemu plików i struktury baz danych mają charakterystyczne rozkłady niejednorodne. Granice bloków chunk są widoczne tam gdzie rozkład entropii zmienia się w tym samym LBA na dwóch dyskach. Partnerzy mirrorów mają identyczną entropię w tym samym LBA - dyski ze stripu nie.
Kotwice systemu plików
NTFS: $MFT records po 1024 bajty wyrównane do granic chunk. EXT4: backup superblok w grupach bloków 1, 3^n, 5^n, 7^n - przy 4 KiB bloku, grupa 1 zaczyna się od bloku 32768. XFS: nagłówki Allocation Group z samoreferującym numerem AG. ZFS: uberblock array w drugiej połowie każdego 256 KiB vdev label. Każda kotwica ląduje w tym samym offsecie na dyskach mirrorów i w offsecie oddalonym o chunk na dyskach stripu.
mdadm --examine /dev/sdXScenariusze awarii RAID 10 - co się stało i co dalej
Proces odzysku z RAID 10 krok po kroku
Jak wyceniamy odzysk z RAID 10
W RAID 10 wycena zależy głównie od liczby dysków, stanu każdego nośnika, typu kontrolera lub NAS-a, systemu plików oraz tego, czy był uruchomiony rebuild, import Foreign Configuration albo praca z nieaktualnym członkiem pary.
Najpierw wykonywana jest diagnoza i kopie posektorowe dostępnych dysków. Po analizie dostajesz informację, czy można złożyć pełny obraz danych, czy potrzebna jest naprawa któregoś dysku z uszkodzonej pary oraz jaki zakres odzysku jest realny.
Aktualne zasady diagnozy i rozliczeń trzymamy w jednym miejscu - w cenniku i formularzu zgłoszenia - dlatego na tej podstronie celowo nie podajemy sztywnych kwot.
Po diagnozie otrzymujesz opis usterki, ocenę szans i konkretną wycenę do akceptacji. Właściwy odzysk danych nie jest rozpoczynany bez Twojej zgody.
RAID 10 na kontrolerach sprzętowych i software RAID
Przy wymianie kontrolera na inny model PERC: "Foreign Configuration" w BIOS-ie RAID. Akceptacja importu przepisuje konfigurację z dysków do NVRAM nowego kontrolera i zazwyczaj działa poprawnie przy wymianie na ten sam rodzaj PERC. Clearing Foreign Config niszczy DDF z dysków - bez możliwości odwrócenia.
Domyślny chunk size to 256 KiB - nie 64 KiB jak PERC. Narzędzia zakładające 64 KiB dają losowe dane. Kontrolery HP Smart Array wyposażone w Flash-Backed Write Cache (FBWC) lub Battery-Backed Write Cache (BBWC): awaria modułu cache przy brudnych zapisach to dane które nigdy nie trafiły na dyski. Rekonstrukcja traktuje macierz jako stan sprzed niespłukanych zapisów.
Przy analizie forensycznej klonów można uruchomić storcli /c0 show all i MegaCli64 -PDList -aALL na testowym systemie z klonami żeby odczytać te same metadane co kontroler - bez ryzyka zapisu na oryginały.
Odczyt bez składania:
mdadm --examine /dev/sdX. Składanie readonly na testowym systemie: mdadm --assemble --readonly /dev/md0 /dev/sdX /dev/sdY ...Flaga --force przy składaniu z dyskiem o niższym event count = stale drive włączony do macierzy. Nigdy bez świadomej decyzji.
Przy awarii kontrolera storage (Storage Spaces Direct, S2D) - metadane mogą być niespójne. Dostęp z Linuxa możliwy przez specjalne narzędzia ale wymaga ostrożności przy niespójnych metadanych.
Przy odzysku z VMFS na RAID 10 - po złożeniu wirtualnej macierzy praca z obrazem VMFS przez dedykowane narzędzia do odzysku środowisk VMware.
Czego nie robić po awarii RAID 10
- Nie uruchamiaj rebuildu zdegradowanej pary bez sprawdzenia SMART partnera - jeśli partner jest marginalny, rebuild go dokończy
- Nie akceptuj Foreign Configuration bez zdjęcia ekranu BIOS-a i bez pewności że żaden dysk nie był stale
- Nie używaj mdadm --assemble --force z dyskiem który ma wyraźnie niższy event count niż reszta
- Nie wkładaj dysków z RAID 10 do innego systemu bez oznaczenia numerów slotów - kolejność ma znaczenie
- Nie używaj konsumenckich dysków DM-SMR jako replacement w macierzy - jest spore prawdopodobieństwo, że podczas rebuildu mocno zwolnią, zaczną zgłaszać timeouty i zostaną wyrzucone z macierzy
- Nie uruchamiaj chkdsk, fsck, ani żadnych narzędzi naprawczych na oryginalnych dyskach - najpierw kopie posektorowe
- Nie inicjalizuj ani nie formatuj dysków przy komunikatach "dysk niezainicjalizowany" czy "nieznana partycja"
- Nie restartuj przerwanego rebuildu - dyski w stanie pośrednim, każdy restart może nadpisać dobre sektory
Co warto napisać przy awarii RAID 10
Nie musisz znać wszystkich parametrów macierzy. Pomocne będzie kilka prostych informacji: ile było dysków, z jakiego serwera lub NAS-a pochodzą, który slot zgłaszał błąd, czy był rebuild oraz czy pojawił się komunikat Degraded, Failed albo Foreign Configuration.
Jeśli dyski są już wyjęte z obudowy, dobrze jest zachować ich kolejność albo oznaczyć sloty. Jeśli widzisz ekran kontrolera RAID, warto zrobić zdjęcie przed dalszym klikaniem. To często ułatwia późniejszą rekonstrukcję, ale brak tych informacji nie zamyka drogi do diagnozy.
Nie twórz nowego woluminu, nie uruchamiaj kolejnego rebuildu, nie inicjalizuj dysków i nie uruchamiaj narzędzi naprawczych typu CHKDSK/fsck na oryginałach. Resztę można ustalić podczas pracy na kopiach posektorowych.
Słownik terminów RAID 10 - co oznaczają te pojęcia
FAQ - RAID 10
Zobacz też
RAID 10 nie działa? Opisz sytuację.
Ile dysków, jaki kontroler, czy z tej samej pary, czy był rebuild lub Foreign Config. Odpiszę z oceną sytuacji - zazwyczaj tego samego dnia.