Vérifier la santé du SSD de Sophos Firewall via SMART

Une valeur SMART peut être utile lors d’un diagnostic matériel. Sur les XGS Appliances physiques dont le SSD interne est monté sous /dev/sda, une requête smartctl en lecture seule renvoie l’attribut d’endurance. Pour SFOS 22.0, Sophos ne documente toutefois ni commande d’administration universelle, ni chemin de disque fixe, ni seuil d’usure valable pour tous les modèles. Commencez donc par vérifier l’appliance, le nœud et le chemin du périphérique, puis considérez la valeur comme un indice de diagnostic et non comme un critère suffisant pour décider d’un remplacement.

La procédure sûre commence dans WebAdmin : contrôlez l’occupation du stockage et le comportement du système, générez un Consolidated troubleshooting report (CTR) et contactez Sophos Support si vous suspectez un problème matériel. La requête présentée ci-dessous ne fait que lire les données SMART existantes et ne lance aucun autotest. Les autres chemins de périphérique, tests SMART ou commandes de réparation ne doivent être utilisés que dans le cadre d’un dossier de support précis.

⚠️ Important : L’Advanced Shell donne un accès direct au système. N’essayez pas différents chemins de disque, ne lancez pas d’autotest SMART, ne modifiez pas les partitions, ne supprimez pas manuellement des fichiers et ne remplacez pas vous-même le SSD. Même system fsck-on-nextboot, dans la Device Console, ne doit être utilisé que sur recommandation de Sophos Support : cette commande peut aider en cas d’erreur de montage de /sig, /conf ou /var, mais elle force la vérification du système de fichiers de toutes les partitions au prochain redémarrage et peut l’endommager si le matériel ou le SSD est défectueux. on, off et show servent respectivement à activer, désactiver ou afficher l’état ; la valeur par défaut est off. En mode Failsafe, SFOS peut activer automatiquement la vérification, par exemple si la base de données de configuration, de rapports ou de signatures ne démarre pas, si une migration ne peut pas être appliquée ou si le mode de déploiement est absent. La procédure sûre est décrite dans Diagnostiquer le mode Failsafe de Sophos Firewall.

Procédure de diagnostic sûre

1. Dans WebAdmin, ouvrez Diagnostics > System graphs, sélectionnez le graphique Disk usage, puis une période couvrant le début de l’incident.
2. Vérifiez si les rapports, les logs, la quarantaine, WebAdmin ou certains services présentent simultanément des anomalies. Le graphique Disk usage indique l’espace occupé, pas l’usure du SSD ni son état SMART.
3. Avant une mise à niveau du firmware, vérifiez également les avertissements et notifications du pare-feu. Pour certains modèles XGS Appliance, SFOS 22.0 peut signaler qu’une mise à jour du firmware du SSD est requise ; en HA, chaque nœud est contrôlé séparément par rapport aux prérequis de mise à niveau.
4. Sous Diagnostics > Tools, dans Consolidated troubleshooting report, sélectionnez System snapshot et All log files, indiquez le motif du diagnostic, cliquez sur Generate, puis sur Download. Le mode debug n’est pas nécessaire pour le System Snapshot.
5. En cas d’erreurs d’E/S, de système de fichiers, de démarrage ou de base de données récurrentes, ouvrez un dossier auprès de Sophos Support et fournissez le CTR, l’heure, les symptômes et les informations de l’appareil. Le support décide des diagnostics Shell ou SMART supplémentaires et d’une éventuelle RMA.

Pour un simple problème d’espace, consultez Vérifier l’espace de stockage de Sophos Firewall et gérer les rapports. Central Firewall Reporting peut réduire la dépendance aux données de rapports locales. En revanche, un Sophos Firewall Health Check évalue les risques de configuration et ne remplace pas un diagnostic matériel.

Comprendre les signaux visibles

Disk usage mesure la capacité, pas l’usure

Sous Diagnostics > System graphs > Disk usage, l’axe X représente, selon la période choisie, des minutes, des heures, des jours ou des mois, et l’axe Y le taux d’occupation en pourcentage. La légende distingue les signatures en orange, les fichiers de configuration en violet, les rapports en vert et le stockage temporaire en bleu. Un taux élevé peut perturber les rapports et les services, mais ne prouve pas que le SSD est défectueux. Inversement, de l’espace disponible ne permet de conclure ni à l’absence d’erreur matérielle ni à la durée de vie restante en écriture. Le graphique ne contient aucun attribut SMART ni seuil d’usure.

Une notification de firmware SSD n’est pas un résultat SMART

Pour certains modèles XGS Appliance, une mise à jour du firmware du SSD visant à améliorer la fiabilité peut être obligatoire avant le passage à SFOS 22.0 ou à une version ultérieure. Une notification apparaît lorsqu’une intervention est nécessaire. Il s’agit d’un prérequis de mise à niveau propre au modèle, et non d’une mesure d’endurance ou d’un défaut constaté automatiquement.

Avant une mise à niveau, vérifiez donc que vous disposez d’une sauvegarde récente et d’un espace suffisant, ainsi que d’un chemin de mise à niveau pris en charge, des Release Notes et d’une fenêtre de maintenance. En HA, les deux nœuds doivent être joignables, sains, synchronisés et satisfaire séparément aux prérequis ; si l’un d’eux ne les remplit pas, la mise à niveau peut être bloquée. Lancez la mise à niveau uniquement depuis le Primary Device.

Les données SMART dépendent du modèle

Les attributs SMART, les noms de périphérique et leur signification peuvent varier selon le SSD, le contrôleur, l’appliance et le firmware.

Lire l’endurance sur une XGS Appliance utilisant /dev/sda

Connectez-vous au pare-feu par SSH, ouvrez l’Advanced Shell et vérifiez que vous intervenez sur la bonne appliance ou sur le bon nœud HA. Avanet a exécuté cette requête sur une XGS 3100 sous SFOS 21.5.1 MR-1 Build 261. Lorsque le SSD interne y est monté sous /dev/sda, la commande suivante lit toutes les données SMART et n’affiche que les lignes contenant Endurance :

smartctl -x /dev/sda | grep Endurance

Dans l’exemple d’Avanet, le SSD renvoie la valeur brute 1 pour Percentage Used Endurance Indicator. Sur ce disque, une valeur basse correspond à une faible consommation de la durée de vie en écriture. N’appliquez cependant pas cette échelle sans vérification à d’autres SSD : le nom de l’attribut, sa normalisation et sa valeur brute peuvent être définis différemment selon le fabricant et le modèle. Une valeur de 80 ne constitue donc pas un seuil RMA universel de Sophos. Consignez son évolution et tenez compte des symptômes, des erreurs d’E/S et de l’interprétation propre au modèle.

La commande et son interprétation selon le modèle ont déjà fait l’objet d’une discussion publique, car elles ne sont pas documentées dans l’aide de Sophos Firewall : Vérifier la durée de vie du SSD d’une Sophos XGS sur Administrator.de. L’article recommande un remplacement rapide au-delà d’une valeur de 80 ; Avanet choisit expressément de ne pas reprendre cette valeur communautaire comme seuil RMA universel de Sophos. La capture d’écran ci-dessus provient d’une appliance Avanet et non de cet article.

Un SSD peut tomber en panne sans avertissement préalable de SFOS. Le HA protège le trafic, mais pas automatiquement toutes les données enregistrées localement : les logs, la Mail Queue et la quarantaine peuvent être affectés sur le nœud défaillant ; la Mail Queue et la quarantaine ne sont pas synchronisées entre les nœuds HA. Les rapports centralisés, les sauvegardes récentes et une procédure de redémarrage documentée réduisent le risque, mais ne remplacent pas la surveillance du SSD.

Si aucune ligne ne s’affiche, soit aucun attribut Endurance approprié n’est disponible, soit le chemin de périphérique confirmé n’est pas correct pour cette appliance, soit smartctl ne peut pas lire le SSD de cette manière via le contrôleur présent. Une sortie vide ne prouve ni que le disque est sain ni qu’il est défectueux. N’essayez pas d’autres noms de périphérique et ne lancez pas d’autotest SMART.

Pour interpréter le résultat :

• utilisez /dev/sda uniquement si ce chemin est confirmé pour l’appliance concernée ; ne devinez pas les chemins NVMe ou RAID ;
• ne déduisez pas de seuil général à partir de noms d’attribut tels que Endurance, Percentage Used ou Wear ;
• ne décidez pas d’un remplacement sur la base d’une valeur isolée ou de l’écart entre deux nœuds HA ;
• ne considérez pas l’absence de sortie SMART comme une preuve que le disque est sain ou défectueux.

En HA, exécutez séparément la commande confirmée sur les deux nœuds, car chacun possède son propre SSD. Conservez ensemble la sortie, la date, le fuseau horaire, la version de SFOS et le rôle du nœud. En présence de symptômes, de valeurs élevées ou augmentant rapidement, ou encore d’attributs ambigus, ajoutez le numéro du dossier et l’évaluation de Sophos Support.

Documenter et valider le résultat

Un historique bref et cohérent est plus utile qu’une valeur isolée :

• Date et heure avec fuseau horaire : par exemple 2026-09-05 10:30 CEST
• Appliance et site : par exemple XGS 2100 – HQ
• Numéro de série et, en HA, rôle du nœud : Primary ou Auxiliary
• Version et build de SFOS
• Symptôme : alerte d’espace, erreur d’E/S, erreur de démarrage, problème de rapport ou de base de données
• Période de Disk usage et évolution inhabituelle
• Fichier CTR et numéro du dossier de support
• Requête SMART pratique : chemin de périphérique confirmé, commande exacte et sortie inchangée

Un graphique normal ou une valeur SMART isolée ne suffit pas à clore le diagnostic. Pour valider la situation, vérifiez si l’occupation du stockage et les fonctions concernées restent stables après la mesure sûre, et si les erreurs réapparaissent pendant la période d’observation convenue. Pour les pare-feu virtuels, l’état du disque, le datastore, la latence d’E/S et les erreurs doivent principalement être surveillés au niveau de l’hyperviseur et de la plateforme de stockage.

En cas de soupçon lié à la température ou aux ventilateurs, consultez Vérifier la température et les ventilateurs via SSH ; la supervision matérielle par SNMP permet en outre de suivre l’état et l’historique des capteurs matériels pris en charge. Aucun de ces contrôles ne remplace le diagnostic du SSD par Sophos.

Si l’appliance est instable ou inaccessible

N’exécutez pas de commande de redémarrage, de système de fichiers ou de réparation au hasard. Consignez la dernière heure de fonctionnement normal, les modifications précédant l’incident, l’état des LED et l’accessibilité par HTTPS, SSH et console série. En cas de panne d’alimentation complète, testez d’abord une autre prise et un autre câble secteur ; sur les appliances à double bloc d’alimentation, vérifiez la seconde entrée et, sur les modèles prévus à cet effet, essayez un autre bloc hot-swap. Une photo ou une vidéo des LED et du comportement au démarrage accélère l’examen de la RMA.

Si l’appliance ne démarre pas, testez HTTPS et SSH via le LAN et le WAN, ainsi que la console série directement au moyen du port DB-9, d’un adaptateur Serial-to-USB ou du port console Micro-USB présent sur les XGS Appliances récentes. Dans le Device Manager du poste d’administration, recherchez les erreurs de pilote ou de connexion. Réglez la vitesse sur 38400 bauds, contrôlez l’état à plusieurs intervalles et documentez les erreurs visibles par des captures d’écran. Si la console reste muette, refaites le test avec un second câble ou un autre ordinateur. Sophos ne décide qu’après sa propre vérification si l’appareil doit être considéré comme DOA. La procédure interne complète est décrite dans Défaillance matérielle Sophos : préparer une RMA et un remplacement.

Si l’appliance reste accessible, reproduisez l’erreur juste avant la collecte et notez l’heure exacte avec le fuseau horaire. Sous Diagnostics > Tools > Consolidated troubleshooting report, sélectionnez System snapshot et All log files, saisissez le motif, cliquez sur Generate, puis sur Download. Chargez le rapport chiffré dans le dossier de support. Certains logs du CTR ne contiennent que le nombre de lignes configuré dans la CLI ; pour un événement ancien, sauvegardez donc aussi séparément les Troubleshooting logs concernés. Le mode debug est désactivé par défaut et n’est pas nécessaire pour le System Snapshot ; les logs de debug utilisent davantage d’espace et doivent être désactivés après une collecte ciblée. En HA, les logs et les rapports ne sont pas synchronisés : ils doivent être recueillis sur chaque nœud et clairement attribués. La procédure complète est décrite dans Sauvegarder les logs de Sophos Firewall pour le support et l’analyse.

Si Sophos demande un accès distant pour le diagnostic, vous pouvez générer un Access ID à durée limitée sous Diagnostics > Support access. Le pare-feu établit alors une connexion de contrôle sécurisée en sortie sur le port TCP 22 vers *.apu.sophos.com ; un routeur placé en amont doit autoriser cette connexion. Activez Support access, confirmez avec OK, choisissez la durée, cliquez sur Apply, puis à nouveau sur OK, et copiez l’identifiant unique affiché sous Access status. Ne communiquez l’Access ID que dans le dossier de support. Sophos l’utilise pour accéder à WebAdmin et au Shell sans mot de passe d’administration ; les sessions inactives prennent fin après 15 minutes. L’accès peut être désactivé à tout moment et est désactivé à la clôture du dossier. La procédure interne détaillée est décrite dans Autoriser Sophos Firewall Support Access pour Avanet.

Préparer le support et la RMA

Avant l’escalade, réunissez les éléments suivants :

• description précise de l’erreur, début, fréquence et conséquences ;
• modèle, révision, numéro de série, version et build de SFOS ;
• état HA et nœud concerné ;
• historique de Disk usage, messages d’erreur pertinents et CTR ;
• sauvegarde récente de la configuration, téléchargée hors de l’appliance ;
• mot de passe de chiffrement de la sauvegarde et Secure Storage Master Key correspondante disponibles en lieu sûr, mais à ne transmettre que par le moyen sécurisé prévu par Sophos ;
• état de la licence et du support.

Une valeur SMART ne déclenche pas automatiquement une RMA. Selon Sophos, la procédure RMA commence par l’identification de l’erreur et la collecte des informations de l’appareil, puis se poursuit par l’ouverture et la validation d’un dossier de support ; Sophos peut demander des diagnostics supplémentaires. Le modèle, la révision, la version du firmware, le numéro de série et l’appartenance HA doivent figurer dans le formulaire RMA.

En HA, il faut aussi déterminer quel nœud sera remplacé. La reconstruction décrite ici s’applique uniquement au mode Active-Passive, et non au mode Active-Active, et entraîne une interruption. Relevez au préalable le modèle, la révision, l’appareil initialement Primary ainsi que la version et le build du firmware des deux appareils avec system diagnostics show version-info.

• Préparer l’appareil de remplacement : Si le même build de firmware n’est pas disponible, demandez-le à Sophos Support. Connectez un client DHCP au port 1 et ouvrez https://172.16.16.16:4444. Dans le Setup Assistant, configurez le port 2 uniquement pour le WAN et l’accès à Internet ; ne créez pas encore d’autres interfaces. Après le reimage ou la mise à jour, vérifiez à nouveau le build avec system diagnostics show version-info.
• Remplacer l’Auxiliary : Le Primary sain fonctionne temporairement seul. Installez sur l’appareil de remplacement la même version et le même build du firmware, enregistrez-le dans Central et transférez-lui la licence de l’Auxiliary défectueux. Désactivez HA sur le Primary sain et utilisez service -S | grep msync pour confirmer l’état UNTOUCHED ou STOPPED, puis remplacez le câblage et reconstruisez le HA Active-Passive en conservant l’appareil sain comme Primary.
• Remplacer le Primary : Désenregistrez l’Auxiliary sain de Central et vérifiez sous My Products > Firewall Management > Firewalls qu’il n’apparaît plus. Sauvegardez sa configuration actuelle. Installez sur l’appareil de remplacement la même version et le même build du firmware, enregistrez-le, transférez la licence, restaurez la sauvegarde et, après avoir remplacé les câbles, faites-lui reprendre seul le trafic. Réinitialisez ensuite l’ancien Auxiliary sain aux paramètres d’usine, enregistrez-le à nouveau et reconfigurez le HA Active-Passive avec l’appareil de remplacement comme Primary.

Le remplacement fournit un nouveau matériel, mais ne garantit pas qu’il soit immédiatement opérationnel. Avant la fenêtre de maintenance, documentez le transfert de licence, la compatibilité de la sauvegarde, l’affectation dans Central, le câblage et le test fonctionnel. Les rôles sont expliqués dans Cluster HA Sophos Firewall : Active-Passive, Active-Active et appliance Auxiliary.

Les principes de garantie et de support sont résumés dans Combien de temps le matériel Sophos est-il sous garantie ?. Si Sophos demande un reimage, suivez la procédure distincte Réinstaller Sophos Firewall OS : reimage avec une clé USB.

Contrôle final

• Disk usage et la période ont été vérifiés sans confondre capacité et santé du SSD.
• Les symptômes, leur évolution, le modèle, le numéro de série, la version de SFOS et le nœud HA ont été documentés.
• Une sauvegarde récente a été conservée hors de l’appliance et les secrets de restauration sont disponibles.
• Un CTR avec System snapshot et All log files a été généré et conservé en lieu sûr.
• Aucun chemin de périphérique n’a été deviné et aucun autotest SMART ni commande fsck, de suppression ou de réparation n’a été exécuté sans autorisation.
• En cas de soupçon matériel, un dossier de support a été ouvert ; tout diagnostic supplémentaire suit une instruction précise du support.
• Une RMA ou un remplacement matériel n’est planifié qu’après validation par Sophos.

FAQ