Wesołe jest życie nekromanty

Artykuł oryginalnie ukazał się dnia 14 listopada 2011 pod (nieistniejącym już) adresem http://doomhammer.jogger.pl

Moje problemy z ReadyNAS zaczęły się dość wcześnie. Myślę, że to trudne dzieciństwo nie tyle spowodowane było awaryjnością sprzętu, co raczej moimi sadystycznymi skłonnościami. Przyznam, iż jestem odrobinę perwersyjny i zaliczam się do grona geeków. Oznacza to, że mam tendencję do wykorzystywania każdego sprzętu, który wpadnie mi w ręce w sposób, którego producent raczej nie przewidział.

Na początku więc eksperymentując z różnymi dodatkami pisanymi przez podobnych mi zwyrodnialców odstrzeliłem sobie stopę. Przepraszam, nie tyle stopę, co twarz. Frontview (interfejs webowy, czy też międzymordzie pajęczynowe) przestał działać po odinstalowaniu dostarczanego z systemem klienta BitTorrent (który nota bene jest dość podły). Tu akurat błąd ze strony producentów, którzy chyba nie wpadli na to, że klient może nie chcieć ich bezgranicznej dobroci i samemu zrobić sobie dobrze. Ponieważ wcześniej nie aktywowałem dostępu po SSH (morał: dla własnego dobra aktywujcie SSH zaraz po zakupie NASa!) mój jedyny kontakt z ReadyNAS odbywał się po NFS oraz przy użyciu Transmission (który nie integruje się z Frontview i chodzi na innym porcie).

Jako że do oglądania por^W^W słuchania muzyki wystarczało to w zupełności (serwer UPnP chodził nieprzejęty sytuacją) nie wnikałem za bardzo w stan ReadyNASa, głównie dlatego że “po pracy sił nie miałem aby z nim pomówić” jak śpiewał poeta.

Synku, zabezpieczaj się

Warto dodać, że ReadyNAS sam w sobie posiada całkiem sporo rozwiązań dotyczących kopii zapasowych. Od najprostszych (kopiowanie na dowolne urządzenie USB podłączone do przedniego gniazda po naciśnięciu przycisku “backup”) po bardziej wyuzdane (rsync wzbudzany przez cron). Brak czasu (który jeszcze często przewinie się w niniejszej notce) sprawił jednak że ku własnej zgubie żadnego z tych rozwiązań nie zdążyłem aktywować przed zniszczeniem Frontview.

Prawdziwe problemy zaczęły się nieco później i związane były z awarią zasilania (co jest tematem samym w sobie). Dyski w macierzy to 4x500GB skonfigurowane w coś, co NetGear nazywa X-RAID i jest to z grubsza odpowiednik RAID 4. Założenie jest takie, że padnięcie jednego dysku nie powoduje utraty danych ani nie zakłóca pracy systemu. Zgodnie z prawem Murphy’iego szlag trafił więc dwa dyski.

Po takim ciosie ReadyNAS nie był w stanie dojść do siebie. Próba uruchomienia go kończyła się na napisie “Booting”, który to napis trwał wiecznie na tle bladego wyświetlacza (no dobrze, wyświetlacz jest zielony, ale nie pasowało mi to do tragizmu sytuacji).

Kolejno odlicz

Wiele nie myśląc (czasem mam wrażenie, że ja ogólnie wiele nie myślę) postanowiłem sprawdzić dyski. Pierwsze notatki:

• HD1: fdisk pokazuje tablicę partycji, partycja ext2 montuje się
• HD2: fdisk nie przyznaje się do niczego
• HD3: sytuacja analogiczna jak w przypadku HD1
• HD4: pożoga

Po podłączeniu HD4 BIOS zaczął krzyczeć, że on dalej nie pójdzie, bo SMART mu powiedział, że HD4 jest zły i skrzywdzi jego kota. Na nic zapewnienia, że będąc BIOSem nie posiada kota. Nie chciał kontynuować i już. Ostatecznie zostało to zdiagnozowane jako padnięta elektronika i odłożone na półkę “Later/Maybe”.

Dwa dobre i dwa walnięte dyski to nienajlepszy początek odzyskiwania danych. Podrapałem się po głowie (zajęło mi to kilka miesięcy jak pamiętam) i doszedłem do wniosku, że HD2 może tak naprawdę nie jest wcale tak chory na jakiego wygląda i jedynie symuluje, by wymigać się od pracy.

Taczka pełna bitów

Żeby sprawy bardziej nie pogmatwać postanowiłem zakupić dodatkowy dysk i wszelkich operacji dokonywać na obrazach, a nie na żywych dyskach. Zakupiłem więc napęd o pojemności 2TB¹, wziąłem w dłoń jedno z moich ulubionych narzędzi (dd) i zacząłem przerzucać bity niczym łopatą.

Tezą roboczą dla HD2 była awaria tablicy partycji. Jako, że ReadyNAS każdy dysk formatuje w identyczny sposób (system, swap, LVM) dla pewności porównałem tablice partycji HD1 i HD3, a następnie przekopiowałem jedną z nich na HD2. Przy pomocy losetup zamontowałem partycję systemową z HD2 — wszystko wyglądało przepięknie. Radość przepełniła me serce i z niecierpliwością wyczekiwałem chwili, gdy aktywuję wolumen LVM i odzyskam dostęp do danych.

(Nie)oczekiwany zwrot akcji

Los bywa jednak złośliwy i okazało się, że jeden z PV nie może zostać znaleziony. Zanotowałem UUID i ze smutkiem zacząłem rozmyślać co dalej. Nie mając lepszego pomysłu odpaliłem hexdump -C i popatrzyłem na wygląd tego, co uważałem za pojedyncze PV.

Na HD1 wszystko przypominało klasyczną rozbiegówkę LVM, na HD3 podobnie. HD2 natomiast prezentowało część danych zgodnie z oczekiwaniami, a część zupełnie chaotycznie (na pierwszy rzut oka). W szczególności pole zawierające UUID wypełnione było śmieciami. Czyli jednak nie tylko tablica partycji ucierpiała?

Mimo porażki, która wydawała się nieunikniona, nie poddałem się i dociekałem dalej. Dlaczego część danych jest dobra, a część nie? Oświecenie przyszło nagle i nie pamiętam już czym zostało spowodowane. Patrząc wstecz dostrzegam swoją głupotę, jednak wtedy wydawało mi się, że jestem najmądrzejszą osobą chodzącą po Ziemi.

Pójdź, dziecię, ja cię uczyć każę!

Przeanalizowałem całą sytuację do punktu, który od początku był katalizatorem mych działań: RAID 4 zapewnia ochronę przed awarią jednego z dysków poprzez zapis XORowanych danych, które potem pozwalają odtworzyć oryginał. Przecież to oczywiste!

Niewiele myśląc (aha!) spłodziłem w C Proof of Concept, czyli program, który czytał pierwsze 4kB z każdego z trzech obrazów i wypisywał na ekran ich alternatywę wykluczającą. W ten sposób odnalazłem brakujący UUID oraz spokój ducha. Teraz tylko uogólnić program tak, by zapisał wyniki do czwartego obrazu, losetup, vgchange -ay i jesteśmy w domu!

Nie tak szybko!

Jako, że zawsze miałem problemy z matematyką umknął mi fakt, że zmieszczenie 4 obrazów po 500GB na sformatowanym dysku o całkowitej pojemności 2TB może być problematyczne biorąc pod uwagę obecność na nim innych danych. Początkowy entuzjazm opadł i zacząłem się zastanawiać nad jakimś rozwiązaniem in–place (ceny dysków zdążyły w międzyczasie zdobyć Mount Everest i rozbić tam obozowisko).

Pierwszą genialną myślą było napisanie sterownika jądra, który wystawi urządzenie blokowe prezentujące XOR z podanych plików. Zacząłem nawet czytać Linux Drivers HOWTO, ale mimo wszystko wydawało mi się to strzelaniem do komara z armaty. Ostatecznie drogą plebiscytu zwyciężyło pisanie systemu plików przy użyciu Python i FUSE. Kolejny raz mina mi zrzedła, gdy losetup zapłakał, że nie ma uprawnień do wystawienia mojego oszukanego pliku jako urządzenie.

W takich sytuacjach staram się prosić o pomoc przyjaciół i na szczęście jeden z nich o imieniu strace² pokazał gdzie może być problem. FUSE nie pozwala bowiem użytkownikowi A na dostęp do systemu plików zamontowanego przez użytkownika B. Ponieważ losetup wymaga uprawnień administratora, a mój oszukiwany system plików montowałem jako użytkownik okazało się to przeszkodą.

O frabjous day! Callooh! Callay!

losetup, vgchange, fuseext2 i… moja prywatna kolekcja muzyki (kilka miesięcy rippowania płyt CD) cała i zdrowa macha do mnie radośnie. Idę się urżnąć ze szczęścia!

Post mortem

Jak znajdę czas (sic!) planuję też napisać wersję niefabularyzowaną powyższej opowieści dla informacji potomnych (czy też siebie w przyszłości). Akcja powyższego opowiadania toczyła się przez niemal równy rok.

¹ Było to w czasach, gdy dodawali takie w sklepach spożywczych do każdych zakupów powyżej 20PLN, dziś zapewne musiałbym zastawić mieszkanie i wziąć kredyt na 40 lat
² To mój i Grzegorz Bugiel wspólny znajomy, często razem rozmawialiśmy w dawnych czasach