Jak odzyskać dane z Synology NAS po awarii podczas migracji z RAID 1 do RAID 5?
-
Autor:
Oksana Volyniuk
-
Redaktor:
Michał Mirosznyczenko
Wyobraź sobie, że dodajesz dysk do systemu Synology NAS i rozpoczynasz migrację z RAID 1 do RAID 5, aby zwiększyć pojemność magazynu. Jednak podczas odbudowy nagle zanika zasilanie i NAS zostaje wyłączony. Po przywróceniu zasilania okazuje się, że jednego z oryginalnych dysków nie można już wykryć, a dostęp do plików jest niemożliwy. Co należy zrobić, jeśli nie ma aktualnej kopii zapasowej wymaganych danych? Czy można odzyskać pliki z dwóch zachowanych dysków, jeśli migracja do nowego poziomu RAID nigdy nie została ukończona?
- KROK 1. Środowisko testowe
- KROK 2. Podłączenie dysków do komputera z systemem Windows
- KROK 3. Wyniki analizy RAID 5
- KROK 4. Ręczna rekonstrukcja RAID
- KROK 5. Określanie początkowego offsetu danych
- KROK 6. Automatyczne wykrywanie parametrów RAID
- KROK 7. Wyszukiwanie danych w oryginalnej konfiguracji RAID 1
- Wnioski
- Najczęściej zadawane pytania
- Komentarze
Migracja macierzy na Synology NAS z RAID 1 do RAID 5 zazwyczaj kończy się bez utraty danych. Jednak awaria zasilania, błędy dysku lub przerwanie procesu mogą spowodować degradację magazynu albo jego całkowitą niedostępność. W takiej sytuacji najważniejsze jest unikanie pochopnych działań, które mogą utrudnić odzyskiwanie danych. W tym artykule sprawdzimy, jak prawidłowo ocenić stan macierzy Synology RAID po awaryjnej migracji oraz jakie metody mogą pomóc przywrócić dostęp do danych.
Odzyskiwanie danych z Synology NAS po nieudanej migracji RAID 1 → RAID 5
KROK 1. Środowisko testowe
Do testu użyliśmy urządzenia pamięci masowej sieciowej Synology DS409 z systemem DSM 4.2 oraz trzech dysków twardych o pojemności 320 gigabajtów każdy.
Początkowo dwa dyski zostały połączone w RAID 1 — macierz lustrzaną, w której dane były duplikowane na obu dyskach. Utworzono na niej wolumin z systemem plików Ext4 i zapisano około 110 gigabajtów danych testowych: dokumenty, zdjęcia, filmy i archiwa. Pliki umieszczono w katalogach o kilku poziomach zagnieżdżenia, aby później można było sprawdzić zachowanie zarówno zawartości, jak i struktury folderów.
Następnie trzeci dysk został dodany do macierzy, a za pomocą Storage Manager rozpoczęto zmianę poziomu RAID z RAID 1 na RAID 5.
Ta migracja pozwala zwiększyć dostępną pojemność przy zachowaniu ochrony przed awarią jednego dysku po pomyślnym zakończeniu operacji.
Gdy wskaźnik przebudowy osiągnął 29,55 procent, zasilanie NAS zostało celowo odłączone bez prawidłowego zamknięcia systemu. Następnie usunięto jeden z dwóch oryginalnych dysków RAID 1, symulując jego całkowitą niedostępność.
W rezultacie do odzyskiwania pozostały dwa dyski: jeden z oryginalnej macierzy lustrzanej oraz trzeci dysk dodany na potrzeby przejścia do RAID 5. Przebudowa nie została ukończona, więc część danych została już przeniesiona, a reszta nadal była przechowywana według poprzedniego schematu. Te dwa dyski zostaną użyte w kolejnych krokach.
KROK 2. Podłączenie dysków do komputera z systemem Windows
Przechodzimy do komputera z systemem Windows, na którym zainstalowano Hetman RAID Recovery.
Podłączamy dwa zachowane dyski za pośrednictwem stacji dokującej USB:
- jeden z oryginalnych dysków RAID 1;
- dysk dodany podczas przejścia na RAID 5.
Drugi członek oryginalnej macierzy lustrzanej jest w naszym teście niedostępny.
Uruchamiamy program. W sekcji RAID Arrays widzimy automatycznie wykrytą macierz DiskStation:2.
Zaznaczamy ją i sprawdzamy informacje na panelu Preview po prawej stronie. Program rozpoznał typ RAID 5, kolejność bloków Left Synchronous oraz rozmiar bloku 64 kilobajty.
Poniżej, na liście RAID Disks, widzimy dwa podłączone dyski oraz pozycję Empty disk, odpowiadającą brakującemu członkowi. Dla obu dostępnych dysków podany jest ten sam początkowy offset danych — do tego parametru wrócimy podczas ręcznej rekonstrukcji.
Lista zawiera również dwie niewielkie macierze RAID 1 o rozmiarze około 2,37 i 2 gigabajtów. Odpowiadają one obszarom systemowym Synology.
Nie należy ich mylić z oryginalną macierzą lustrzaną, która zawierała nasze pliki testowe.
Oryginalna macierz RAID 1 z danymi użytkownika nie jest już wyświetlana jako oddzielna.
KROK 3. Wyniki analizy RAID 5
Sprawdźmy, co jest dostępne w ramach automatycznie wykrytej konfiguracji RAID 5. W tym celu otwieramy wolumin Ext4 w tej macierzy, klikając go dwukrotnie. W kreatorze analizy wybieramy opcję Fast scan i klikamy Next, aby rozpocząć wyszukiwanie plików.
Dostępna część danych testowych: po analizie RAID 5 program znalazł 390 folderów i 8 239 plików. W wynikach widzimy folder My Data oraz zagnieżdżone katalogi z plikami testowymi. Część oryginalnej struktury została zachowana: program pokazuje nazwy folderów i plików oraz ich lokalizacje.
Zatem nawet przy dwóch dostępnych członkach przerwanej macierzy udało się odczytać część jej zawartości. Aby zapisać potrzebne pliki, zaznacz je, kliknij Recovery i wskaż folder na oddzielnym dysku, który nie należy do odzyskiwanej macierzy, aby uniknąć nadpisania danych źródłowych.
Jednak nie wszystkie pliki zapisane przed testem są obecne w wynikach. Przed migracją dane były przechowywane na dwóch dyskach jako kopie lustrzane. Podczas przejścia na RAID 5 system stopniowo zmieniał układ bloków, rozkładając je na trzy dyski i tworząc parzystość.
W rezultacie na zachowanych dyskach pozostały obszary o różnej organizacji danych. Układ RAID 5 odpowiada rozmieszczeniu bloków w już przebudowanych obszarach, natomiast poprzednia organizacja RAID 1 pozostaje w pozostałej części, choć sama macierz lustrzana nie jest już automatycznie wykrywana.
Dlatego brak pliku w tych wynikach nie oznacza jeszcze, że jego zawartość jest całkowicie utracona.
KROK 4. Ręczna rekonstrukcja RAID
W naszym przypadku program automatycznie zidentyfikował RAID 5 i jego parametry. Ale co zrobić, jeśli konfigurację trzeba określić ręcznie albo niektóre ustawienia są nieznane? W tym celu Hetman RAID Recovery zawiera narzędzie RAID Constructor. Na przykładzie wykrytego RAID 5 sprawdzimy jego możliwości, a następnie użyjemy tego narzędzia do odtworzenia oryginalnego RAID 1.
Otwieramy RAID Constructor, wybieramy RAID 5 i dodajemy dwa dostępne dyski. Brakujący członek zostaje oznaczony jako Empty disk. Dzięki temu otrzymujemy trzy pozycje odpowiadające składowi macierzy podczas migracji.
W konfiguracjach RAID 5 testowanych na Synology często spotykano kolejność bloków Left Synchronous oraz rozmiar bloku 64 kilobajty, dlatego użyjemy tego zestawienia w konstruktorze. W naszym przypadku odpowiada ono również parametrom automatycznie wykrytej macierzy.
Nie są to jednak wartości uniwersalne: dla innego zestawu dysków lub innego urządzenia pamięci masowej należy je sprawdzić oddzielnie, uwzględniając konfigurację macierzy oraz historię jej zmian.
Oddzielnie należy określić początkowy offset danych dla każdego dysku, dlatego najpierw sprawdzimy, gdzie go znaleźć i jak go obliczyć.
KROK 5. Określanie początkowego offsetu danych
Offset wskazuje, jaką początkową część dysku należy pominąć przed odczytem bloków macierzy użytkownika. Na diagramie dysku fizycznego widzimy partycje systemowe Synology oraz partycję używaną do przechowywania naszych plików. W tym teście zaczyna się ona w sektorze 9 437 184. To nasz punkt odniesienia. Same dane RAID zaczynają się nieco później, ponieważ na początku partycji znajduje się miejsce na informacje systemowe.
Otwieramy dysk fizyczny w HEX Editor. Aby przejść do początku wymaganej partycji, najpierw przelicz jej sektor początkowy na adres bajtowy. W kalkulatorze pomnóż 9 437 184 przez rozmiar sektora — 512 bajtów. Wynik to 4 831 838 208 bajtów. Przelicz wynik na zapis szesnastkowy i przejdź do tego adresu w edytorze.
Od bieżącej pozycji rozpocznij wyszukiwanie w kierunku do przodu. Wybierz wyszukiwanie szesnastkowe i wpisz sygnaturę FC 4E 2B A9. Pozwala to pominąć początkowe partycje systemowe Synology i wyszukać superblok EXT w partycji zawierającej nasze pliki.
Wymagane dopasowanie zostaje znalezione pod adresem 120001000. W pobliżu, w części tekstowej edytora, widzimy nazwę DiskStation:2. Sama sygnatura nie wystarcza, ponieważ taki ciąg bajtów może występować również w innych danych.
Teraz znajdźmy pole data_offset, które wskazuje początkowy offset danych RAID wewnątrz partycji. W tym formacie superbloku znajduje się ono 128 bajtów od początku i zajmuje osiem bajtów. W naszym przypadku są to pierwsze osiem bajtów wiersza pod adresem 120001080.
Wartość jest zapisana w kolejności little-endian. W standardowym zapisie liczba ta ma postać szesnastkową 800. Wprowadź ją do kalkulatora i przełącz na zapis dziesiętny — wynik to 2048 sektorów. Jest to odległość od początku partycji do początku danych RAID. Dodajemy więc 2048 do początkowego sektora partycji. Otrzymujemy 9 439 232 sektory. Po pomnożeniu przez 512 bajtów końcowy offset od początku dysku fizycznego wynosi 4 832 886 784 bajty. Jest to zgodne z wartością w właściwościach automatycznie wykrytego RAID 5.
KROK 6. Automatyczne wykrywanie parametrów RAID
Wracamy do RAID Constructor i podajemy ustalony offset dla każdego dostępnego dysku. Teraz możemy skorzystać z automatycznego wykrywania nieznanych parametrów.
Jeśli rozmiar bloku lub kolejność bloków są nieznane, można wybrać Detect automatically w polach Block size i Block order. Do określenia kolejności członków dostępna jest osobna opcja Detect the disk order automatically. Na przykład możemy pozostawić RAID 5, Left Synchronous i rozmiar bloku 64 kilobajty, ale pozwolić programowi określić kolejność dysków.
Po przejściu do następnego kroku program rozpoczyna wyszukiwanie konfiguracji odpowiadających określonym warunkom. Znalezione opcje są wyświetlane na liście. Wybierz wymaganą konfigurację i kliknij Add.
Następnie złożona macierz RAID pojawi się na głównym ekranie programu, gdzie można ją otworzyć w celu analizy i wyszukiwania plików.
Teraz użyjemy konstruktora do innego zadania — sprawdzimy zachowany dysk oryginalnej macierzy lustrzanej w konfiguracji RAID 1.
KROK 7. Wyszukiwanie danych w oryginalnej konfiguracji RAID 1
Wracamy do RAID Constructor i wybieramy RAID 1. Dodajemy zachowany dysk oryginalnej macierzy lustrzanej, a brakujący członek zostaje oznaczony jako Empty disk.
Podajemy zweryfikowany początkowy offset danych. Dzięki temu program wie, jak odczytywać dane według poprzedniego schematu. Jest to wirtualna rekonstrukcja służąca do analizy: nie cofa migracji ani nie przywraca dysków do stanu sprzed zdarzenia.
Złożona macierz RAID 1 pojawi się na głównym ekranie programu.
Otwieramy ją dwukrotnie i w kreatorze analizy wybieramy Full analysis. Określamy system plików Ext4 i rozpoczynamy analizę.
Po zakończeniu program znalazł 979 folderów i 14 049 plików. Dla porównania, po Fast scan konfiguracji RAID 5 uzyskaliśmy 390 folderów i 8 239 plików. Liczby te nie oznaczają liczby unikalnych prawidłowych plików: wyniki mogą zawierać duplikaty i wymagają weryfikacji.
Sprawdzamy znalezione dane. Oryginalna struktura katalogów nie została odtworzona w całości, a część znalezionych obiektów znajduje się w Lost and Found.
Odtworzenie drzewa folderów wymaga zachowania struktur metadanych systemu plików oraz zależności między nimi. Po przerwanej migracji dane pojedynczego pliku mogą być czytelne w wybranej konfiguracji, podczas gdy wpisy łączące go z oryginalnym katalogiem mogą być niedostępne. Dlatego brak znanego folderu nie musi oznaczać, że cała jego zawartość została utracona.
Aby szybciej znaleźć potrzebne pliki, użyj funkcji Find File. W oknie wyszukiwania wpisz pełną nazwę lub jej część i kliknij Find. W razie potrzeby można włączyć wyszukiwanie z uwzględnieniem wielkości liter lub ograniczyć wyniki wyłącznie do pełnych dopasowań całych słów.
Sprawdzamy kilka plików w różnych formatach, w tym pliki znalezione poprzez wyszukiwanie. W oknie Preview weryfikujemy obrazy, zawartość dokumentów i inne pliki dostępne do podglądu. Pozwala to zidentyfikować wymagane dane i ocenić ich zawartość przed zapisaniem.
Wnioski
W tym teście przeanalizowaliśmy utratę dysku po przerwanej migracji Synology z RAID 1 do RAID 5. Hetman RAID Recovery automatycznie wykrył RAID 5 na podstawie zachowanych metadanych, ale tylko część oryginalnych danych była dostępna w tej konfiguracji.
Następnie przeanalizowaliśmy również zachowany dysk oryginalnej macierzy lustrzanej jako RAID 1. W wynikach znaleźliśmy pliki, których zawartość można wyświetlić, chociaż struktura katalogów nie została odtworzona w pełni.
Ten przypadek pokazuje, dlaczego po nieukończonej migracji należy uwzględnić wcześniejszą konfigurację macierzy: jej bieżące metadane nie muszą odzwierciedlać położenia wszystkich danych na dyskach.
Aktualna kopia zapasowa znacząco upraszcza odzyskiwanie danych po incydencie. Jeśli jej nie ma, analiza zachowanych danych może pomóc odzyskać przynajmniej część plików — właśnie taki scenariusz został tutaj sprawdzony.
