Controllare lo stato dell'SSD di Sophos Firewall con SMART

Un valore SMART può essere utile durante una diagnosi hardware. Sulle XGS Appliances fisiche in cui l’SSD interno è montato come /dev/sda, una query smartctl in sola lettura restituisce l’attributo di endurance. Per SFOS 22.0, tuttavia, Sophos non documenta un comando amministrativo universale, un percorso disco fisso né una soglia di usura valida per tutti i modelli. Verifica quindi prima l’appliance, il nodo e il percorso del dispositivo e considera il valore un indizio diagnostico, non l’unico criterio per decidere una sostituzione.

Il percorso sicuro inizia da WebAdmin: controlla l’occupazione e il comportamento del sistema, genera un Consolidated troubleshooting report (CTR) e coinvolgi Sophos Support se sospetti un problema hardware. La query descritta di seguito legge i dati SMART disponibili e non avvia alcun self-test. Altri percorsi di dispositivo, test SMART o comandi di riparazione vanno utilizzati solo nell’ambito di uno specifico caso di supporto.

⚠️ Importante: La Advanced Shell consente l’accesso diretto al sistema. Non provare percorsi disco, non avviare self-test SMART, non modificare partizioni, non eliminare manualmente file e non sostituire autonomamente gli SSD. Anche system fsck-on-nextboot nella Device Console deve essere utilizzato solo su indicazione di Sophos Support: il comando aiuta in caso di errori di mount di /sig, /conf o /var, forza il controllo del file system di tutte le partizioni al riavvio successivo e, in presenza di hardware o SSD non integro, può danneggiare il file system. on, off e show attivano, disattivano o mostrano lo stato; l’impostazione predefinita è off. In modalità failsafe, SFOS può attivare automaticamente il controllo, ad esempio se i database di configurazione, report o firme non si avviano, se non è possibile applicare una migrazione o se manca la modalità di deployment. La procedura sicura è descritta in Diagnosticare la modalità failsafe di Sophos Firewall.

Percorso diagnostico sicuro

1. In WebAdmin, apri Diagnostics > System graphs, seleziona Disk usage come grafico e scegli un intervallo che includa l’inizio del problema.
2. Verifica se nello stesso periodo si sono verificati comportamenti anomali nei report, nei log, nella quarantena, in WebAdmin o nei servizi. La schermata Disk usage mostra lo spazio occupato, non l’usura dell’SSD o lo stato SMART.
3. Prima di un upgrade del firmware, controlla anche le indicazioni e le notifiche del firewall. Per determinati modelli XGS Appliance, SFOS 22.0 può segnalare un aggiornamento obbligatorio del firmware dell’SSD; in HA, i requisiti di upgrade vengono verificati separatamente per ciascun nodo.
4. In Diagnostics > Tools, alla voce Consolidated troubleshooting report, seleziona System snapshot e All log files, inserisci il motivo della diagnosi, quindi scegli Generate e poi Download. La modalità debug non è necessaria per il System Snapshot.
5. In caso di errori I/O, del file system, di avvio o di database ricorrenti, apri un caso presso Sophos Support e fornisci CTR, data e ora, sintomi e dati del dispositivo. Il supporto decide se sono necessarie ulteriori diagnosi tramite shell/SMART e un’eventuale RMA.

Per un semplice problema di spazio, consulta Controllare lo spazio di archiviazione di Sophos Firewall e gestire i report. Central Firewall Reporting può ridurre la dipendenza dai dati dei report locali. Un Sophos Firewall Health Check, invece, valuta i rischi di configurazione e non sostituisce una diagnosi hardware.

Cosa indicano i segnali visibili

Disk usage indica la capacità, non l’usura

In Diagnostics > System graphs > Disk usage, l’asse X mostra minuti, ore, giorni o mesi in base all’intervallo selezionato, mentre l’asse Y indica la percentuale di occupazione. La legenda distingue firme (arancione), file di configurazione (viola), report (verde) e memoria temporanea (blu). Un valore elevato può compromettere report e servizi, ma non dimostra un guasto dell’SSD. Allo stesso modo, lo spazio libero non fornisce informazioni su errori hardware o sulla vita residua in scrittura. Il grafico non contiene attributi SMART né soglie di usura.

Una notifica sul firmware dell’SSD non è un risultato SMART

Per alcuni modelli XGS Appliance, prima di installare SFOS 22.0 o versioni successive potrebbe essere obbligatorio aggiornare il firmware dell’SSD per migliorarne l’affidabilità. Se è necessario intervenire, viene visualizzata una notifica. Si tratta di un requisito di upgrade specifico del modello, non di un valore di endurance misurato né della prova automatica di un guasto.

Prima di un upgrade, verifica quindi di disporre di un backup aggiornato, spazio sufficiente, un percorso di upgrade supportato, le Release Notes e una finestra di manutenzione. In HA, entrambi i nodi devono essere raggiungibili, integri, sincronizzati e singolarmente idonei a soddisfare i requisiti di upgrade; se uno dei due non li soddisfa, l’upgrade può essere bloccato. Avvia l’upgrade solo dal Primary Device.

Gli output SMART sono dati diagnostici specifici del modello

Gli attributi SMART, i nomi dei dispositivi e il loro significato possono variare in base a SSD, controller, appliance e firmware.

Leggere l’endurance su un’XGS Appliance con /dev/sda

Accedi al firewall tramite SSH, apri la Advanced Shell e conferma di operare sull’appliance corretta o sul nodo HA corretto. Avanet ha eseguito la query su un’XGS 3100 con SFOS 21.5.1 MR-1 Build 261. Se l’SSD interno è montato come /dev/sda, questo comando legge tutti i dati SMART e mostra solo le righe contenenti Endurance:

smartctl -x /dev/sda | grep Endurance

Nell’esempio di Avanet, l’SSD restituisce il valore grezzo 1 per Percentage Used Endurance Indicator. Su questa unità, un valore basso indica che è stata consumata poca vita utile in scrittura. Non applicare però questa scala ad altri SSD senza verificarla: nome dell’attributo, normalizzazione e valore grezzo possono avere significati diversi a seconda del produttore e del modello. Un valore di 80 non costituisce quindi una soglia RMA universale di Sophos. Documenta l’andamento e considera anche i sintomi, gli errori I/O e la valutazione specifica del modello.

Il comando e la sua interpretazione dipendente dal modello sono già stati discussi pubblicamente in ambito pratico, perché non sono documentati nella guida di Sophos Firewall: Controllare la durata dell’SSD Sophos XGS su Administrator.de. L’articolo consiglia una sostituzione rapida quando il valore supera 80; Avanet sceglie consapevolmente di non adottare questo valore della community come soglia RMA universale di Sophos. Lo screenshot mostrato sopra proviene da un’appliance Avanet e non da quell’articolo.

Un SSD può guastarsi senza un precedente avviso di SFOS. L’HA protegge il traffico, ma non automaticamente tutti i dati archiviati localmente: log, Mail Queue e quarantena possono essere interessati dal guasto del nodo; Mail Queue e quarantena non vengono sincronizzate tra i nodi HA. Report centralizzati, backup aggiornati e una procedura di riavvio documentata riducono il rischio, ma non sostituiscono il monitoraggio dell’SSD.

Se non viene visualizzata alcuna riga, potrebbe non essere presente un attributo Endurance adatto, il percorso del dispositivo confermato potrebbe non essere corretto per quell’appliance oppure smartctl potrebbe non riuscire a leggere l’SSD in questo modo tramite il controller disponibile. Un output vuoto non dimostra né il buono stato né un guasto. Non provare altri nomi di dispositivo e non avviare un self-test SMART.

Per l’ulteriore valutazione valgono le seguenti regole:

• Utilizza /dev/sda solo se il percorso è stato confermato per l’appliance specifica; non tentare di indovinare percorsi NVMe o RAID.
• Non dedurre una soglia generale dai nomi di attributi quali Endurance, Percentage Used o Wear.
• Non interpretare un singolo valore o la differenza tra due nodi HA come una decisione di sostituzione.
• Non considerare l’assenza di output SMART una prova di integrità o di guasto.

In HA, il comando confermato viene eseguito separatamente su entrambi i nodi, perché ciascun nodo dispone di un proprio SSD. Conserva insieme output, data, fuso orario, versione SFOS e ruolo del nodo. Se sono presenti sintomi, valori elevati o in rapido aumento oppure attributi poco chiari, aggiungi anche il numero del caso e la valutazione di Sophos Support.

Documentare e convalidare il risultato

Una cronologia breve e coerente è più utile di un singolo valore:

• Data e ora con fuso orario: ad esempio 2026-09-05 10:30 CEST
• Appliance e sede: ad esempio XGS 2100 – HQ
• Numero di serie e, in HA, ruolo: Primary o Auxiliary
• Versione e build di SFOS
• Sintomo: avviso di spazio, errore I/O, errore di avvio, problema nei report o nel database
• Intervallo di Disk usage e variazione anomala
• File CTR e numero del caso di supporto
• Query SMART pratica: percorso del dispositivo confermato, comando esatto e output non modificato

La diagnosi non si conclude con un grafico normale o con un singolo valore SMART. Per convalidarla, occorre verificare che l’occupazione dello spazio e le funzioni interessate rimangano stabili dopo l’intervento sicuro e che gli errori non si ripresentino durante il periodo di osservazione concordato. Per i firewall virtuali, lo stato del disco, il datastore, la latenza I/O e gli errori rientrano principalmente nel monitoraggio dell’hypervisor e della piattaforma di storage.

In caso di sospetti relativi a temperatura o ventole, consulta Controllare temperatura e ventole tramite SSH; lo stato e l’andamento dei sensori hardware supportati possono essere integrati con SNMP Hardware Monitoring. Nessuno di questi controlli sostituisce la diagnosi dell’SSD eseguita da Sophos.

Se l’appliance è instabile o non raggiungibile

Non eseguire a tentativi comandi di riavvio, controllo del file system o riparazione. Documenta l’ultimo momento in cui l’appliance funzionava, le modifiche precedenti al problema, lo stato dei LED e la raggiungibilità tramite HTTPS, SSH e console seriale. In caso di perdita completa di alimentazione, prova prima un’altra presa e un altro cavo di alimentazione; sulle appliance con doppio alimentatore, verifica il secondo ingresso e, sui modelli predisposti, un altro alimentatore hot-swap. Una foto o un video dei LED e della sequenza di avvio accelera la verifica RMA.

Se l’appliance non si avvia, verifica HTTPS e SSH tramite LAN e WAN e accedi direttamente alla console seriale con DB-9, un convertitore Serial-to-USB o la porta console Micro-USB presente sui modelli XGS Appliance più recenti. Nel Device Manager del computer dell’amministratore, controlla eventuali errori di driver o connessione. Imposta 38400 baud, verifica lo stato a intervalli diversi e documenta con screenshot gli errori visibili. Se la console rimane inattiva, ripeti la prova con un altro cavo o computer. Solo Sophos può stabilire, dopo la propria verifica, se un dispositivo è DOA. La procedura interna completa è descritta in Guasto hardware Sophos: preparare RMA e sostituzione.

Se l’appliance è ancora raggiungibile, riproduci l’errore immediatamente prima della raccolta e annota l’ora esatta con il fuso orario. In Diagnostics > Tools > Consolidated troubleshooting report, seleziona System snapshot e All log files, inserisci il motivo, quindi fai clic su Generate e poi su Download. Carica il report crittografato nel caso di supporto. Alcuni log del CTR contengono solo il numero di righe configurato tramite CLI; per un evento meno recente, salva quindi anche singolarmente i Troubleshooting logs interessati. La modalità debug è disattivata per impostazione predefinita e non è necessaria per il System Snapshot; i log di debug aumentano lo spazio occupato e devono essere nuovamente disattivati al termine di una registrazione mirata. In HA, log e report non vengono sincronizzati: devono essere raccolti per ciascun nodo e associati in modo univoco. La procedura completa è descritta in Salvare i log di Sophos Firewall per supporto e analisi.

Se Sophos richiede l’accesso remoto per la diagnosi, in Diagnostics > Support access è possibile generare un Access ID con durata limitata. A tale scopo, il firewall stabilisce una connessione di controllo sicura in uscita tramite TCP 22 verso *.apu.sophos.com; un router a monte deve consentirla. Attiva Support access, conferma con OK, seleziona la durata, fai clic su Apply e di nuovo su OK, quindi copia l’ID univoco da Access status. Condividi l’Access ID esclusivamente nel caso di supporto. Sophos può così accedere a WebAdmin e alla shell senza la password amministratore; le sessioni inattive terminano dopo 15 minuti. L’accesso può essere disattivato in qualsiasi momento e viene disabilitato alla chiusura del caso. La procedura interna dettagliata è descritta in Abilitare Sophos Firewall Support Access per Avanet.

Preparare supporto e RMA

Prima dell’escalation, prepara:

• descrizione esatta dell’errore, inizio, frequenza e conseguenze;
• modello, revisione, numero di serie, versione e build di SFOS;
• stato HA e nodo interessato;
• andamento di Disk usage, messaggi di errore pertinenti e CTR;
• backup della configurazione aggiornato e scaricato;
• password di crittografia del backup e relativo Secure Storage Master Key disponibili in modo sicuro, ma da condividere solo attraverso il canale sicuro previsto da Sophos;
• stato della licenza e del supporto.

Un valore SMART non avvia automaticamente una RMA. Secondo Sophos, il processo RMA prevede innanzitutto l’identificazione dell’errore e la raccolta dei dati del dispositivo, seguite dall’apertura e dalla convalida del caso di supporto; Sophos può richiedere ulteriori diagnosi. Modello, revisione, versione del firmware, numero di serie e appartenenza a un cluster HA devono essere inclusi nel modulo RMA.

In HA occorre inoltre chiarire quale nodo verrà sostituito. La procedura di ricostruzione qui descritta vale solo per Active-Passive, non per Active-Active, e comporta un’interruzione del servizio. Prima di iniziare, registra modello, revisione, Primary iniziale, versione firmware e build di entrambi i dispositivi con system diagnostics show version-info.

• Preparare il dispositivo sostitutivo: Se la stessa build del firmware non è disponibile, richiedila a Sophos Support. Collega un client DHCP alla porta 1 e apri https://172.16.16.16:4444. Configura la porta 2 tramite Setup Assistant esclusivamente per WAN e accesso a Internet; inizialmente non creare altre interfacce. Dopo il reimage o l’aggiornamento, verifica nuovamente la build con system diagnostics show version-info.
• Sostituire l’Auxiliary: Il Primary integro continua temporaneamente a funzionare da solo. Porta il dispositivo sostitutivo alla stessa versione e build del firmware, eseguine il claim in Central e trasferisci la licenza dell’Auxiliary guasto. Sul Primary integro, disattiva HA, verifica con service -S | grep msync che lo stato sia UNTOUCHED o STOPPED, sposta i cavi e ricrea l’HA Active-Passive utilizzando il dispositivo integro come Primary.
• Sostituire il Primary: Deregistra da Central l’Auxiliary integro e, in My Products > Firewall Management > Firewalls, verifica che non compaia più nell’elenco. Salva il suo backup aggiornato. Porta il dispositivo sostitutivo alla stessa versione e build del firmware, eseguine il claim, trasferisci la licenza, ripristina il backup e, dopo aver spostato i cavi, fallo subentrare nel traffico come dispositivo standalone. Ripristina quindi le impostazioni di fabbrica dell’ex Auxiliary integro, eseguine nuovamente il claim e riconfigura l’HA Active-Passive con il dispositivo sostitutivo come Primary.

La sostituzione rende disponibile l’hardware, ma non garantisce che il sistema sia operativo. Documenta prima della finestra di manutenzione il trasferimento della licenza, la compatibilità del backup, l’associazione in Central, il cablaggio e il test funzionale. Le nozioni di base sui ruoli sono descritte in Cluster HA Sophos Firewall: Active-Passive, Active-Active e Auxiliary Appliance.

Le basi relative a garanzia e supporto sono riepilogate in Per quanto tempo ricevo garanzia sull’hardware Sophos?. Se Sophos richiede un reimage, segui la procedura separata Reinstallare Sophos Firewall OS: reimage con chiavetta USB.

Controllo finale

• Disk usage e intervallo verificati senza interpretare la capacità come stato dell’SSD.
• Sintomi, andamento temporale, modello, numero di serie, versione SFOS e nodo HA documentati.
• Backup aggiornato conservato all’esterno dell’appliance e segreti di ripristino disponibili.
• CTR con System snapshot e All log files generato e salvato in modo sicuro.
• Nessun percorso di dispositivo ipotizzato e nessun self-test SMART né comando fsck, di eliminazione o di riparazione eseguito senza autorizzazione.
• Caso di supporto aperto in presenza di un sospetto hardware; ulteriori diagnosi eseguite solo su indicazione specifica del supporto.
• RMA o sostituzione dell’hardware pianificata solo dopo la convalida da parte di Sophos.

FAQ