Blog (15)
Komentarze (117)
Recenzje (0)
@redsplOdzyskiwanie danych, czyli jak (prawie) straciłem 30GB danych i weekend

Odzyskiwanie danych, czyli jak (prawie) straciłem 30GB danych i weekend

31.08.2017 | aktual.: 05.09.2017 13:41

W połowie lipca robiłem mały maintentance na moim serwerze polegający na poprawieniu skryptu PHP do wrzucania obrazków przez przeglądarkę, który po aktualizacji PHP przestał działać; Problem był całkiem prosty do rozwiązania (okazało się że tmpfs był pełny, na moim serwerze to tylko ~430mb - hehe, Raspberry Pi), ale zanim udało mi się do tego dojść, wyrządziłem całkiem dużych szkód swoim plikom.

Pierwszym moim błędem przy troubleshootingu było skopiowanie skryptu uploadującego do katalogu nazwanego temp/ - domyślnie skrypt przebywa w katalogu upload/ i wrzuca pliki do tmp/, z którego w zależności czy będę ich kiedyś potrzebował, albo przenoszę, albo zostawiam na dłuższy, bliżej nieokreślony czas (aka forever). W pewnym momencie chciałem zacząć troubleshootowanie od początku żeby spróbować naprawy w inny sposób - wykonałem komendę rm -R t<TAB>, a autouzupełnianie mnie zawiodło, przez co usunąłem katalog z około 30GB plików, które po części były ważnymi danymi.

Pierwsze co przyszło mi do głowy to odmontowanie partycji z danymi, co miało zapobiec zapisowi przypadkowych danych w miejscu w którym leżała zawartość katalog tmp/. Potem zacząłem szukać. Google pokazało mi pare małych utilów do odzyskiwania danych pod linuxa, sam zdecydowałem się na extundelete, który miał całkiem dużo pozytywnych opinii cd. poprawnego odzyskania danych.

Configuration hell

629830

Jak widać na wyżej załączonym obrazku, pozornie prosty util ma całkiem dużo opcji. Po chwili studiowania -‑help, zacząłem od ponownego zamontowania filesystemu używając `mount -o ro /dev/sda1 /mnt`, poczym wykonałem `extundelete -‑restore-directory 'recovery/' -‑restore-files '/mnt/a/tmp/'`(byłem w /home/reds/, dlatego recovery/), co po chwili wywaliło się, krzycząc o niewystarczających prawach dostępu. Aplikując sudo do początku komendy udało mi się dojść do momentu w którym narzędzie zaczyna skanować dysk, ale extundelete stwierdził, że nie będzie zapisywał danych do mojego katalogu. Po paru innych kombinacjach parametrów spróbowałem `sudo extundelete -‑restore-all /mnt/` będąc w /, co wreszcie zaczęło zapisywać odzyskane pliki do

Problems continue...

Po paru odzyskanych GB, zorientowałem się że powoli kończy mi się miejsce na karcie SD w malince. Setup z dyskami na moim serwerze zakłada, że dysk 2TB z danymi będzie podpięty zawsze i będzie miał przynajmniej pare GB wolnego miejsca, a karta SD może być mała, i wolnego miejsca prawie nie mieć. Jako iż dysk podzieliłem na jedną partycje, która w tamtym momencie była zamontowana w trybie read-only aby zapobiec dalszej korupcji danych, musiałem znaleźć sposób którym mógłbym podmontować inny dysk, najlepiej nie podłączając go fizycznie do serwera..

sshfs to the rescue!

Szybko odpaliłem swój drugi serwer docelowo przeznaczony do backupów i stworzyłem w nim katalog do którego miałaby się skopiować reszta danych, a na pierwszym zatrzymałem extundelete przez Ctrl+Z, skopiowałem aktualną wartość katalogu /RECOVERED_FILES po SCP do katalogu na drugim serwerze, podmontowałem katalog z drugiego serwera komendą `sshfs reds@192.168.250.7:/mnt/a/backups/tmprecovery /RECOVERED_FILES/mnt/b` (/RECOVERED_FILES był już pusty). Po tej operacji trzymałem kciuki, że extundelete po prostu wróci do pracy i nie zauważy różnicy.. I nie myliłem się. Wszystko szło jak z płatka, dopóki nie wywalił mi się AmiWM (zdarza się to średnio raz na dwa miesiące, że też akurat musiał teraz..), co jednocześnie zamknęło mi terminal, w którym działało sobie extundelete (po co mi screen, żyjmy na krawędzi)..

Alleluja i Sukces!

Po ponownym uruchomieniu extundelete, odzyskało ono prawie wszystkie dane z wyjątkiem dwóch plików FLAC i paru JARów, które nie miały jakiejś ogromnej wartości. Ogólnie całą operację uznaje za sukces, bo mimo mojej małej wiedzy o odzyskiwaniu danych udało mi się tego dokonać.

Kończąc chciałbym również pokazać inny przypadek w którym nie udało mi się odzyskać prawie niczego - dosłownie następnego dnia po opisywanej w tym wpisie operacji, kiedy już dowiedziałem się czemu upload nie chce działać, wykonałem polecenie `rm -R *` będąc w / zamiast w /tmp, i mimo całkiem szybkiego odpięcia zasilania od serwera, nie odzyskałem nawet połowy plików konfiguracyjnych, przez co straciłem parę kolejnych dni.

Wybrane dla Ciebie
Komentarze (12)