Weryfikacja zdalna i diagnoza problemu
Odzyskiwanie danych z serwerów NAS to często walka z czasem i skomplikowaną architekturą logiczną. Niedawno do naszego laboratorium trafił model QNAP TS-351 ze Szczecina.
Zlecenie rozpoczęliśmy od zdalnej analizy, która była kluczowa ze względu na konfigurację typu SSD Cache w trybie odczyt/zapis. Istniało poważne ryzyko, że mechanizm TRIM mógł wyzerować zawartość dysku SSD lub nadpisać metadane – co w wielu przypadkach oznacza nieodwracalne zniszczenie struktury logicznej plików.
Wstępna weryfikacja potwierdziła jednak, że dane na SSD fizycznie istnieją. Klient podjął decyzję o przesłaniu wszystkich nośników do laboratorium, aby podjąć próbę rekonstrukcji macierzy.
Pułapka SSD Cache w macierzach QNAP
Warto zatrzymać się przy samej technologii. QNAP wprost ostrzega na swoich forach: awaria pamięci Cache SSD w trybie odczyt/zapis może prowadzić do trwałej utraty danych.
Dlaczego tak się dzieje?
- W tym trybie pamięć podręczna przechowuje krytyczne części tablic alokacji i struktury logicznej wolumenu.
- Uszkodzenie dysku SSD lub błąd logiczny metadanych sprawia, że odczyt struktury plików staje się niemożliwy.
- Bez integralnego Cache'u użytkownik zostaje z kawałkami danych bez nazw i folderów.
Analiza uszkodzenia: gdzie podział się dysk NVMe?
Po zabezpieczeniu dwóch dysków HDD (WD40PURZ) oraz jednego SSD SATA przystąpiliśmy do analizy. Tu pojawiły się pierwsze schody.
Specyfikacja TS-351 wskazywała na dodatkowy slot M.2 NVMe. Okazało się, że taki dysk również był w urządzeniu, ale nie trafił do pierwszej przesyłki. Poprosiłem klienta o jego dosłanie – bez niego dalsza analiza nie miała sensu.
Po dostarczeniu dysku NVMe szybko okazało się, że wszystkie jego kluczowe partycje są puste. Metadane macierzy wskazywały jednak na brakujące urządzenie fizyczne – co znaczyło, że NVMe był aktywną częścią konfiguracji i jego stan miał kluczowe znaczenie dla możliwości odzysku.
Jak się okazało, zawinił błąd podczas migracji dysków do nowego urządzenia – to wtedy QNAP zgubił oryginalną konfigurację i wyzerował partycje NVMe, które stały się bezużyteczne dla macierzy.
Można by w tym miejscu napisać, że przed migracją powinna była zostać wykonana kopia zapasowa. Oczywiście – tak, powinna. My jednak nie jesteśmy od oceniania decyzji klientów. Trafił do nas konkretny problem i naszym zadaniem było znaleźć jego rozwiązanie.
Sprzeczność w konfiguracji – RAID 5 czy RAID 1?
To co widzieliśmy w plikach konfiguracyjnych serwera wprowadzało dodatkowy chaos. Zapisana konfiguracja wskazywała RAID 5 – tymczasem fizyczna struktura dysków HDD jednoznacznie mówiła RAID 1 (lustro).
Skąd ta sprzeczność? Podczas migracji QNAP najprawdopodobniej zachował w plikach ustawień sugerowaną konfigurację dla nowych ustawień, mimo że fizycznie dyski były ułożone inaczej. Logi serwera sugerowały RAID 5, ale sektory dysków mówiły coś zupełnie innego.
Każda próba automatycznej odbudowy macierzy kończyła się tym samym komunikatem – required component is missing wskazując ciągle PV0.
Manualna odbudowa struktury logicznej
Automatyczne narzędzia do odzyskiwania danych poległy. Algorytmy wskazywały wolumeny fizyczne (PV0 i PV1) jako wspólną pulę, ale nie potrafiły złożyć ich w całość przy błędnych danych konfiguracyjnych.
Musieliśmy przejść na tryb pracy ręcznej:
- Odnalezienie prawidłowych wpisów LVM bezpośrednio na sektorach dysków.
- Ręczne przypisanie parametrów pracy obu pul (HDD i SSD) z pominięciem błędnych plików konfiguracyjnych.
- Załadowanie konkretnej migawki (Snapshot) o numerze 10024 z dnia 7.09.2025, która zawierała aktualną tablicę folderów i plików.
Kluczowym krokiem było ręczne obliczenie i przypisanie konfiguracji pamięci flash SSD dla puli LVM. Dopiero po tym kroku narzędzie było w stanie poprawnie zmapować zakresy danych między dyskami HDD a SSD Cache i odczytać spójną strukturę logiczną.
Finał: 100% skuteczności
Dzięki ręcznemu połączeniu metadanych z dysków HDD oraz SSD udało się w pełni zrekonstruować strukturę logiczną danych klienta. Czas realizacji wyniósł 20 dni – od dostarczenia dysków do laboratorium do weryfikacji przekazanych danych.
Ten przypadek pokazuje, że nawet sytuacje opisywane przez producenta jako potencjalnie nieodwracalne – przy odpowiedniej wiedzy o strukturze LVM, ręcznej analizie metadanych i cierpliwości – można zakończyć sukcesem.