Monitoraggio dello stato del disco con smartctl e smartd

Introduzione

smartctl è un'utilità da console del pacchetto smartmontools, progettata per lavorare con la tecnologia S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) implementata nei moderni dispositivi di archiviazione.

Casi d'uso:

• server di aziende di hosting;
• nodi VPS/VDS;
• server dedicati;
• file server;
• sistemi di backup;
• infrastrutture aziendali.

Quali compiti risolve:

• rilevamento precoce del degrado del disco;
• previsione dei guasti del disco;
• riduzione del rischio di perdita di dati;
• automazione del monitoraggio dello stato di salute di HDD, SSD, NVMe;
• analisi dei problemi fisici nel sottosistema del disco.

Requisiti e prerequisiti

Sistemi operativi e versioni supportati:

Linux:

• Debian 10+
• Ubuntu 18.04+
• RHEL / AlmaLinux / Rocky Linux 8+
• CentOS 7 (supportato, ma obsoleto)
• FreeBSD 12+

Windows (tramite smartmontools, uso limitato)

Gli esempi seguenti sono forniti per Linux.

Software e pacchetti richiesti:

• pacchetto smartmontools
• accesso a /dev/sdX, /dev/nvmeX
• systemd installato (per smartd)

Diritti di accesso:

• privilegi di root richiesti
• o accesso tramite sudo

Controlli preliminari

Visualizzazione dell'elenco dei dischi nel sistema:

lsblk -d -o NAME,MODEL

Panoramica e concetti di base

Termini chiave

• SMART – sistema di autodiagnosi integrato del disco
• Attributi – attributi di stato (Reallocated_Sector_Ct, Pending_Sectors, ecc.)
• Self-test – test integrati del disco
• smartctl – utilità CLI per la gestione di SMART
• smartd – demone di monitoraggio automatico

Come funziona

1. Il disco raccoglie autonomamente statistiche
2. smartctl legge questi dati
3. smartd analizza i valori soglia e gli eventi
4. Le notifiche vengono inviate quando si verificano problemi

Logica del flusso di lavoro

Disco > Attributi SMART > smartctl > smartd > log / email / monitoraggio

Configurazione di base e utilizzo di smartctl

Installazione dell'utilità smartmontools

Lavorare con SMART è impossibile senza il pacchetto smartmontools installato, che include le utilità smartctl (lavoro manuale con i dischi) e smartd (demone di monitoraggio in background).

L'installazione viene eseguita utilizzando gli strumenti standard del gestore pacchetti della distribuzione.

Debian / Ubuntu

sudo apt update

sudo apt install smartmontools

RHEL / AlmaLinux / Rocky Linux

sudo dnf install smartmontools

Dopo l'installazione, le utilità diventano disponibili nel sistema e sono pronte per l'uso senza ulteriori inizializzazioni.

Verifica della versione e disponibilità di smartctl

Come primo passo, si consiglia di verificare che l'utilità sia correttamente installata e disponibile nel sistema:

smartctl --version

Il comando restituisce la versione del pacchetto e un elenco delle tecnologie supportate.

Questo consente di:

• assicurarsi che venga utilizzata una versione aggiornata;
• verificare il supporto di NVMe, RAID e altri tipi di dispositivi.

Verifica del supporto SMART su un disco specifico

Successivamente, è necessario verificare se il disco stesso supporta la tecnologia SMART e se è abilitata a livello di dispositivo.

sudo smartctl -i /dev/sda

Esempio di output corretto:

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

Available – il disco supporta fisicamente SMART;
Enabled – la raccolta dei dati SMART è attivata e disponibile per la lettura.

Se SMART è supportato ma disabilitato, questo è spesso visto su dischi nuovi o precedentemente inutilizzati. In tal caso, deve essere abilitato manualmente:

sudo smartctl -s on /dev/sda

Dopo questo, si consiglia di rieseguire il comando smartctl -i per assicurarsi che SMART sia attivato.

Visualizzazione degli attributi SMART e valutazione iniziale dello stato di salute

Il valore pratico principale di SMART risiede nei suoi attributi – valori numerici che riflettono la condizione della superficie del disco, della meccanica e dell'elettronica.

Per visualizzare gli attributi, utilizzare il comando:

sudo smartctl -A /dev/sda

L'output contiene una tabella di attributi con i loro valori attuali e la storia. Prima di tutto, si dovrebbe prestare attenzione ai seguenti indicatori:

Campi chiave nell'output:

• VALUE (Valore Corrente): Il valore normalizzato dell'attributo (di solito da 1 a 100, 100 essendo ideale). Il disco è considerato difettoso se VALUE ≤ THRESH.
• WORST (Valore Peggiore): Il valore peggiore che è stato raggiunto durante il funzionamento del disco.
• THRESH (Soglia): Il valore minimo consentito per VALUE. Superare la soglia (VALUE ≤ THRESH) è un segno di condizione critica.
• RAW_VALUE: Il valore "grezzo", non normalizzato dell'attributo. Questo è ciò che deve essere analizzato per valutare l'usura e contare gli eventi.

Attributi chiave per HDD (dischi rigidi tradizionali):

• Reallocated_Sector_Ct: Un aumento indica un degrado fisico della superficie.
• Current_Pending_Sector (Settori in attesa di riallocazione): Settori instabili. Anche un singolo valore diverso da zero è un segnale di avvertimento.
• Offline_Uncorrectable (Errori non correggibili): Settori che non possono essere letti.
• Power_On_Hours: Il tempo totale di funzionamento del disco.

Attributi chiave per SSD:

• Retired_Block_Count: L'equivalente di Reallocated_Sector_Ct per gli HDD. Mostra il numero di blocchi messi fuori servizio. Anche un valore basso con VALUE=100 può essere normale.
• Reallocated_Event_Count: Il numero di eventi di riallocazione.
• SSD_Life_Left o Percentage Used/Media Wearout Indicator: La percentuale di vita residua (o usura). Un valore basso (ad es. <10%) è un segno di guasto imminente.
• Wear_Range_Delta: Un indicatore dell'uniformità dell'usura tra le celle di memoria.
• Power_On_Hours_and_Msec: Il tempo totale di funzionamento.
• Lifetime_Writes_GiB / Lifetime_Reads_GiB (Attributi 241, 242): Il volume totale di dati scritti/lettura.

Attributi chiave per NVMe (tramite smartctl -a /dev/nvme0):

• Percentage Used: La percentuale di resistenza alla scrittura consumata. L'indicatore principale dell'usura.
• Media and Data Integrity Errors: Errori di integrità dei dati.
• Critical Warning: Flag di avviso critico.
• Temperature: Temperatura attuale.

A questo punto, l'amministratore ottiene una comprensione generale della condizione del disco e può identificare segni evidenti di problemi.

Configurazione avanzata e scenari pratici

SMART supporta i test integrati, che vengono eseguiti dal disco stesso senza il coinvolgimento del sistema operativo.

Il test breve è progettato per un controllo rapido dei componenti chiave:

sudo smartctl -t short /dev/sda

Il test lungo esegue una scansione completa della superficie e richiede significativamente più tempo:

sudo smartctl -t long /dev/sda

Dopo il completamento del test, è necessario controllare i risultati:

sudo smartctl -l selftest /dev/sda

L'output indica:

• il tipo di test;
• lo stato di completamento;
• la presenza o assenza di errori.

Un test non riuscito è un motivo diretto per prepararsi alla sostituzione del disco.

Lavorare con i controller RAID

I controller RAID hardware spesso nascondono i dati SMART al sistema. In tali casi, è necessario specificare esplicitamente il tipo di dispositivo.

Esempio per un controller LSI:

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

Dove:

• -a – chiave per visualizzare tutte le informazioni SMART disponibili (attributi, log, errori, valutazione complessiva dello stato di salute).
• -d – chiave per specificare il tipo di dispositivo.
• megaraid – indica al driver SMART che il disco è dietro un controller LSI/Broadcom (comunemente usato nei server).
• 0 – il numero del disco fisico (PD, Physical Drive) nell'array RAID. Questo non è sda, ma un ID univoco assegnato dal controller. Può essere trovato utilizzando l'utilità di gestione del controller (ad es. storcli o MegaCLI).
• /dev/sda – in questo contesto, questo non è il disco reale, ma un pseudo-dispositivo che rappresenta il controller RAID stesso nel sistema. Tipicamente, questo è /dev/sgX (SCSI Generic) o semplicemente /dev/sda se il controller ha creato un disco virtuale.

Errore tipico quando il tipo di dispositivo non è specificato:

SMART support is: Unavailable

Questo non significa che SMART non sia disponibile – solo che smartctl non è riuscito a determinare automaticamente il percorso al disco fisico. La soluzione è specificare correttamente il parametro -d.

Diagnostica e risoluzione dei problemi

Segni di possibili malfunzionamenti:

• aumento del valore Reallocated_Sector_Ct;
• Current_Pending_Sector diverso da zero;
• errori di programmazione/cancellazione (Program_Fail_Count, Erase_Fail_Count);
• errori nei self-test;
• aumento della latenza I/O;
• messaggi di errore nei log di sistema.

Analisi dei log:

journalctl -u smartd

dmesg | grep -i error

Spiegazione:
Pending Sectors > 0 – alto rischio di guasto;
Reallocated Sectors in aumento – degrado progressivo;
Self-test FAILED – il disco deve essere sostituito.

Identificazione delle fonti dei problemi

Per escludere falsi positivi, è importante correlare i dati SMART con il carico effettivo.

iostat -x 1

iotop

Controllo di dove è montato il disco:

lsblk -o NAME,SERIAL,MOUNTPOINT

Identificazione dei controller:

lspci | grep -i raid

Metriche aggiuntive:

• temperatura superiore a 50 °C;
• aumento degli errori CRC;
• valori SMART instabili.

Configurazione delle notifiche per l'amministratore quando le metriche SMART si avvicinano ai valori soglia

La semplice presenza di dati SMART non garantisce ancora la sicurezza dell'infrastruttura. Un elemento chiave del monitoraggio è la notifica tempestiva dell'amministratore nel momento in cui la condizione del disco inizia a deteriorarsi, ma il guasto non si è ancora verificato.

Il meccanismo di notifica consente di:

• rilevare il degrado del disco in una fase iniziale;
• pianificare la sostituzione del disco in anticipo;
• evitare tempi di inattività imprevisti e perdita di dati;
• operare all'interno delle finestre di manutenzione programmate.

In smartmontools, il demone smartd è responsabile dell'invio delle notifiche. Traccia automaticamente i cambiamenti negli attributi SMART e risponde alle deviazioni dalla norma.

Principio di funzionamento delle notifiche di smartd

Il demone smartd funziona come un servizio in background e svolge i seguenti compiti:

1. Interroga periodicamente gli attributi SMART del disco.
2. Confronta i valori attuali con: soglie di fabbrica, valori precedenti (dinamica dei cambiamenti).
3. Rileva: crescita degli attributi critici, comparsa di nuovi errori, fallimenti nei self-test.
4. Genera una notifica e la invia all'amministratore.

Requisiti per il funzionamento delle notifiche

Prima della configurazione, è necessario assicurarsi di quanto segue:

• un MTA (Postfix, Exim, Sendmail, ssmtp) è installato e correttamente configurato nel sistema;
• il server è in grado di inviare posta in uscita;
• l'indirizzo email dell'amministratore per ricevere le notifiche è definito.

Esempio di configurazione di ssmtp – un MTA leggero e semplice per l'invio di posta dal sistema.

Installazione:

Debian/Ubuntu:

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

RHEL:

sudo dnf install ssmtp mailx

Crea il file di configurazione:

sudo nano /etc/ssmtp/ssmtp.conf

e modifica il contenuto:

# Indirizzo mittente predefinito
[email protected]

# Server SMTP e porta del tuo provider di posta elettronica
mailhub=smtp.your-domain.com:587
# Esempio alternativo:
# mailhub=smtp.gmail.com:587        # Per Gmail

# Credenziali di autenticazione
[email protected]
AuthPass=your-password

# Impostazioni di crittografia
UseSTARTTLS=YES    # Usa STARTTLS
UseTLS=YES         # Usa TLS
FromLineOverride=YES  # Consenti di sovrascrivere l'indirizzo del mittente

# Nome host (specifica il nome del tuo server)
hostname=server1.your-domain.com
# puoi usare hostname=localhost o specificare il nome effettivo del sistema

Salva il file e configura i permessi di accesso:

sudo chmod 640 /etc/ssmtp/ssmtp.conf

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

Configura i mittenti (revaliases):

sudo nano /etc/ssmtp/revaliases

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

Per l'invio corretto dei messaggi, le seguenti porte devono essere aperte sul server: 587 (principale per l'invio con crittografia STARTTLS), o 25 (SMTP standard), 465 (SMTP sicuro con SSL), se sono previste dalla configurazione.

Test di invio di posta di base:

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

Puoi specificare esplicitamente il mittente:

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

Oppure tramite ssmtp direttamente:

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

[email protected] – l'indirizzo del destinatario a cui verrà inviato il messaggio.

La configurazione delle notifiche SMART viene effettuata nel file:

/etc/smartd.conf

Esempio di una configurazione semplice e funzionante:

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

Parametri:

• /dev/sda – il disco monitorato;
• -a – set completo di controlli;
• -S on – il salvataggio degli attributi tra i riavvii è abilitato;
• -o on – la raccolta automatica dei dati offline è attivata;
• -m – le notifiche vengono inviate all'email specificata.

Da questo punto, smartd inizierà a monitorare lo stato del disco in background.

Notifiche quando si avvicinano ai valori soglia

Una caratteristica chiave di smartd è che monitora i cambiamenti nei valori degli attributi, non solo il loro superamento critico.

In pratica, questo significa che una notifica può essere inviata:

• alla prima comparsa di Current_Pending_Sector;
• all'aumento di Reallocated_Sector_Ct, anche se la soglia non è ancora stata raggiunta;
• alla rilevazione di errori nei self-test;
• alla degradazione dei parametri NVMe.

Gli attributi più significativi di guasto precoce:

• Reallocated_Sector_Ct
• Current_Pending_Sector
• Offline_Uncorrectable
• Errori di integrità dei dati e dei media (NVMe)
• Percentage Used (SSD/NVMe)

Anche i cambiamenti minimi in questi parametri dovrebbero essere considerati un motivo di attenzione.

Utilizzo dei self-test come fonte di notifica

Per aumentare l'informatività, si consiglia di combinare il monitoraggio degli attributi con self-test regolari.

Esempio di configurazione con un programma:

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

Logica di funzionamento:

• un test breve viene eseguito quotidianamente;
• un test completo viene eseguito una volta alla settimana;
• in caso di fallimento di qualsiasi test, l'amministratore riceve una notifica.

Gestione della frequenza e del volume delle notifiche

Per evitare avvisi eccessivi, viene utilizzato il parametro -M once:

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

In questa modalità:

• una notifica viene inviata al primo rilevamento di un problema;
• i messaggi successivi non vengono duplicati fino a quando la causa non viene risolta.

Per testare il sistema di notifica, puoi utilizzare -M test. Questo ti consente di verificare che smartd sia in grado di inviare messaggi senza aspettare un errore effettivo.

Conclusione

Nell'ambito di questo manuale, è stato esaminato sistematicamente l'intero ciclo di implementazione e funzionamento di smartctl e del demone smartd come strumento per il monitoraggio proattivo dello stato di salute dei dischi. Sono stati trattati i principi di base del funzionamento di SMART, i metodi pratici per l'analisi degli attributi, l'avvio e l'interpretazione dei self-test, le specificità del lavoro con i dischi NVMe e i controller RAID, nonché i metodi diagnostici e le tecniche per identificare le cause principali dei problemi. Particolare attenzione è stata dedicata alla configurazione delle notifiche, che consentono di rilevare il degrado del disco nelle fasi iniziali, anche prima che si verifichi un guasto critico.

Un monitoraggio SMART correttamente configurato è una parte integrante di un'infrastruttura server affidabile e dovrebbe essere considerato uno standard operativo obbligatorio. L'uso di smartctl e smartd consente all'amministratore di sistema di passare dalla risoluzione reattiva degli incidenti a una manutenzione consapevole e gestibile del sottosistema del disco, riducendo i rischi di tempi di inattività, perdita di dati e incidenti non pianificati, creando al contempo una solida base per ulteriori automazioni e integrazioni con sistemi di monitoraggio centralizzati.