Jog Jajcusia

Historia padu pewnego dysku...

18 kwietnia 2005 22:03:55 | kategorie: oprogramowanie, praca, sprzęt,

W piątek rano jeden z naszych serwerów nagle przestał odpowiadać, nawet na konsoli szeregowej. Kumpel przeszedł się na serwerownie zobaczyć co jest. Komputer nie reagował, a po resecie nie widział jednego dysku (tego z którego miał się startować system). Uznałem, że dysk mógł się zawiesić na twardo i zaproponowałem odłączenie komputera całkowicie z zasilania na chwilę. Po tej operacji system wystartował normalnie z właściwego dysku.

Jak już system działał postanowiłem dyskom bliżej się przyjrzeć. smartctl -a stwierdził OK. scsinfo -a nie wykazało żadnych bad sektorów. Zapuściłem jeszcze SMART Extended Self Test i uznałem, że problem został zażegnany. Niestety po chwili serwer zaczął się zachowywać dziwnie. Dawał błąd read-only filesystem przy dowolnej próbie zapisu na głównej partycji. W logach było jedynie nic nie mówiące Journal aborted. Gdy chciałem sprawę bliżej zbadać, okazało się, że bash nie widzi podstawowych binarek. Jakież było moje zdumienie, gdy się okazało, że ls -l / nie pokazuje nic. Ale już np. ls -l /bin/ls pokazywało poprawne informacje o pliku. Nie było co się więcej zastanawiać, tylko downować serwer i lecieć na serwerownię.

Na serwerowni powtórzyliśmy operację, która poprzednio przywróciła maszynę do życia. Bez skutku — system już nie startował z tego dysku. Co prawda, BIOS kontrolera widział dysk, ale z Media format error i go od razu wyłączał. Wyciągnęliśmy więc serwer z szafy i zanieśliśmy do biura.

Dysk podłączony do innej maszyny też nie działał, więc zabraliśmy się za ratowanie systemu, wykorzystując to co zostało. Na szczęście okazało się, że większość najistotniejszych plików (/var i /home) leży na drugim, ocalałym dysku. Znalazło się też tam miejsce na odtworzenie / + /usr z backupu.

Backupy wszystkich naszych serwerów zapisujemy na tasiemkach przy pomocy oprogramowania Bacula (It comes by night and sucks the vital essence from your computers.). Ten wspaniały zestaw narzędzi pozwala nam zdalne backupowanie wszystkich systemów na jednym streamerze, zachowując informacje o tym co, gdzie i kiedy zostało zarchiwizowane. Niestety okazało się, że przy odtwarzaniu z tych kopii zapasowych to już nie działa tak ładnie...

Pierwszy problem to to, że gdy Bacula skończył odtwarzanie z jednej tasiemki, to nie poprosił o włożenie kolejnej, tylko wszedł w jakiś dziwny stan w którym nic nie mógł przeczytać, ani nie dało się kasetki wyciągnąć. Dało się to obejść rozpoczynając kolejny proces odtwarzania, tylko danych z tej drugiej (chronologicznie pierwszej) tasiemki.

Gorszy był drugi problem. Odtwarzanie przerwało się gdzieś w środku (na jakimś /dev/rd/cośtam. Puściłem jeszcze raz, omijając dane już odtworzone, oraz katalog na którym się wywalił. Niby wszystko odzyskaliśmy, ale okazało się, że prawa dostępu do wielu katalogów, utworzonych w tym przerwanym procesie, są co najmniej dziwne. Np. 744 na /usr albo 777 na /usr/local/bin. Udało się to jednak RPMem do porządku doprowadzić. Ostatecznie udało się, jeszcze w piątek, uruchomić na serwerze podstawowe usługi, w tym Jabbera i pocztę, bez żadnych strat w danych.

Od razu, gdy stwierdziliśmy, że dysk padł, zamówiliśmy nowy. Była pewna szansa, że przyjdzie w sobotę i plan, żeby w tę sobotę odzyskać resztę systemu (w tym builder AMD64 dla PLD). Jak nie w sobotę, to w poniedziałek od rana. Dysk przyszedł w poniedziałek (dzisiaj), ale dopiero w południe. Spartycjonowałem go, założyłem wolumeny LVM i przegrałem większość danych z tego ocalałego dysku. Zacząłem też odtwarzanie pozostałych danych z backupu. Wszystko w trybie single, aby działające usługi (w tym Jabber i poczta) nie nabruździły mi w tym. Niestety odtwarzanie z backupu nie zdążyło się skończyć przed moim wyjściem z pracy. Koledzy zostali w pracy, aby po zakończeniu operacji przywrócić serwer do życia. Niestety Bacula znów się wywalił. Serwer działa (tyle co w piątek udało się odpalić), ale część danych wciąż nie jest odzyskana. Jutro będę miał jeszcze z tym sporo roboty...