smartctl i smartmontools: Kompletny przewodnik po monitorowaniu stanu dysków w Linux

smartctl to główny interfejs wiersza poleceń pakietu smartmontools, zaprojektowany do odpytywania, testowania i interpretowania danych S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) wbudowanych w oprogramowanie układowe HDD, SSD i dysków NVMe. Komunikuje się bezpośrednio z oprogramowaniem układowym dysku przez interfejsy ATA, SCSI lub NVMe, aby udostępniać surową diagnostyczną telemetrię, której sam system operacyjny nie eksponuje przez standardowe ścieżki I/O.

Dla każdego administratora Linux zarządzającego fizyczną lub wirtualną pamięcią masową — czy to na serwerze bare-metal, Serwerze Dedykowanym, czy lokalnie podłączonej macierzy dyskowej — smartctl jest jedynym najbardziej niezawodnym narzędziem do wykrywania zbliżającej się awarii dysku, zanim spowoduje nieodwracalną utratę danych.

Czym jest S.M.A.R.T. i dlaczego ma znaczenie

S.M.A.R.T. to system monitorowania wbudowany praktycznie w każde konsumenckie i korporacyjne urządzenie pamięci masowej wyprodukowane po 1996 roku. Działa na poziomie oprogramowania układowego, stale śledząc dziesiątki wewnętrznych parametrów: wskaźniki błędów odczytu/zapisu, wskaźniki naprężeń mechanicznych, poziomy zużycia NAND, liczniki realokowanych sektorów i odczyty termiczne.

Kluczowa różnica, którą pomija większość poradników: dane S.M.A.R.T. mają charakter predykcyjny, nie reaktywny. Dysk może przejść sprawdzenie systemu plików i normalnie obsługiwać I/O, jednocześnie gromadząc realokowane sektory w tempie, które statystycznie przewiduje awarię w ciągu kilku tygodni. smartctl ujawnia ten ukryty stan degradacji.

S.M.A.R.T. działa w trzech rodzinach interfejsów pamięci masowej:

• ATA/SATA — oryginalna specyfikacja S.M.A.R.T., najbogatsza w atrybuty
• SCSI/SAS — używa innego modelu atrybutów (strony dziennika wyjątków informacyjnych)
• NVMe — udostępnia dane o stanie zdrowia przez dziennik informacji o stanie NVMe (Log Page 0x02), z metrykami takimi jak dostępna pojemność zapasowa, procent wykorzystania i niebezpieczne wyłączenia

Instalacja smartmontools w systemie Linux

Pakiet smartmontools jest dostępny w oficjalnych repozytoriach każdej głównej dystrybucji Linux. Zainstaluj wersję odpowiednią dla swojego środowiska:

Debian / Ubuntu:

“`bash

sudo apt-get update && sudo apt-get install smartmontools

“`

CentOS / RHEL 7:

“`bash

sudo yum install smartmontools

“`

CentOS Stream / RHEL 8+ / AlmaLinux / Rocky Linux:

“`bash

sudo dnf install smartmontools

“`

Fedora:

“`bash

sudo dnf install smartmontools

“`

Arch Linux:

“`bash

sudo pacman -S smartmontools

“`

openSUSE:

“`bash

sudo zypper install smartmontools

“`

Po instalacji sprawdź wersję i potwierdź, że obsługa NVMe jest skompilowana:

“`bash

smartctl –version

“`

Poszukaj `NVMe` na liście obsługiwanych typów urządzeń. Wersje wcześniejsze niż 6.6 mają niekompletną obsługę NVMe — na nowoczesnych serwerach z dyskami NVMe SSD upewnij się, że używasz smartmontools 7.x lub nowszego.

Identyfikacja urządzeń pamięci masowej

Przed uruchomieniem jakiegokolwiek polecenia smartctl zidentyfikuj właściwy węzeł urządzenia. Pomylenie identyfikatorów urządzeń w systemie wielodyskowym jest częstym i kosztownym błędem.

“`bash

lsblk -d -o NAME,SIZE,MODEL,TRAN

“`

Polecenie to wyświetla nazwy urządzeń wraz z typem transportu (sata, nvme, usb), co bezpośrednio informuje, jakich flag smartctl będziesz potrzebować. W przypadku urządzeń NVMe węzeł będzie widoczny jako `/dev/nvme0`, `/dev/nvme1` itd. — nie `/dev/sdX`.

W przypadku sprzętowych kontrolerów RAID (LSI MegaRAID, Adaptec, HP Smart Array) dyski są ukryte za kontrolerem i wymagają jawnych flag pass-through, omówionych w sekcji zaawansowanej poniżej.

Podstawowe polecenia smartctl

Wyświetlanie informacji o tożsamości urządzenia

“`bash

sudo smartctl -i /dev/sda

“`

Polecenie to odpytuje stronę IDENTIFY DATA urządzenia i zwraca numer modelu, numer seryjny, wersję oprogramowania układowego, pojemność, rozmiar sektora (512-bajtowy logiczny vs. 4096-bajtowy fizyczny — ważne dla wyrównania) oraz flagi możliwości S.M.A.R.T. Na urządzeniach NVMe:

“`bash

sudo smartctl -i /dev/nvme0

“`

Przeprowadzanie pełnej oceny stanu zdrowia

“`bash

sudo smartctl -H /dev/sda

“`

Zwraca jednowierszowy werdykt: `PASSED` lub `FAILED`. Wynik `FAILED` oznacza, że własne oprogramowanie układowe dysku ustaliło, że przekroczono jeden lub więcej krytycznych progów. Dysk zgłaszający FAILED należy traktować jako uszkodzony — nie czekaj na dalsze potwierdzenie.

Jednak wynik `PASSED` nie oznacza, że dysk jest sprawny. Oznacza jedynie, że żaden próg nie został formalnie przekroczony. Dlatego analiza surowych atrybutów jest niezbędna.

Wyświetlanie wszystkich atrybutów S.M.A.R.T.

“`bash

sudo smartctl -A /dev/sda

“`

Jest to polecenie o największej gęstości informacji w codziennym użyciu. Tabela wynikowa zawiera kilka kolumn wymagających precyzyjnej interpretacji:

RAW_VALUE to wartość, którą należy przede wszystkim analizować. Znormalizowany system VALUE/WORST/THRESH jest przydatny do automatycznego wykrywania progów, ale może być mylący — niektórzy producenci stosują niestandardowe krzywe normalizacji.

Kompleksowe wyjście: łączenie flag

Aby uzyskać pełny obraz w jednym poleceniu, połącz flagi informacji, stanu zdrowia i atrybutów:

“`bash

sudo smartctl -a /dev/sda

“`

Mała litera `-a` jest odpowiednikiem `-H -i -c -A -l error -l selftest`. Jest to standardowe polecenie do uruchomienia podczas diagnozowania nieznanego dysku.

Dla jeszcze bardziej szczegółowego wyjścia zawierającego wszystkie strony dziennika:

“`bash

sudo smartctl -x /dev/sda

“`

Krytyczne atrybuty S.M.A.R.T. i sposób ich interpretacji

Nie wszystkie atrybuty S.M.A.R.T. mają jednakową wagę diagnostyczną. Poniżej przedstawiono atrybuty, które doświadczeni inżynierowie pamięci masowej traktują jako podstawowe wskaźniki awarii:

Wskaźniki awarii o wysokim priorytecie

Reallocated_Sector_Ct (ID 5)

Liczba sektorów, które dysk przemapował do obszaru zapasowego z powodu błędów odczytu/zapisu/weryfikacji. Jakakolwiek niezerowa wartość na dysku poniżej dwóch lat wymaga natychmiastowej uwagi. Stale rosnąca liczba — nawet od 1 do 5 w ciągu miesiąca — jest silnym predyktorem zbliżającej się awarii. Na dyskach korporacyjnych niewielka liczba może być akceptowalna w zależności od specyfikacji producenta.

Current_Pending_Sector (ID 197)

Sektory oznaczone jako niestabilne i oczekujące na przemapowanie. Sektory te spowodowały błędy podczas odczytu, ale nie zostały jeszcze pomyślnie przemapowane. Niezerowa wartość oznacza, że dysk aktywnie zmaga się z odczytem danych. Jeśli oczekujący sektor zostanie następnie pomyślnie zapisany, może zostać przemapowany lub wyczyszczony — ale podstawowe medium jest podejrzane.

Uncorrectable_Sector_Count (ID 198) / Offline_Uncorrectable

Sektory, których nie można było poprawić przez ECC i których nie można było przemapować. Jest to najpoważniejszy atrybut. Niezerowa wartość oznacza, że dane zostały już utracone z tych sektorów. Jedyną właściwą odpowiedzią jest natychmiastowe wykonanie kopii zapasowej i wymiana dysku.

Reported_Uncorrect (ID 187)

Na nowoczesnych dyskach zlicza błędy, których wewnętrzny ECC dysku nie mógł poprawić. Wysokie wartości wskazują na poważną degradację nośnika.

Spin_Retry_Count (ID 10)

W przypadku HDD — wielokrotne niepowodzenia przy rozpędzaniu talerzy do prędkości roboczej. Wskazuje na naprężenia mechaniczne silnika wrzeciona lub łożysk. Jakakolwiek niezerowa wartość na intensywnie używanym dysku jest sygnałem alarmowym.

Command_Timeout (ID 188)

Liczba poleceń, które zostały przerwane z powodu przekroczenia limitu czasu. Podwyższone wartości często wskazują na problemy z interfejsem (kabel, kontroler lub zasilanie), a nie na awarię nośnika — ale mogą również poprzedzać całkowitą awarię dysku.

Atrybuty monitorowania drugorzędnego

Raw_Read_Error_Rate (ID 1)

Często błędnie interpretowany: na dyskach Seagate ten atrybut ma z założenia bardzo wysoką wartość surową, ponieważ reprezentuje współczynnik zakodowany w 48-bitowym polu. Surowa wartość kilku milionów na dysku Seagate jest normalna. Na dyskach Western Digital i innych producentów wartość surowa powinna być bliska zeru. Zawsze sprawdzaj dokumentację producenta przed alarmowaniem na podstawie tego atrybutu.

Power_On_Hours (ID 9)

Łączna liczba godzin pracy. Konsumenckie HDD są zazwyczaj oceniane na 20 000–25 000 godzin (około 2–3 lata ciągłej pracy). Dyski korporacyjne są oceniane na 55 000+ godzin. Używaj tego do kontekstualizacji innych wartości atrybutów.

Temperature_Celsius (ID 194)

Aktualna temperatura dysku. Optymalny zakres pracy dla większości HDD wynosi 25–45°C. Utrzymujące się temperatury powyżej 55°C przyspieszają zużycie łożysk i degradację magnetycznego nośnika. W przypadku SSD tolerancja termiczna jest generalnie wyższa, ale utrzymujące się temperatury powyżej 70°C przyspieszą zużycie NAND. Na serwerach bez odpowiedniego przepływu powietrza — częsty problem w gęstych wdrożeniach rack — dławienie termiczne może maskować się jako opóźnienie I/O, zanim atrybut temperatury przekroczy jakikolwiek formalny próg.

Wear_Leveling_Count (ID 177) / Media_Wearout_Indicator (ID 233)

Atrybuty specyficzne dla SSD śledzące zużycie wytrzymałości NAND. Gdy znormalizowana wartość VALUE zbliża się do wartości THRESH, SSD zbliża się do swojej ocenionej wytrzymałości zapisu. Planuj wymianę z wyprzedzeniem.

Power_Cycle_Count (ID 12)

Częste cykle zasilania powodują naprężenia mechaniczne na HDD (parkowanie/odparkowanie głowic, naprężenia silnika wrzeciona) i w mniejszym stopniu naprężenia elektryczne na SSD. Niezwykle wysokie liczniki w stosunku do Power_On_Hours mogą wskazywać na niestabilne środowisko zasilania.

Uruchamianie diagnostycznych testów własnych

Testy własne S.M.A.R.T. są wykonywane przez własne oprogramowanie układowe dysku, a nie przez system operacyjny. Dysk nadal obsługuje I/O podczas testowania (z niewielkim wpływem na wydajność), co sprawia, że testy te są bezpieczne do uruchomienia na systemach produkcyjnych.

Krótki test własny

“`bash

sudo smartctl -t short /dev/sda

“`

Czas trwania: zazwyczaj 1–5 minut. Testuje komponenty elektryczne i mechaniczne oraz niewielki procent powierzchni dysku. Przydatny do szybkiego sprawdzenia poprawności. Wyniki po zakończeniu:

“`bash

sudo smartctl -l selftest /dev/sda

“`

Długi test własny (test rozszerzony)

“`bash

sudo smartctl -t long /dev/sda

“`

Czas trwania: proporcjonalny do pojemności dysku — oczekuj około 1 godziny na terabajt dla typowego HDD 7200 RPM i 20–60 minut dla większości SSD. Wykonuje kompletne skanowanie powierzchni każdego sektora. Jest to definitywny test do wykrywania uszkodzonych sektorów na całej powierzchni nośnika.

Monitorowanie postępu bez oczekiwania na zakończenie:

“`bash

sudo smartctl -c /dev/sda

“`

Wyjście zawiera procent ukończenia i szacowany czas zakończenia.

Test własny Conveyance

“`bash

sudo smartctl -t conveyance /dev/sda

“`

Dostępny na większości dysków ATA. Zaprojektowany do wykrywania uszkodzeń powstałych podczas transportu lub fizycznej obsługi. Sprawdza problemy spowodowane wstrząsem mechanicznym. Czas trwania wynosi zazwyczaj 5 minut. Ten test jest niedostatecznie wykorzystywany — jest szczególnie cenny przy uruchamianiu nowego sprzętu lub po fizycznym przeniesieniu serwera.

Selektywny test własny

“`bash

sudo smartctl -t select,0-1000000 /dev/sda

“`

Umożliwia testowanie określonego zakresu LBA zamiast całego dysku. Nieoceniony, gdy sprawdzenia systemu plików wskazały błędy w określonym regionie i musisz potwierdzić, czy odpowiedzialne jest podstawowe medium.

Monitorowanie stanu zdrowia specyficzne dla NVMe

Dyski NVMe używają zasadniczo innego modelu atrybutów. Podstawowe polecenie stanu zdrowia:

“`bash

sudo smartctl -a /dev/nvme0

“`

Kluczowe pola specyficzne dla NVMe do monitorowania:

• Available Spare: Procent pozostałych zapasowych bloków NAND. Poniżej 10% wymaga planowania wymiany.
• Available Spare Threshold: Zdefiniowany przez producenta próg, poniżej którego dysk może zgłaszać obniżoną niezawodność.
• Percentage Used: Szacowany procent zużytej ocenionej wytrzymałości zapisu. Przy 100% dysk osiągnął swój oceniony TBW (Terabajty Zapisane) — może nadal działać, ale gwarancje niezawodności nie mają już zastosowania.
• Data Units Read / Written: Skumulowane I/O w jednostkach 512 000 bajtów. Przydatne do obliczania rzeczywistego obciążenia pracą vs. oceniony TBW.
• Media and Data Integrity Errors: Nieodzyskane błędy nośnika lub błędy integralności danych wykryte przez kontroler NVMe. Jakakolwiek niezerowa wartość jest poważna.
• Number of Error Information Log Entries: Liczba wpisów dziennika błędów. Szybko rosnąca liczba wskazuje na trwałe problemy.
• Power State: Aktualny stan zasilania NVMe — istotny dla obciążeń wrażliwych na opóźnienia, gdzie dysk może znajdować się w głębokim stanie oszczędzania energii.

Sprzętowy RAID i dostęp pass-through

Gdy dyski są podłączone przez sprzętowy kontroler RAID, system operacyjny widzi wirtualny dysk kontrolera, a nie fizyczne dyski. smartctl wymaga jawnego pass-through, aby dotrzeć bezpośrednio do oprogramowania układowego dysku.

LSI MegaRAID:

“`bash

sudo smartctl -a /dev/sda -d megaraid,0

sudo smartctl -a /dev/sda -d megaraid,1

“`

HP Smart Array (sterownik hpsa):

“`bash

sudo smartctl -a /dev/sda -d cciss,0

“`

3ware RAID:

“`bash

sudo smartctl -a /dev/twa0 -d 3ware,0

“`

Jeśli nie jesteś pewien, którego typu pass-through użyć, smartctl może próbować automatycznego wykrywania:

“`bash

sudo smartctl –scan

“`

Skanuje wszystkie wykrywalne urządzenia pamięci masowej i wyświetla zalecaną ścieżkę urządzenia oraz flagę typu dla każdego z nich.

Włączanie i wyłączanie S.M.A.R.T.

S.M.A.R.T. jest domyślnie włączony praktycznie na wszystkich nowoczesnych dyskach. W rzadkich przypadkach — zazwyczaj starsze dyski lub niektóre zwirtualizowane środowiska — może być wyłączony:

“`bash

sudo smartctl -s on /dev/sda

“`

Aby wyłączyć (niezalecane z wyjątkiem określonych scenariuszy testowych):

“`bash

sudo smartctl -s off /dev/sda

“`

Uwaga: W zwirtualizowanych środowiskach takich jak KVM lub VMware, pass-through S.M.A.R.T. do gościnnych maszyn wirtualnych zależy od konfiguracji hiperwizora. W środowisku VPS Hosting hiperwizor zazwyczaj abstrahuje fizyczny dysk, a smartctl wewnątrz gościa może zwracać ograniczone lub żadne dane. Aby uzyskać pełny dostęp S.M.A.R.T., wymagane jest monitorowanie na poziomie fizycznego hosta lub Serwer Dedykowany.

Automatyczne monitorowanie za pomocą smartd

Demon smartd to komponent klasy produkcyjnej pakietu smartmontools. Działa w tle, okresowo odpytując dyski i wykonując zaplanowane testy, a następnie powiadamiając administratorów, gdy progi są przekraczane lub testy kończą się niepowodzeniem.

Konfiguracja /etc/smartd.conf

Domyślna konfiguracja monitoruje wszystkie wykryte dyski z podstawowymi ustawieniami. Konfiguracja wzmocniona dla środowiska produkcyjnego wygląda następująco:

“`

Monitor all ATA/SCSI/NVMe drives with full attribute checking

Run short test every day at 02:00, long test every Saturday at 03:00

Email alert on any failure or attribute change

DEVICESCAN -a -o on -S on

-s (S/../.././02|L/../../6/03)

-m admin@yourdomain.com

-M exec /usr/share/smartmontools/smartd-runner

“`

Wyjaśnienie kluczowych dyrektyw:

Włączanie i uruchamianie smartd

“`bash

sudo systemctl enable smartd

sudo systemctl start smartd

sudo systemctl status smartd

“`

Sprawdź, czy demon aktywnie monitoruje:

“`bash

sudo journalctl -u smartd -f

“`

Konfiguracja alertów e-mail

Aby alerty e-mail smartd działały, system wymaga działającego MTA (agenta transferu poczty). Na minimalnych instalacjach serwerowych zainstaluj i skonfiguruj `postfix` lub `msmtp` do przekazywania. Jeśli używasz dedykowanej infrastruktury pocztowej, rozważ połączenie alertów smartd z odpowiednio skonfigurowaną usługą Email Hosting, aby zapewnić, że dostarczanie alertów nie jest blokowane przez filtry antyspamowe.

Porównanie atrybutów S.M.A.R.T.: HDD vs. SSD vs. NVMe

Praktyczny przepływ pracy: diagnozowanie podejrzanego dysku

Gdy dysk wykazuje objawy — błędy I/O w `dmesg`, uszkodzenie systemu plików, nietypowe opóźnienia — postępuj zgodnie z tą sekwencją diagnostyczną:

Krok 1: Potwierdź dostępność S.M.A.R.T.

“`bash

sudo smartctl -i /dev/sda | grep -i "SMART support"

“`

Krok 2: Sprawdź ogólny werdykt stanu zdrowia

“`bash

sudo smartctl -H /dev/sda

“`

Krok 3: Sprawdź dziennik błędów

“`bash

sudo smartctl -l error /dev/sda

“`

Dziennik błędów rejestruje ostatnie 5 błędów ATA z sygnaturami czasowymi i adresami LBA. Porównaj adresy LBA z mapami bloków systemu plików używając `debugfs` lub `xfs_db`, aby określić, czy błędy dotyczą krytycznych struktur systemu plików.

Krok 4: Analizuj krytyczne atrybuty

“`bash

sudo smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|Command_Timeout"

“`

Krok 5: Uruchom krótki test w celu natychmiastowego potwierdzenia

“`bash

sudo smartctl -t short /dev/sda

sleep 120

sudo smartctl -l selftest /dev/sda

“`

Krok 6: Jeśli krótki test przejdzie pomyślnie, a objawy utrzymują się, uruchom długi test podczas okna konserwacyjnego

“`bash

sudo smartctl -t long /dev/sda

“`

Krok 7: Przejrzyj dziennik testów własnych pod kątem adresów LBA awarii

“`bash

sudo smartctl -l selftest /dev/sda

“`

Nieudane testy raportują LBA pierwszego napotkanego błędu. Pozwala to dokładnie zlokalizować miejsce uszkodzenia nośnika.

Typowe pułapki i przypadki brzegowe

Dyski podłączone przez USB: smartctl często nie może komunikować się z dyskami podłączonymi przez adaptery USB-to-SATA, ponieważ układ mostka USB nie przekazuje poleceń ATA. Użyj flagi `-d sat` lub `-d usb` albo jawnie określ typ mostka (np. `-d usb,0x0bc2,0x2312`). Flaga `–scan` spróbuje automatycznie zidentyfikować właściwy typ.

Środowiska zwirtualizowane: Wewnątrz gościa KVM lub VMware `/dev/sda` jest dyskiem wirtualnym. smartctl może zwracać `Device does not support SMART` lub sfabrykowane dane przekazane przez hiperwizor. Nie polegaj na wyjściu smartctl wewnątrz gościa do oceny stanu zdrowia fizycznego dysku w infrastrukturze hostingu współdzielonego.

Fałszywe alarmy dla Raw_Read_Error_Rate: Jak wspomniano powyżej, kodowanie tego atrybutu przez Seagate powoduje alarmujące surowe wartości, które są całkowicie normalne. Zawsze weryfikuj z dokumentacją atrybutów producenta przed podjęciem działań na podstawie tej wartości.

Dyski za programowym RAID (mdadm): smartctl uzyskuje dostęp do dysków składowych bezpośrednio (`/dev/sda`, `/dev/sdb`), a nie do urządzenia RAID (`/dev/md0`). Monitoruj każdy dysk członkowski indywidualnie.

Przestrzeń nazw NVMe vs. kontroler: Używaj `/dev/nvme0` (kontroler) do danych o stanie zdrowia, a nie `/dev/nvme0n1` (przestrzeń nazw/urządzenie blokowe). Niektóre wersje smartctl akceptują oba, ale węzeł kontrolera jest autorytatywny dla dostępu do dziennika stanu zdrowia.

Dyski, które kłamią: Niektóre konsumenckie SSD, szczególnie dyski NAND QLC niższej klasy, zostały udokumentowane jako zgłaszające zdrowe atrybuty S.M.A.R.T. aż do całkowitej i nagłej awarii. S.M.A.R.T. jest silnym wskaźnikiem, ale nie gwarancją — nie zastępuje regularnych kopii zapasowych.

Wdrażanie smartmontools w środowiskach serwerowych

Dla administratorów zarządzających wieloma serwerami fizycznymi — takimi jak te obsługujące obciążenia na Serwerach Dedykowanych — centralizacja monitorowania S.M.A.R.T. jest niezbędna. Rozważ następującą architekturę:

• Prometheus + node_exporter: `node_exporter` zawiera skrypt kolektora tekstowego `smartmon`, który eksportuje atrybuty S.M.A.R.T. jako metryki Prometheus. Umożliwia to alerty przez Alertmanager i wizualizację w dashboardach Grafana.
• Nagios / Icinga2: Wtyczka `check_smart` zapewnia integrację monitorowania S.M.A.R.T. dla tradycyjnych stosów monitorowania.
• Niestandardowe skrypty smartd: Dyrektywa `-M exec` w smartd.conf może wyzwalać dowolny skrypt przy alercie — przydatna do integracji z PagerDuty, webhookami Slack lub niestandardowymi systemami zgłoszeń.
• Agregacja plików dziennika: Skonfiguruj smartd do zapisu do syslog, a następnie przekazuj do scentralizowanego agregatora dzienników (stos ELK, Loki) do historycznej analizy trendów w całej flocie.

W środowiskach hostingu internetowego używających paneli sterowania, wdrożenia VPS z cPanel korzystają z monitorowania S.M.A.R.T. na poziomie hosta skonfigurowanego przez dostawcę infrastruktury, ponieważ cPanel sam w sobie nie eksponuje natywnie danych o stanie zdrowia dysków.

Lista kontrolna kluczowych wniosków

Używaj tego jako odniesienia przed wdrożeniem i w bieżącej eksploatacji:

• Zainstaluj smartmontools 7.x lub nowszy, aby zapewnić pełną obsługę NVMe i nowoczesnych SSD
• Uruchom `smartctl –scan` na nowym sprzęcie, aby zidentyfikować wszystkie dyski i wymagane flagi interfejsu
• Najpierw sprawdź werdykt stanu zdrowia `-H` — wynik `FAILED` wymaga natychmiastowego działania niezależnie od innych atrybutów
• Traktuj jakąkolwiek niezerową wartość Reallocated_Sector_Ct, Current_Pending_Sector lub Uncorrectable_Sector_Count jako sygnał awarii — nie czekaj na wzrost licznika
• Nie polegaj wyłącznie na Raw_Read_Error_Rate — weryfikuj z dokumentacją producenta przed alarmowaniem
• Zaplanuj automatyczne długie testy tygodniowo przez smartd na wszystkich dyskach produkcyjnych; krótkie testy codziennie
• Skonfiguruj alerty e-mail smartd i zweryfikuj dostarczanie przed poleganiem na nich
• Dla sprzętowego RAID zawsze używaj odpowiedniej flagi pass-through — monitorowanie dysku wirtualnego nie jest równoważne monitorowaniu dysków fizycznych
• W środowiskach zwirtualizowanych wykonuj monitorowanie S.M.A.R.T. na poziomie hiperwizora/hosta, a nie wewnątrz gościnnych maszyn wirtualnych
• Łącz monitorowanie S.M.A.R.T. ze strategią tworzenia kopii zapasowych — S.M.A.R.T. przewiduje awarię, ale nie zapobiega utracie danych
• Dla dysków NVMe monitoruj Available Spare i Percentage Used oprócz liczników błędów
• Na serwerach wielodyskowych integruj smartd ze scentralizowaną platformą alertów zamiast polegać na lokalnym dostarczaniu poczty e-mail

Często zadawane pytania

Czy smartctl działa wewnątrz VPS lub instancji chmurowej?

W większości środowisk VPS hiperwizor prezentuje gościowi wirtualne urządzenie blokowe. smartctl wewnątrz gościa zwróci albo brak danych, albo dane syntetyzowane przez hiperwizor, które nie odzwierciedlają rzeczywistego stanu zdrowia fizycznego dysku. Znaczące monitorowanie S.M.A.R.T. wymaga dostępu do fizycznego hosta. Dla pełnej widoczności na poziomie dysku, Serwer Dedykowany jest odpowiednim rozwiązaniem.

Jaka jest różnica między `smartctl -a` a `smartctl -x`?

Flaga `-a` wyświetla standardowy zestaw danych S.M.A.R.T.: informacje o urządzeniu, werdykt stanu zdrowia, flagi możliwości, wszystkie atrybuty, dziennik błędów i dziennik testów własnych. Flaga `-x` wyświetla wszystko, co zapewnia `-a`, plus dodatkowe strony dziennika, w tym dziennik selektywnych testów własnych, dziennik statystyk urządzenia, dziennik oczekujących defektów i statystyki urządzenia ATA — zapewniając pełniejszy obraz historii dysku. Używaj `-x` do dokładnej diagnostyki; `-a` do rutynowych sprawdzeń.

Jak długo trwa długi test własny i czy jest bezpieczny do uruchomienia na dysku produkcyjnym?

Czas trwania zależy od pojemności i prędkości dysku: około 1 godziny na terabajt dla HDD 7200 RPM i 20–60 minut dla większości SSD. Test działa w tle oprogramowania układowego dysku, a dysk nadal obsługuje I/O podczas testu. Wpływ na wydajność jest zazwyczaj niewielki (redukcja przepustowości o 5–15%). Jest bezpieczny do uruchomienia na systemach produkcyjnych podczas okresów niskiego ruchu, ale planowanie podczas okna konserwacyjnego jest zalecane dla obciążeń wrażliwych na opóźnienia.

Co oznacza, gdy Current_Pending_Sector jest niezerowy, ale Reallocated_Sector_Ct nie wzrósł?

Dysk zidentyfikował sektory, które powodują błędy odczytu, ale nie przemapował ich jeszcze pomyślnie. Przemapowanie następuje, gdy dysk może zapisać do sektora — albo przez operację zapisu, albo przez skanowanie offline. Jeśli licznik pozostaje statyczny, sektory mogą znajdować się w regionie tylko do odczytu lub dysk może nie mieć dostępnych sektorów zapasowych do przemapowania. Niezerowy i rosnący licznik Current_Pending_Sector, przy pozostającym płaskim Reallocated_Sector_Ct, często wskazuje, że dysk wyczerpał pulę sektorów zapasowych — krytyczny stan awarii.

Czy smartctl może wykryć zużycie SSD przed awarią dysku?

Tak, dla SATA SSD atrybuty Wear_Leveling_Count (ID 177), Media_Wearout_Indicator (ID 233) i Available_Reservd_Space (ID 232) śledzą zużycie wytrzymałości NAND. Dla NVMe SSD pola Percentage Used i Available Spare w dzienniku informacji o stanie zdrowia NVMe służą temu samemu celowi. Gdy Available Spare spadnie poniżej swojego progu lub Percentage Used osiągnie 100%, dysk zużył swoją ocenioną wytrzymałość zapisu. W przeciwieństwie do nagłych awarii mechanicznych, degradacja zużycia SSD jest stopniowa i wysoce przewidywalna — co czyni ją jednym z najsilniejszych przypadków użycia dla proaktywnego monitorowania S.M.A.R.T.