Instalacja i konfiguracja narzędzia smartctl do proaktywnego monitorowania stanu dysków

Wprowadzenie

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

Przykłady zastosowań:

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

Jakie zadania rozwiązuje:

• wczesne wykrywanie pogorszenia stanu dysku;
• przewidywanie awarii dysków;
• ograniczenie ryzyka utraty danych;
• automatyzacja monitorowania stanu dysków HDD, SSD i NVMe;
• analiza problemów fizycznych w podsystemie dyskowym.

Proaktywny monitoring SMART pozwala zidentyfikować problem przed faktyczną awarią dysku, co ma kluczowe znaczenie w środowiskach produkcyjnych.

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 (za pośrednictwem smartmontools, ograniczone zastosowanie)

Poniższe przykłady dotyczą systemu Linux.

Wymagane oprogramowanie i pakiety:

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

Uprawnienia dostępu:

• wymagane uprawnienia administratora
• lub dostęp za pośrednictwem sudo

Wstępne sprawdzenie

Wyświetlanie listy dysków w systemie:

lsblk -d -o NAME,MODEL

Przegląd i podstawowe pojęcia

Kluczowe pojęcia

• SMART — wbudowany system autodiagnostyki dysków
• Atrybuty — atrybuty stanu (Reallocated_Sector_Ct, Pending_Sectors itp.)
• Autotest — wbudowane testy dysku
• smartctl – narzędzie CLI do zarządzania systemem SMART
• smartd – demon automatycznego monitorowania

Jak to działa

1. Dysk samodzielnie gromadzi statystyki
2. smartctl odczytuje te dane
3. smartd analizuje wartości progowe i zdarzenia
4. W razie wystąpienia problemów wysyłane są powiadomienia

Logika działania

Dysk > Atrybuty SMART > smartctl > smartd > dziennik / e-mail / monitorowanie

Podstawowa konfiguracja i obsługa programu smartctl

Instalacja narzędzia smartmontools

Praca z systemem SMART jest niemożliwa bez zainstalowanego pakietu smartmontools, który zawiera narzędzia smartctl (do ręcznej obsługi dysków) oraz smartd (demon monitorujący działający w tle).

Instalację przeprowadza się za pomocą standardowych narzędzi menedżera pakietów danej 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

W pierwszej kolejności zaleca się sprawdzenie, czy narzędzie zostało poprawnie zainstalowane i jest dostępne w systemie:

smartctl --version

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

Pozwala to:

• upewnić się, że używana jest aktualna wersja;
• sprawdzić obsługę NVMe, RAID i innych typów urządzeń.

Sprawdzanie obsługi technologii SMART na konkretnym dysku

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

sudo smartctl -i /dev/sda

Przykład prawidłowego wyniku:

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

• Dostępne — dysk fizycznie obsługuje technologię SMART;
• Włączone – gromadzenie danych SMART jest włączone i dostępne do odczytu.

Jeśli technologia SMART jest obsługiwana, ale wyłączona, często ma to miejsce w przypadku nowych lub wcześniej nieużywanych dysków. W takim przypadku należy ją włączyć ręcznie:

sudo smartctl -s on /dev/sda

Następnie zaleca się ponowne uruchomienie polecenia smartctl -i, aby upewnić się, że technologia SMART jest aktywna.

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

Główna praktyczna wartość funkcji SMART wynika z jej atrybutów – wartości liczbowych odzwierciedlających stan powierzchni dysku, jego mechaniki i elektroniki.

Aby wyświetlić atrybuty, należy użyć polecenia:

sudo smartctl -A /dev/sda

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

Kluczowe pola w wynikach:

• VALUE (wartość bieżąca): znormalizowana wartość atrybutu (zwykle od 1 do 100, gdzie 100 oznacza stan idealny). Dysk uznaje się za uszkodzony, jeśli VALUE ≤ THRESH.
• WORST (najgorsza wartość): Najgorsza wartość, jaka została osiągnięta podczas pracy dysku.
• THRESH (próg): minimalna dopuszczalna wartość dla VALUE. Przekroczenie progu (VALUE ≤ THRESH) jest oznaką stanu krytycznego.
• RAW_VALUE: „Surowa”, znormalizowana wartość atrybutu. To właśnie tę wartość należy analizować w celu oceny zużycia i zliczania zdarzeń.

Kluczowe atrybuty dla dysków HDD (tradycyjnych dysków twardych):

• Reallocated_Sector_Ct: Wzrost tej wartości wskazuje na fizyczne zużycie powierzchni.
• Current_Pending_Sector (sektory oczekujące na realokację): Sektory niestabilne. Nawet pojedyncza wartość niezerowa stanowi sygnał ostrzegawczy.
• Offline_Uncorrectable (błędy nie do skorygowania): Sektory, których nie udało się odczytać.
• Power_On_Hours: Łączny czas pracy dysku.

Kluczowe atrybuty dysków SSD:

• Retired_Block_Count: Odpowiednik wskaźnika Reallocated_Sector_Ct dla dysków HDD. Pokazuje liczbę bloków wycofanych z eksploatacji. Nawet niska wartość, np. 100, może być w normie.
• Reallocated_Event_Count: Liczba zdarzeń realokacji.
• SSD_Life_Left lub Percentage Used/Media Wearout Indicator: Procent pozostałej żywotności (lub stopnia 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: Łączny czas pracy.
• Lifetime_Writes_GiB / Lifetime_Reads_GiB (atrybuty 241, 242): Łączna objętość zapisanych/odczytanych danych.

Kluczowe atrybuty dla NVMe (za pomocą polecenia smartctl -a /dev/nvme0):

• Percentage Used: Procent wykorzystanej wytrzymałości na zapisy. Główny wskaźnik zużycia.
• Błędy integralności nośnika i danych: Błędy integralności danych.
• Ostrzeżenie krytyczne: flagi ostrzegawcze o krytycznych stanach.
• Temperatura: aktualna temperatura.

Na tym etapie administrator uzyskuje ogólny obraz stanu dysku i może zidentyfikować oczywiste oznaki problemów.

Zaawansowana konfiguracja i praktyczne scenariusze

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

Krótki test służy do szybkiego sprawdzenia kluczowych komponentów:

sudo smartctl -t short /dev/sda

Test długotrwały obejmuje pełne skanowanie powierzchni dysku i trwa znacznie dłużej:

sudo smartctl -t long /dev/sda

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

sudo smartctl -l selftest /dev/sda

Wynik wskazuje:

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

Niepowodzenie testu stanowi bezpośredni powód 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 wyraźnie określić typ urządzenia.

Przykład dla kontrolera LSI:

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

Gdzie:

• -a – klucz służący do wyświetlenia wszystkich dostępnych informacji SMART (atrybuty, logi, błędy, ogólna ocena stanu).
• -d – opcja służąca do określenia typu urządzenia.
• megaraid – informuje sterownik SMART, że dysk jest podłączony do kontrolera LSI/Broadcom (powszechnie stosowanego w serwerach).
• 0 – numer dysku fizycznego (PD, Physical Drive) w macierzy RAID. Nie jest to 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 rzeczywisty dysk, lecz pseudourządzenie reprezentujące w systemie sam kontroler RAID. Zazwyczaj jest to /dev/sgX (SCSI Generic) lub po prostu /dev/sda, jeśli kontroler utworzył dysk wirtualny.

Typowy błąd w przypadku braku określenia typu urządzenia:

SMART support is: Unavailable

Nie oznacza to, że funkcja SMART jest niedostępna — oznacza jedynie, że program smartctl nie mógł automatycznie określić ścieżki do dysku fizycznego. Rozwiązaniem jest poprawne określenie parametru -d.

Diagnostyka i rozwiązywanie problemów

Oznaki możliwych usterek:

• wzrost wartości Reallocated_Sector_Ct;
• niezerowa wartość Current_Pending_Sector;
• błędy programowania/kasowania (Program_Fail_Count, Erase_Fail_Count);
• błędy autotestu;
• wzrost opóźnienia operacji wejścia/wyjścia;
• komunikaty o błędach w dziennikach systemowych.

Analiza logów

journalctl -u smartd

dmesg | grep -i error

Wyjaśnienie:

• Liczbasektorów oczekujących > 0 — wysokie ryzyko awarii;
• Liczba sektorów realokowanych rośnie – postępująca degradacja;
• Test samokontroli NIEUDANY – dysk należy wymienić.

Identyfikacja źródeł problemów

Aby wykluczyć fałszywe alarmy, należy skorelować dane 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 wskaźniki:

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

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

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

Mechanizm powiadomień pozwala na:

• wykrycie pogorszenia stanu dysku na wczesnym etapie;
• z wyprzedzeniem zaplanować wymianę dysku;
• uniknąć awaryjnych przestojów i utraty danych;
• działanie w ramach zaplanowanych okien serwisowych.

W programie smartmontools za wysyłanie powiadomień odpowiada demon smartd. Automatycznie śledzi on zmiany atrybutów 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 sprawdza atrybuty SMART dysku.
2. Porównuje bieżące wartości z: progami fabrycznymi, poprzednimi wartościami (dynamika zmian).
3. Wykrywa: wzrost wartości atrybutów krytycznych, pojawienie się nowych błędów, niepowodzenia testów samokontroli.
4. Generuje powiadomienie i wysyła je do administratora.

Wymagania dotyczące działania powiadomień

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

• w systemie jest zainstalowany i poprawnie skonfigurowany serwer MTA (Postfix, Exim, Sendmail, ssmtp);
• serwer ma możliwość wysyłania poczty wychodzącej;
• zdefiniowany jest adres e-mail administratora, na który będą wysyłane powiadomienia.

Przykład konfiguracji ssmtp – lekkiego i prostego serwera MTA do wysyłania wiadomości e-mail z systemu

Instalacja:

#  For Debian/Ubuntu
sudo apt update && sudo apt install ssmtp mailutils -y

#  For RHEL
sudo dnf install ssmtp mailx 

Utwórz plik konfiguracyjny

sudo nano /etc/ssmtp/ssmtp.conf 

i edytuj jego zawartość:

# Default sender address
[email protected]

# SMTP server and port of your email provider
mailhub=smtp.your-domain.com:587
# Alternative example:
# mailhub=smtp.gmail.com:587        # For Gmail

# Authentication credentials
[email protected]
AuthPass=your-password

# Encryption settings
UseSTARTTLS=YES    # Use STARTTLS
UseTLS=YES         # Use TLS
FromLineOverride=YES  # Allow overriding the sender address

# Hostname (specify your server's name)
hostname=server1.your-domain.com
# you can use hostname=localhost or specify the system's actual hostname

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 (aliasów):

sudo nano /etc/ssmtp/revaliases

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

Aby wysyłanie wiadomości przebiegało 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ą przewidziane w konfiguracji.

Podstawowy test wysyłania wiadomości:

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

# You can explicitly specify the sender
echo "SMART test message" | mail -s "SMART notification test" -a "From: [email protected]" [email protected]

# Via ssmtp directly
echo "SMART test message" | ssmtp [email protected]

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

Jeśli wiadomość e-mail nie zostanie dostarczona, dalsza konfiguracja smartd nie ma sensu, dopóki problemy z dostarczaniem poczty nie zostaną rozwiązane.

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 testów;
• -S on – włączone zapisywanie atrybutów między restartami;
• -o on – włączono automatyczne gromadzenie danych w trybie offline;
• -m – powiadomienia są wysyłane na podany adres e-mail.

Od tego momentu program smartd rozpocznie monitorowanie stanu dysku w tle.

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

Kluczową cechą programu smartd jest to, że monitoruje on 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;
• w przypadku wzrostu wartości Reallocated_Sector_Ct, nawet jeśli próg nie został jeszcze osiągnięty;
• po wykryciu błędów podczas autotestu;
• w przypadku pogorszenia parametrów NVMe.

Najważniejsze cechy wczesnej awarii:

• Reallocated_Sector_Ct
• Current_Pending_Sector
• Offline_Uncorrectable
• Błędy integralności nośnika i danych (NVMe)
• Procent wykorzystania (SSD/NVMe)

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

Wykorzystanie autotestów jako źródła powiadomień

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

Przykładowa konfiguracja z harmonogramem:

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

Logika działania:

• codziennie przeprowadzany jest krótki test;
• raz w tygodniu przeprowadzany jest pełny test;
• w przypadku niepowodzenia dowolnego testu administrator otrzymuje powiadomienie.

Zarządzanie częstotliwością i liczbą powiadomień

Aby uniknąć nadmiernej liczby alertów, stosuje się parametr -M once

Przykład:

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

W tym trybie:

• powiadomienie jest wysyłane przy pierwszym wykryciu problemu;
• kolejne komunikaty nie są powielane, dopóki przyczyna nie zostanie usunięta.

Aby przetestować system powiadomień, można użyć opcji -M test

Pozwala to sprawdzić, czy smartd jest w stanie wysyłać komunikaty bez oczekiwania na rzeczywisty błąd.

Wnioski

W ramach niniejszego podręcznika systematycznie omówiono pełny cykl wdrażania i działania programu smartctl oraz demona smartd jako narzędzia do proaktywnego monitorowania stanu dysków. Omówiono podstawowe zasady działania technologii 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 pierwotnych przyczyn problemów. Szczególną uwagę poświęcono konfiguracji powiadomień, które pozwalają na wykrycie pogorszenia stanu dysku na wczesnym etapie, jeszcze przed wystąpieniem krytycznej awarii.

Prawidłowo skonfigurowane monitorowanie SMART stanowi integralną część niezawodnej infrastruktury serwerowej i powinno być traktowane jako obowiązkowy standard operacyjny. Korzystanie z narzędzi smartctl i smartd pozwala administratorowi systemu przejść od reaktywnego rozwiązywania incydentów do świadomej i łatwej w zarządzaniu konserwacji podsystemu dyskowego, zmniejszając ryzyko przestojów, utraty danych i nieplanowanych incydentów, a jednocześnie tworząc solidną podstawę do dalszej automatyzacji i integracji ze scentralizowanymi systemami monitorowania.