Monitorowanie stanu dysku za pomocą smartctl i smartd

Wprowadzenie

smartctl to narzędzie konsolowe z pakietu smartmontools, zaprojektowane do pracy z technologią S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) zaimplementowaną w nowoczesnych dyskach pamięci masowej.

Przypadki użycia:

• serwery firm hostingowych;
• węzły VPS/VDS;
• serwery dedykowane;
• serwery plików;
• systemy kopii zapasowych;
• infrastruktury korporacyjne.

Jakie zadania rozwiązuje:

• wczesne wykrywanie degradacji dysku;
• prognozowanie awarii dysków;
• zmniejszenie ryzyka utraty danych;
• automatyzacja monitorowania stanu HDD, SSD, NVMe;
• analiza problemów fizycznych w podsystemie dyskowym.

Wymagania i warunki wstępne

Obsługiwane systemy operacyjne i wersje:

Linux:

• Debian 10+
• Ubuntu 18.04+
• RHEL / AlmaLinux / Rocky Linux 8+
• CentOS 7 (obsługiwany, ale przestarzały)
• FreeBSD 12+

Windows (poprzez smartmontools, ograniczone użycie)

Poniższe przykłady są podane dla systemu Linux.

Wymagane oprogramowanie i pakiety:

• pakiet smartmontools
• dostęp do /dev/sdX, /dev/nvmeX
• zainstalowany systemd (dla smartd)

Prawa dostępu:

• wymagane uprawnienia root
• lub dostęp przez sudo

Wstępne kontrole

Wyświetlanie listy dysków w systemie:

lsblk -d -o NAME,MODEL

Przegląd i podstawowe pojęcia

Kluczowe terminy

• SMART – wbudowany system autodiagnostyki dysku
• Atrybuty – atrybuty stanu (Reallocated_Sector_Ct, Pending_Sectors, itp.)
• Self-test – wbudowane testy dysku
• smartctl – narzędzie CLI do zarządzania SMART
• smartd – automatyczny demon monitorujący

Jak to działa

1. Dysk samodzielnie zbiera statystyki
2. smartctl odczytuje te dane
3. smartd analizuje wartości progowe i zdarzenia
4. Powiadomienia są wysyłane, gdy wystąpią problemy

Logika przepływu pracy

Dysk > Atrybuty SMART > smartctl > smartd > log / email / monitoring

Podstawowa konfiguracja i użycie smartctl

Instalacja narzędzia smartmontools

Praca z SMART jest niemożliwa bez zainstalowanego pakietu smartmontools, który zawiera narzędzia smartctl (ręczna praca z dyskami) i smartd (demon monitorujący w tle).

Instalacja odbywa się za pomocą standardowych narzędzi menedżera pakietów dystrybucji.

Debian / Ubuntu

sudo apt update

sudo apt install smartmontools

RHEL / AlmaLinux / Rocky Linux

sudo dnf install smartmontools

Po instalacji narzędzia stają się dostępne w systemie i są gotowe do użycia bez dodatkowej inicjalizacji.

Sprawdzanie wersji i dostępności smartctl

Jako pierwszy krok zaleca się sprawdzenie, czy narzędzie jest poprawnie zainstalowane i dostępne w systemie:

smartctl --version

Polecenie wyświetla wersję pakietu i listę obsługiwanych technologii.

Pozwala to na:

• upewnienie się, że używana jest aktualna wersja;
• sprawdzenie wsparcia dla NVMe, RAID i innych typów urządzeń.

Sprawdzanie wsparcia SMART na konkretnym dysku

Następnie należy sprawdzić, czy sam dysk obsługuje technologię SMART i czy jest ona włączona na poziomie urządzenia.

sudo smartctl -i /dev/sda

Przykład poprawnego wyjścia:

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Available – dysk fizycznie obsługuje SMART;
Enabled – zbieranie danych SMART jest włączone i dostępne do odczytu.

Jeśli SMART jest obsługiwany, ale wyłączony, często jest to widoczne na nowych lub wcześniej nieużywanych dyskach. W takim przypadku należy go włączyć ręcznie:

sudo smartctl -s on /dev/sda

Po tym zaleca się ponowne uruchomienie polecenia smartctl -i, aby upewnić się, że SMART jest aktywowany.

Wyświetlanie atrybutów SMART i wstępna ocena stanu zdrowia

Główna praktyczna wartość SMART leży w jego atrybutach – wartościach liczbowych odzwierciedlających stan powierzchni dysku, mechaniki i elektroniki.

Aby wyświetlić atrybuty, użyj polecenia:

sudo smartctl -A /dev/sda

Wyjście zawiera tabelę atrybutów z ich bieżącymi wartościami i historią. Przede wszystkim należy zwrócić uwagę na następujące wskaźniki:

Kluczowe pola w wyjściu:

• VALUE (Current Value): Znormalizowana wartość atrybutu (zwykle od 1 do 100, 100 to ideał). Dysk jest uważany za uszkodzony, jeśli VALUE ≤ THRESH.
• WORST (Worst Value): Najgorsza wartość, jaka została osiągnięta podczas pracy dysku.
• THRESH (Threshold): Minimalna dopuszczalna wartość dla VALUE. Przekroczenie progu (VALUE ≤ THRESH) jest oznaką krytycznego stanu.
• RAW_VALUE: "Surowa", nieznormalizowana wartość atrybutu. To, co należy analizować, aby ocenić zużycie i liczbę zdarzeń.

Kluczowe atrybuty dla HDD (tradycyjne dyski twarde):

• Reallocated_Sector_Ct: Wzrost wskazuje na degradację fizycznej powierzchni.
• Current_Pending_Sector (Sektory oczekujące na realokację): Niestabilne sektory. Nawet pojedyncza wartość różna od zera jest sygnałem ostrzegawczym.
• Offline_Uncorrectable (Błędy niekorygowalne): Sektory, których nie można było odczytać.
• Power_On_Hours: Całkowity czas pracy dysku.

Kluczowe atrybuty dla SSD:

• Retired_Block_Count: Odpowiednik Reallocated_Sector_Ct dla HDD. Pokazuje liczbę bloków wycofanych z użytku. Nawet niska wartość z VALUE=100 może być normalna.
• Reallocated_Event_Count: Liczba zdarzeń realokacji.
• SSD_Life_Left lub Percentage Used/Media Wearout Indicator: Procent pozostałego życia (lub zużycia). Niska wartość (np. <10%) jest oznaką zbliżającej się awarii.
• Wear_Range_Delta: Wskaźnik równomierności zużycia komórek pamięci.
• Power_On_Hours_and_Msec: Całkowity czas pracy.
• Lifetime_Writes_GiB / Lifetime_Reads_GiB (Atrybuty 241, 242): Całkowita ilość zapisanych/odczytanych danych.

Kluczowe atrybuty dla NVMe (poprzez smartctl -a /dev/nvme0):

• Percentage Used: Procent zużycia wytrzymałości zapisu. Główny wskaźnik zużycia.
• Media and Data Integrity Errors: Błędy integralności danych.
• Critical Warning: Flagi krytycznych ostrzeżeń.
• Temperature: Aktualna temperatura.

Na tym etapie administrator zyskuje ogólne zrozumienie stanu dysku i może zidentyfikować oczywiste oznaki problemów.

Zaawansowana konfiguracja i scenariusze praktyczne

SMART obsługuje wbudowane autotesty, które są wykonywane przez sam dysk bez udziału systemu operacyjnego.

Krótki test jest przeznaczony do szybkiego sprawdzenia kluczowych komponentów:

sudo smartctl -t short /dev/sda

Długi test wykonuje pełne skanowanie powierzchni i zajmuje znacznie więcej czasu:

sudo smartctl -t long /dev/sda

Po zakończeniu testu należy sprawdzić wyniki:

sudo smartctl -l selftest /dev/sda

Wyjście wskazuje:

• rodzaj testu;
• status zakończenia;
• obecność lub brak błędów.

Nieudany test jest bezpośrednim powodem do przygotowania się do wymiany dysku.

Praca z kontrolerami RAID

Sprzętowe kontrolery RAID często ukrywają dane SMART przed systemem. W takich przypadkach należy jawnie określić typ urządzenia.

Przykład dla kontrolera LSI:

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

Gdzie:

• -a – klucz do wyświetlenia wszystkich dostępnych informacji SMART (atrybuty, logi, błędy, ogólna ocena stanu zdrowia).
• -d – klucz do określenia typu urządzenia.
• megaraid – informuje sterownik SMART, że dysk znajduje się za kontrolerem LSI/Broadcom (często używanym w serwerach).
• 0 – numer fizycznego dysku (PD, Physical Drive) w macierzy RAID. To nie jest sda, ale unikalny identyfikator przypisany przez kontroler. Można go znaleźć za pomocą narzędzia do zarządzania kontrolerem (np. storcli lub MegaCLI).
• /dev/sda – w tym kontekście nie jest to prawdziwy dysk, ale pseudo-urządzenie reprezentujące sam kontroler RAID w systemie. Zazwyczaj jest to /dev/sgX (SCSI Generic) lub po prostu /dev/sda, jeśli kontroler utworzył wirtualny dysk.

Typowy błąd, gdy typ urządzenia nie jest określony:

SMART support is: Unavailable

To nie oznacza, że SMART jest niedostępny – tylko że smartctl nie mógł automatycznie określić ścieżki do fizycznego dysku. Rozwiązaniem jest poprawne określenie parametru -d.

Diagnostyka i rozwiązywanie problemów

Oznaki możliwych usterek:

• wzrost wartości Reallocated_Sector_Ct;
• wartość Current_Pending_Sector różna od zera;
• błędy programowania/wymazywania (Program_Fail_Count, Erase_Fail_Count);
• błędy autotestów;
• wzrost opóźnienia I/O;
• komunikaty o błędach w logach systemowych.

Analiza logów:

journalctl -u smartd

dmesg | grep -i error

Wyjaśnienie:
Pending Sectors > 0 – wysokie ryzyko awarii;
Reallocated Sectors rosną – postępująca degradacja;
Self-test FAILED – dysk musi zostać wymieniony.

Identyfikacja źródeł problemów

Aby wykluczyć fałszywe alarmy, ważne jest skorelowanie danych SMART z rzeczywistym obciążeniem.

iostat -x 1

iotop

Sprawdzanie, gdzie dysk jest zamontowany:

lsblk -o NAME,SERIAL,MOUNTPOINT

Identyfikacja kontrolerów:

lspci | grep -i raid

Dodatkowe metryki:

• temperatura powyżej 50 °C;
• wzrost liczby błędów CRC;
• niestabilne wartości SMART.

Konfiguracja powiadomień administratora, gdy metryki SMART zbliżają się do wartości progowych

Sama obecność danych SMART nie gwarantuje jeszcze bezpieczeństwa infrastruktury. Kluczowym elementem monitorowania jest terminowe powiadamianie administratora w momencie, gdy stan dysku zaczyna się pogarszać, ale awaria jeszcze nie nastąpiła.

Mechanizm powiadomień pozwala na:

• wykrycie degradacji dysku na wczesnym etapie;
• zaplanowanie wymiany dysku z wyprzedzeniem;
• uniknięcie awaryjnych przestojów i utraty danych;
• działanie w ramach zaplanowanych okien serwisowych.

W smartmontools za wysyłanie powiadomień odpowiada demon smartd. Automatycznie śledzi zmiany w atrybutach SMART i reaguje na odchylenia od normy.

Zasada działania powiadomień smartd

Demon smartd działa jako usługa w tle i wykonuje następujące zadania:

1. Okresowo odpytywanie atrybutów SMART dysków.
2. Porównywanie bieżących wartości z: progami fabrycznymi, poprzednimi wartościami (dynamika zmian).
3. Wykrywanie: wzrostu krytycznych atrybutów, pojawienia się nowych błędów, niepowodzeń autotestów.
4. Generowanie powiadomienia i wysyłanie go do administratora.

Wymagania dla działania powiadomień

Przed konfiguracją należy upewnić się, że:

• w systemie zainstalowany i poprawnie skonfigurowany jest MTA (Postfix, Exim, Sendmail, ssmtp);
• serwer jest zdolny do wysyłania poczty wychodzącej;
• zdefiniowany jest adres e-mail administratora do odbierania powiadomień.

Przykład konfiguracji ssmtp – lekkiego i prostego MTA do wysyłania poczty z systemu.

Instalacja:

Debian/Ubuntu:

sudo apt update && sudo apt install ssmtp mailutils -y

RHEL:

sudo dnf install ssmtp mailx

Utwórz plik konfiguracyjny:

sudo nano /etc/ssmtp/ssmtp.conf

i edytuj jego zawartość:

# Domyślny adres nadawcy
[email protected]

# Serwer SMTP i port dostawcy poczty
mailhub=smtp.your-domain.com:587
# Alternatywny przykład:
# mailhub=smtp.gmail.com:587        # Dla Gmail

# Dane uwierzytelniające
[email protected]
AuthPass=your-password

# Ustawienia szyfrowania
UseSTARTTLS=YES    # Użyj STARTTLS
UseTLS=YES         # Użyj TLS
FromLineOverride=YES  # Zezwól na nadpisanie adresu nadawcy

# Nazwa hosta (określ nazwę swojego serwera)
hostname=server1.your-domain.com
# możesz użyć hostname=localhost lub określić rzeczywistą nazwę hosta systemu

Zapisz plik i skonfiguruj uprawnienia dostępu:

sudo chmod 640 /etc/ssmtp/ssmtp.conf

sudo chown root:mail /etc/ssmtp/ssmtp.conf

Skonfiguruj nadawców (revaliases):

sudo nano /etc/ssmtp/revaliases

root:[email protected]:smtp.your-domain.com:587
www-data:[email protected]:smtp.your-domain.com:587

Aby wiadomości były wysyłane pomyślnie, na serwerze muszą być otwarte następujące porty: 587 (główny do wysyłania z szyfrowaniem STARTTLS), lub 25 (standardowy SMTP), 465 (bezpieczny SMTP z SSL), jeśli są one przewidziane w konfiguracji.

Podstawowy test wysyłania poczty:

echo "SMART test message" | mail -s "SMART notification test" [email protected]

Możesz jawnie określić nadawcę:

echo "SMART test message" | mail -s "SMART notification test" -a "From: [email protected]" [email protected]

Lub bezpośrednio przez ssmtp:

echo "SMART test message" | ssmtp [email protected]

[email protected] – adres odbiorcy, na który zostanie wysłana wiadomość.

Konfiguracja powiadomień SMART odbywa się w pliku:

/etc/smartd.conf

Przykład prostej działającej konfiguracji:

/dev/sda -a -o on -S on -m [email protected]

Parametry:

• /dev/sda – monitorowany dysk;
• -a – pełny zestaw kontroli;
• -S on – zapisywanie atrybutów między restartami jest włączone;
• -o on – automatyczne zbieranie danych offline jest aktywowane;
• -m – powiadomienia są wysyłane na podany e-mail.

Od tego momentu smartd zacznie monitorować stan dysku w tle.

Powiadomienia przy zbliżaniu się do wartości progowych

Kluczową cechą smartd jest to, że monitoruje zmiany wartości atrybutów, a nie tylko ich krytyczne przekroczenie.

W praktyce oznacza to, że powiadomienie może zostać wysłane:

• przy pierwszym pojawieniu się Current_Pending_Sector;
• przy wzroście Reallocated_Sector_Ct, nawet jeśli próg nie został jeszcze osiągnięty;
• przy wykryciu błędów autotestów;
• przy degradacji parametrów NVMe.

Najważniejsze atrybuty wczesnej awarii:

• Reallocated_Sector_Ct
• Current_Pending_Sector
• Offline_Uncorrectable
• Media and Data Integrity Errors (NVMe)
• Percentage Used (SSD/NVMe)

Nawet minimalne zmiany w tych parametrach powinny być traktowane jako powód do uwagi.

Używanie autotestów jako źródła powiadomień

Aby zwiększyć informacyjność, zaleca się łączenie monitorowania atrybutów z regularnymi autotestami.

Przykład konfiguracji z harmonogramem:

/dev/sda -a -o on -S on \
    -s (S/../.././02|L/../../6/03) \
    -m [email protected]

Logika działania:

• krótki test jest wykonywany codziennie;
• pełny test jest wykonywany raz w tygodniu;
• przy każdej awarii testu administrator otrzymuje powiadomienie.

Zarządzanie częstotliwością i objętością powiadomień

Aby uniknąć nadmiernych alertów, używa się parametru -M once:

/dev/sda -a -m [email protected] -M once

W tym trybie:

• powiadomienie jest wysyłane przy pierwszym wykryciu problemu;
• kolejne wiadomości nie są duplikowane, dopóki przyczyna nie zostanie rozwiązana.

Aby przetestować system powiadomień, można użyć -M test. Pozwala to sprawdzić, czy smartd jest w stanie wysyłać wiadomości bez czekania na rzeczywisty błąd.

Podsumowanie

W ramach tego podręcznika systematycznie przeanalizowano pełny cykl wdrażania i działania smartctl oraz demona smartd jako narzędzia do proaktywnego monitorowania stanu zdrowia dysków. Omówiono podstawowe zasady działania SMART, praktyczne metody analizy atrybutów, uruchamianie i interpretację autotestów, specyfikę pracy z dyskami NVMe i kontrolerami RAID, a także metody diagnostyczne i techniki identyfikacji przyczyn problemów. Szczególną uwagę poświęcono konfiguracji powiadomień, które pozwalają na wykrycie degradacji dysku na wczesnych etapach, jeszcze przed wystąpieniem krytycznej awarii.

Prawidłowo skonfigurowane monitorowanie SMART jest integralną częścią niezawodnej infrastruktury serwerowej i powinno być traktowane jako obowiązkowy standard operacyjny. Użycie smartctl i smartd pozwala administratorowi systemu przejść od reaktywnego rozwiązywania incydentów do świadomego, zarządzalnego utrzymania podsystemu dyskowego, zmniejszając ryzyko przestojów, utraty danych i nieplanowanych incydentów, jednocześnie tworząc solidną podstawę do dalszej automatyzacji i integracji z centralnymi systemami monitorowania.