Diagnostyka dysku Linux - SMART, fsck, badblocks. Zobacz jak!

Dobry program do sprawdzania dysków powinien robić dwie rzeczy: szybko pokazać stan nośnika i nie mylić awarii sprzętowej z błędami systemu plików. W praktyce najczęściej potrzebujesz nie jednego narzędzia, tylko zestawu: SMART do oceny kondycji, testu powierzchni do wykrywania wadliwych bloków oraz fsck albo jego odpowiednika do naprawy struktur danych. To właśnie od tego rozróżnienia zależy, czy jeszcze uratujesz dane bez stresu, czy lepiej od razu przenieść je w bezpieczne miejsce.

Co naprawdę ma sprawdzać narzędzie do diagnostyki dysków

Ja rozdzielam diagnostykę na trzy poziomy, bo tylko wtedy wynik ma znaczenie. Pierwszy poziom to kondycja nośnika, czyli SMART: liczba godzin pracy, temperatura, błędy odczytu, sektory przeniesione w bezpieczne miejsce i testy wewnętrzne. Drugi poziom to powierzchnia dysku, czyli pytanie, czy da się bezbłędnie odczytać każdy blok. Trzeci poziom to system plików, czyli struktura, którą widzi system operacyjny, gdy montuje partycję.

To ważne, bo objawy często się mieszają. Dysk może mieć zdrowy SMART, a mimo to uszkodzony system plików po nagłym wyłączeniu zasilania. Zdarza się też odwrotnie: system plików da się naprawić, ale nośnik już sypie błędami i przy kolejnym obciążeniu problem wróci. Jeśli chcesz podejść do sprawy rozsądnie, najpierw ustal, co dokładnie chcesz sprawdzić, a dopiero potem wybieraj narzędzie.

Właśnie dlatego jedno uniwersalne narzędzie zwykle nie wystarcza. SMART daje szybki sygnał ostrzegawczy, badblocks pokazuje problemy z powierzchnią, a fsck naprawia to, co dzieje się na poziomie metadanych. Dzięki temu kolejne kroki stają się logiczne, a nie przypadkowe. Następny etap to wybór programu dopasowanego do konkretnego problemu.

Jakie narzędzie wybrać do konkretnego problemu

Jeśli ktoś pyta mnie o praktyczny zestaw, zwykle odpowiadam: zależy od objawu i od rodzaju nośnika. Na Linuksie sprawa jest prosta tylko pozornie, bo inne narzędzie bierzesz do dysku SATA, inne do NVMe, a jeszcze inne do naprawy systemu plików. Poniższa tabela porządkuje ten wybór.

W praktyce na Linuksie najczęściej kończy się to na połączeniu smartctl, badblocks i fsck. Reszta to dodatki zależne od rodzaju dysku i systemu operacyjnego. Jeśli chcesz działać bez zgadywania, przejdź od najlżejszego testu do najcięższego.

Jak przeprowadzam diagnostykę na Linuksie krok po kroku

1. Zidentyfikuj właściwe urządzenie

Zanim cokolwiek uruchomisz, sprawdź, jak system widzi nośnik. To banalny krok, ale właśnie tutaj najłatwiej popełnić kosztowny błąd. Przy SATA często zobaczysz urządzenia w stylu /dev/sda, /dev/sdb, a przy NVMe zwykle /dev/nvme0n1 albo sam kontroler /dev/nvme0.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL

Ten widok od razu pokazuje, co jest zamontowane, jaki ma rozmiar i gdzie fizycznie siedzi partycja. Ja zawsze zaczynam od tego, bo test na złym urządzeniu nie wybacza pomyłek.

2. Odczytaj SMART albo log NVMe

Jeśli dysk odpowiada, od razu sprawdzam jego stan. Dla SATA i SAS używam SMART, dla NVMe sięgam po logi specyficzne dla tego standardu. To daje najszybszy obraz sytuacji.

smartctl -a /dev/sdX
nvme smart-log /dev/nvme0

Szukam przede wszystkim temperatury, liczby godzin pracy, błędów odczytu, informacji o sektorach przeniesionych do obszaru zapasowego oraz wyników wcześniejszych testów. W NVMe zwracam uwagę na błędy nośnika, procent zużycia i ostrzeżenia krytyczne. Jeśli tutaj widzę wyraźny trend pogarszania się parametrów, nie czekam na kolejne objawy.

3. Uruchom krótki test samokontroli

Krótki test jest dobrym kompromisem między szybkością a użytecznością. Nie zastępuje pełnej diagnozy, ale bardzo często pozwala szybko potwierdzić, że coś jest nie tak.

smartctl -t short /dev/sdX

Po kilku minutach sprawdzam wynik:

smartctl -l selftest /dev/sdX

Jeśli test zwraca błędy albo zawiesza się w połowie, traktuję to jako sygnał ostrzegawczy, a nie drobiazg. Krótki self-test nie mówi wszystkiego, ale zwykle wystarcza, by zdecydować, czy warto iść dalej.

4. Zrób pełniejszy test powierzchni tylko wtedy, gdy ma to sens

Pełny skan powierzchni uruchamiam wtedy, gdy potrzebuję wiedzieć, czy nośnik ma fizycznie uszkodzone bloki. Na istniejących danych bezpieczniejszy jest tryb tylko do odczytu, a testy zapisowe zostawiam dla sytuacji, w których naprawdę rozumiem ryzyko. Na SSD podchodzę do tego ostrożniej niż na HDD, bo długie zapisy nie są obojętne dla zużycia.

sudo badblocks -sv /dev/sdX

Jeśli potrzebujesz głębszego, ale nadal niedestrukcyjnego testu, możesz użyć trybu -n:

sudo badblocks -nsv /dev/sdX

To wolniejsze, ale bezpieczniejsze dla danych. Z kolei tryb zapisowy -w czyści zawartość dysku, więc stosuje się go wyłącznie na nośniku bez cennych danych. Tu nie ma miejsca na improwizację.

Przeczytaj również: Conti ransomware - Anatomia i ochrona przed nowymi zagrożeniami

5. Sprawdź system plików, jeśli problem dotyczy montowania

Gdy wolumin nie montuje się, system zgłasza błędy po restarcie albo katalogi znikają, sprawdzam najpierw strukturę systemu plików. Dla ext2, ext3 i ext4 używam narzędzi z pakietu e2fsprogs, a sam fsck działa jako front-end dla odpowiedniego sprawdzarki.

sudo fsck -f /dev/sdX1
sudo e2fsck -f /dev/sdX1

Ważne: partycja musi być odmontowana. Jeśli system plików jest zamontowany, ryzykujesz pogłębienie uszkodzeń. W przypadku innych systemów plików zasada jest podobna, ale narzędzie bywa inne. Nie warto zgadywać, bo łatwo naprawiać nie ten poziom, na którym faktycznie leży problem.

Po tych krokach zwykle wiadomo już, czy walczysz z kondycją nośnika, czy z metadanymi systemu plików. To dobra chwila, żeby nauczyć się poprawnie interpretować wyniki.

Jak czytać wyniki i nie wyciągać złych wniosków

Najczęstszy błąd to patrzenie na jeden parametr w izolacji. SMART nie działa jak prosty licznik „dobry-zły”; ważniejszy jest trend i kontekst. Jeśli atrybuty pogarszają się z tygodnia na tydzień, to znaczy więcej niż pojedyncza wartość, która przekroczyła oczekiwania po nagłym zaniku zasilania.

• Reallocated Sectors i Pending Sectors traktuję poważnie, bo oznaczają problemy z zapisem lub odczytem z konkretnego miejsca na talerzu albo pamięci flash.
• Uncorrectable Errors to sygnał, że nośnik nie poradził sobie z odzyskaniem danych bez błędu.
• CRC Errors często wskazują nie na sam dysk, lecz na kabel, port SATA, adapter USB albo kontroler.
• Self-test passed nie oznacza, że dysk jest zdrowy. Oznacza tylko, że dany test niczego nie wykrył.
• W NVMe zwracam uwagę także na media errors i komunikaty ostrzegawcze związane z zużyciem nośnika.

Jeśli SMART jest w miarę czysty, a system plików sypie błędami, podejrzewam też zasilanie, RAM albo połączenie. Z kolei jeśli testy zwracają coraz więcej błędów po każdym uruchomieniu, to nie jest moment na dalsze eksperymenty. Właśnie tu najłatwiej odróżnić realną awarię od jednorazowego incydentu.

Najczęstsze błędy, które psują diagnozę

Na papierze diagnoza dysku wygląda prosto. W praktyce większość pomyłek bierze się z pośpiechu, złego doboru testu albo zaufania do pierwszego komunikatu, który pojawił się na ekranie. Ja najczęściej widzę te same błędy:

• Uruchamianie ciężkich testów na zamontowanej partycji, mimo że narzędzie wyraźnie ostrzega przed ryzykiem.
• Mylenie błędu systemu plików z awarią nośnika i odwrotnie.
• Stawianie wyroku po jednym parametrze SMART bez spojrzenia na resztę danych.
• Ignorowanie kabla SATA, obudowy USB lub przejściówki, które potrafią generować błędy nie do odróżnienia od problemu dysku.
• Wykonywanie zapisu testowego na dysku z jedyną kopią ważnych plików.
• Zakładanie, że jeśli system się uruchamia, to nośnik jest bezpieczny.

Najgroźniejszy jest zwykle ostatni punkt. Dysk potrafi działać „prawie normalnie” jeszcze przez kilka dni, a potem nagle przestać odpowiadać. Dlatego przy pierwszych niepokojących objawach zawsze myślę najpierw o kopii, a dopiero potem o kolejnych testach.

Kiedy przestać testować i po prostu ratować dane

Są sytuacje, w których dalsza diagnostyka nie poprawi sytuacji, tylko ją pogorszy. Jeśli słyszysz klikanie głowic, system znika z listy urządzeń, odczyt zawiesza się na tych samych plikach albo liczba błędów rośnie z każdym kolejnym testem, to sygnał, żeby przerwać eksperymenty. Wtedy priorytetem staje się zabezpieczenie danych, nie „dociśnięcie” nośnika kolejnym skanem.

Jeśli dysk jeszcze odpowiada, kopiuję najpierw najważniejsze katalogi, a przy trudniejszych przypadkach sięgam po narzędzia do ratowania nośników, takie jak ddrescue. To narzędzie nie naprawia dysku, ale pomaga odzyskać możliwie dużo danych mimo błędów odczytu. Potem nośnik wymieniam, bo jeśli objawy wracają, dalsze testy są już tylko przedłużaniem problemu.

Warto też pamiętać o jednym wyjątku: przy dyskach zewnętrznych winna bywa sama obudowa, przewód albo port. Jeśli po zmianie kabla i portu problem znika, nie wymieniaj odruchowo całego nośnika. To detal, ale często oszczędza pieniądze i czas.

Co trzymam zainstalowane, zanim dysk zacznie się sypać

Najwygodniej działać wtedy, gdy nie trzeba niczego doinstalowywać w panice. Na Linuksie trzymam pod ręką kilka pakietów, bo razem dają pełny obraz sytuacji i pozwalają szybko zareagować.

• smartmontools - do SMART, self-testów i monitoringu przez smartd.
• nvme-cli - do logów i diagnostyki dysków NVMe.
• e2fsprogs - do fsck, e2fsck i testów powiązanych z ext2/ext3/ext4.
• gddrescue - do ratowania danych z nośników, które już zgłaszają błędy odczytu.
• regularny backup - bo to jedyne narzędzie, które naprawdę wygrywa z awarią dysku.

Jeśli miałbym wskazać jeden ruch o największym zwrocie, to byłoby nim włączenie regularnego monitoringu SMART i ustawienie kopii zapasowej zanim pojawi się pierwszy alert. Narzędzia diagnostyczne są ważne, ale największą różnicę robi przygotowanie systemu na dzień, w którym dysk zacznie się zachowywać gorzej niż zwykle. I właśnie to, a nie jednorazowy test, daje spokój na dłużej.