Historia padu pewnego dysku…

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…