Sophos Firewall SSD-Gesundheit per SMART prüfen

Ein SMART-Wert kann bei einer Hardwarediagnose nützlich sein. Auf physischen XGS Appliances, deren interne SSD als /dev/sda eingebunden ist, liefert eine lesende smartctl-Abfrage den Endurance-Eintrag. Für SFOS 22.0 dokumentiert Sophos allerdings keinen allgemeinen Administratorbefehl, keinen festen Datenträgerpfad und keinen modellübergreifenden Verschleissgrenzwert. Prüfe deshalb zuerst Appliance, Node und Gerätepfad und behandle den Wert als Diagnosehinweis, nicht als alleinige Austauschentscheidung.

Der sichere Weg beginnt im WebAdmin: Belegung und Systemverhalten prüfen, einen Consolidated troubleshooting report (CTR) erzeugen und bei Hardwareverdacht Sophos Support einbeziehen. Die unten dokumentierte Abfrage liest vorhandene SMART-Daten und startet keinen Selbsttest. Weitere Gerätepfade, SMART-Tests oder Reparaturbefehle gehören nur in einen konkreten Supportfall.

⚠️ Wichtig: Die Advanced Shell bietet direkten Systemzugriff. Keine Datenträgerpfade ausprobieren, SMART-Selbsttests starten, Partitionen verändern, Dateien manuell löschen oder SSDs eigenständig ersetzen. Selbst system fsck-on-nextboot in der Device Console darf nur auf Empfehlung des Sophos Supports verwendet werden: Der Befehl hilft bei Mount-Fehlern von /sig, /conf oder /var, erzwingt beim nächsten Neustart die Dateisystemprüfung aller Partitionen und kann bei ungesunder Hardware oder SSD das Dateisystem beschädigen. on, off und show aktivieren, deaktivieren oder zeigen den Zustand; Standard ist off. Im Failsafe-Modus kann SFOS die Prüfung automatisch einschalten, etwa wenn Konfigurations-, Report- oder Signaturdatenbank nicht starten, eine Migration nicht angewendet werden kann oder der Deployment-Modus fehlt. Der sichere Ablauf steht unter Sophos Firewall Failsafe Mode diagnostizieren.

Sicherer Diagnoseweg

1. Im WebAdmin zu Diagnostics > System graphs gehen, als Graph Disk usage wählen und einen Zeitraum auswählen, der den Beginn der Störung einschliesst.
2. Prüfen, ob gleichzeitig Reports, Logs, Quarantäne, WebAdmin oder Dienste auffällig sind. Die Disk-usage-Anzeige zeigt belegten Speicherplatz, nicht SSD-Verschleiss oder SMART-Gesundheit.
3. Vor einem Firmware-Upgrade zusätzlich die Hinweise und Benachrichtigungen der Firewall prüfen. SFOS 22.0 kann für bestimmte XGS-Appliance-Modelle ein erforderliches SSD-Firmware-Update melden; in HA wird jeder Node separat auf die Upgrade-Anforderungen geprüft.
4. Unter Diagnostics > Tools bei Consolidated troubleshooting report die Optionen System snapshot und All log files wählen, den Diagnosegrund eintragen, Generate und danach Download auswählen. Debug-Modus ist für den System Snapshot nicht nötig.
5. Bei I/O-, Dateisystem-, Boot- oder wiederkehrenden Datenbankfehlern einen Sophos Support Case eröffnen und CTR, Zeitpunkt, Symptome und Gerätedaten bereitstellen. Support entscheidet über zusätzliche Shell-/SMART-Diagnosen und eine mögliche RMA.

Bei einem reinen Speicherplatzproblem hilft Sophos Firewall Speicherplatz prüfen und Reports verwalten. Central Firewall Reporting kann die Abhängigkeit von lokalen Reportdaten reduzieren. Ein Sophos Firewall Health Check bewertet hingegen Konfigurationsrisiken und ersetzt keine Hardwarediagnose.

Was die sichtbaren Signale bedeuten

Disk usage ist Kapazität, nicht Verschleiss

Unter Diagnostics > System graphs > Disk usage zeigt die X-Achse je nach Zeitraum Minuten, Stunden, Tage oder Monate und die Y-Achse die prozentuale Belegung. Die Legende trennt Signaturen (Orange), Konfigurationsdateien (Violett), Reports (Grün) und temporären Speicher (Blau). Ein hoher Wert kann Reports und Dienste beeinträchtigen, beweist aber keinen SSD-Defekt. Umgekehrt ist freie Kapazität keine Aussage über Hardwarefehler oder verbleibende Schreib-Lebensdauer. Der Graph enthält weder SMART-Attribute noch Verschleissgrenzen.

SSD-Firmware-Hinweis ist kein SMART-Befund

Für einen Teil der XGS-Appliance-Modelle kann vor SFOS 22.0 oder neuer ein SSD-Firmware-Update zur Verbesserung der Zuverlässigkeit verpflichtend sein. Wenn Handlungsbedarf besteht, erscheint eine Benachrichtigung. Das ist eine modellbezogene Upgrade-Voraussetzung und weder ein gemessener Endurance-Wert noch automatisch ein Defekt.

Vor einem Upgrade deshalb aktuelles Backup, verfügbaren Speicherplatz, unterstützten Upgrade-Pfad, Release Notes und ein Wartungsfenster prüfen. Bei HA müssen beide Nodes erreichbar, gesund, synchron und unabhängig für die Upgrade-Anforderungen geeignet sein; erfüllt einer die Vorgaben nicht, kann dies das Upgrade blockieren. Das Upgrade nur vom Primary Device starten.

SMART-Ausgaben sind modellabhängige Diagnosedaten

SMART-Attribute, Gerätenamen und deren Bedeutung können sich nach SSD, Controller, Appliance und Firmware unterscheiden.

Endurance auf einer XGS Appliance mit /dev/sda auslesen

Melde dich per SSH an der Firewall an, öffne die Advanced Shell und bestätige, dass du auf der richtigen Appliance beziehungsweise beim richtigen HA-Node arbeitest. Avanet hat die Abfrage auf einer XGS 3100 unter SFOS 21.5.1 MR-1 Build 261 ausgeführt. Ist die interne SSD dort als /dev/sda eingebunden, liest dieser Befehl die vollständigen SMART-Daten und zeigt nur Zeilen mit Endurance:

smartctl -x /dev/sda | grep Endurance

Im Avanet-Beispiel meldet die SSD den Rohwert 1 für Percentage Used Endurance Indicator. Auf diesem Laufwerk steht ein niedriger Wert für wenig verbrauchte Schreib-Lebensdauer. Übertrage die Skala aber nicht ungeprüft auf andere SSDs: Attributname, Normalisierung und Rohwert können je nach Hersteller und Modell anders belegt sein. Ein Wert von 80 ist daher kein universeller Sophos-RMA-Grenzwert. Dokumentiere den Verlauf und beziehe Symptome, I/O-Fehler und die modellspezifische Bewertung ein.

Der Befehl und seine modellabhängige Interpretation wurden bereits öffentlich in der Praxis diskutiert, weil sie in der Sophos-Firewall-Hilfe nicht dokumentiert sind: Sophos XGS SSD-Lebensdauer prüfen auf Administrator.de. Der Beitrag empfiehlt bei einem Wert über 80 einen raschen Austausch; Avanet übernimmt diesen Community-Wert bewusst nicht als universelle Sophos-RMA-Grenze. Der oben gezeigte Screenshot stammt von einer Avanet-Appliance und nicht aus diesem Beitrag.

Ein SSD-Ausfall kann ohne vorherige SFOS-Warnung auftreten. HA schützt den Datenverkehr, aber nicht automatisch alle lokal gespeicherten Daten: Logs, Mail Queue und Quarantäne können vom ausgefallenen Node betroffen sein; Mail Queue und Quarantäne werden zwischen HA-Nodes nicht synchronisiert. Zentrale Reports, aktuelle Backups und ein dokumentierter Wiederanlauf reduzieren das Risiko, ersetzen aber keine SSD-Überwachung.

Wenn keine Zeile erscheint, fehlt entweder ein passendes Endurance-Attribut, der bestätigte Gerätepfad stimmt für diese Appliance nicht oder smartctl kann die SSD über den vorhandenen Controller nicht entsprechend auslesen. Eine leere Ausgabe ist weder ein Gesundheits- noch ein Defektnachweis. Führe nicht versuchsweise weitere Gerätenamen oder einen SMART-Selbsttest aus.

Für die weitere Einordnung gilt:

• /dev/sda nur verwenden, wenn dieser Pfad für die konkrete Appliance bestätigt ist; NVMe- oder RAID-Pfade nicht erraten.
• Nicht aus Attributnamen wie Endurance, Percentage Used oder Wear einen allgemeinen Grenzwert ableiten.
• Einen einzelnen Wert oder den Unterschied zwischen zwei HA-Nodes nicht als Austauschentscheid interpretieren.
• Eine fehlende SMART-Ausgabe weder als gesund noch als defekt werten.

Bei HA wird der bestätigte Befehl auf beiden Nodes separat ausgeführt, weil jeder Node eine eigene SSD besitzt. Speichere Ausgabe, Datum, Zeitzone, SFOS-Version und Node-Rolle zusammen. Sobald Symptome, hohe oder schnell steigende Werte beziehungsweise unklare Attribute vorliegen, kommen zusätzlich Case-Nummer und die Bewertung durch Sophos Support hinzu.

Befund dokumentieren und validieren

Eine kurze, konsistente Historie hilft mehr als ein einzelner Wert:

• Datum und Uhrzeit mit Zeitzone: beispielsweise 2026-09-05 10:30 CEST
• Appliance und Standort: beispielsweise XGS 2100 – HQ
• Seriennummer und bei HA die Rolle: Primary oder Auxiliary
• SFOS-Version und Build
• Symptom: Speicherwarnung, I/O-Fehler, Bootfehler, Report- oder Datenbankproblem
• Disk-usage-Zeitraum und auffällige Änderung
• CTR-Datei und Support-Case-Nummer
• SMART-Praxisabfrage: bestätigter Gerätepfad, exakter Befehl und unveränderte Ausgabe

Die Diagnose ist nicht allein durch einen normalen Graphen oder einen einzelnen SMART-Wert abgeschlossen. Als Validierung sollte man prüfen, ob Speicherbelegung und betroffene Funktionen nach der sicheren Massnahme stabil bleiben und ob die Fehler im vereinbarten Beobachtungszeitraum wiederkehren. Bei virtuellen Firewalls gehören Datenträgerzustand, Datastore, I/O-Latenz und Fehler primär in das Monitoring von Hypervisor und Storage-Plattform.

Für Temperatur- oder Lüfterverdacht passt Temperatur und Lüfter per SSH prüfen; Status und Verlauf unterstützter Hardware-Sensoren lassen sich mit SNMP Hardware Monitoring ergänzen. Keiner dieser Checks ersetzt die SSD-Diagnose durch Sophos.

Wenn die Appliance instabil oder nicht erreichbar ist

Keine Neustart-, Dateisystem- oder Reparaturkommandos auf Verdacht ausführen. Den letzten funktionierenden Zeitpunkt, Änderungen vor der Störung, LED-Zustand und Erreichbarkeit über HTTPS, SSH und serielle Konsole dokumentieren. Bei vollständigem Stromausfall zuerst eine andere Steckdose und ein anderes Stromkabel testen; bei Dual-PSU-Appliances den zweiten Eingang und bei dafür vorgesehenen Modellen ein anderes Hot-Swap-Netzteil prüfen. Foto oder Video des LED- und Startverhaltens beschleunigen die RMA-Prüfung.

Bei einer nicht bootenden Appliance prüft man HTTPS und SSH über LAN und WAN sowie die serielle Konsole direkt per DB-9, Serial-to-USB-Konverter oder dem bei neueren XGS Appliances vorhandenen Micro-USB-Konsolenport. Im Device Manager des Admin-Rechners auf Treiber- oder Verbindungsfehler achten. 38400 Baud einstellen, den Zustand in mehreren Zeitabständen prüfen und sichtbare Fehler per Screenshot belegen. Bleibt die Konsole stumm, mit einem zweiten Kabel oder Rechner gegenprüfen. Ob ein Gerät als DOA gilt, entscheidet Sophos erst nach eigener Prüfung. Der vollständige interne Ablauf steht unter Sophos Hardwaredefekt: RMA und Austausch vorbereiten.

Ist die Appliance noch erreichbar, Fehler unmittelbar vor der Erfassung reproduzieren und den genauen Zeitpunkt mit Zeitzone notieren. Unter Diagnostics > Tools > Consolidated troubleshooting report System snapshot und All log files wählen, den Grund eintragen, Generate und danach Download anklicken. Den verschlüsselten Bericht lädt man in den Support Case hoch. Einige CTR-Logs enthalten nur die per CLI konfigurierte Zeilenanzahl; bei einem älteren Ereignis daher die betroffenen Troubleshooting logs zusätzlich einzeln sichern. Debug-Modus ist standardmässig aus und für den System Snapshot nicht nötig; Debug-Logs vergrössern den Speicherbedarf und sind nach einer gezielten Aufzeichnung wieder auszuschalten. In HA sind Logs und Reports nicht synchronisiert und werden pro Node gesammelt und eindeutig zugeordnet. Der vollständige Ablauf steht unter Sophos Firewall Logs für Support und Analyse sichern.

Wenn Sophos für die Diagnose Fernzugriff anfordert, lässt sich unter Diagnostics > Support access eine zeitlich begrenzte Access ID erzeugen. Die Firewall baut dafür ausgehend über TCP 22 zu *.apu.sophos.com eine sichere Steuerverbindung auf; ein vorgeschalteter Router muss dies erlauben. Support access einschalten, mit OK bestätigen, Dauer wählen, Apply und nochmals OK anklicken und die eindeutige ID unter Access status kopieren. Die Access ID nur im Support Case teilen. Sophos greift damit ohne Admin-Kennwort auf WebAdmin und Shell zu, inaktive Sitzungen enden nach 15 Minuten. Der Zugriff lässt sich jederzeit ausschalten und wird nach dem Case deaktiviert. Der interne Detailablauf steht unter Sophos Firewall Support Access für Avanet freigeben.

Support und RMA vorbereiten

Vor der Eskalation bereithalten:

• genaue Fehlerbeschreibung, Beginn, Häufigkeit und Auswirkungen;
• Modell, Revision, Seriennummer, SFOS-Version und Build;
• HA-Status und betroffener Node;
• Disk-usage-Verlauf, relevante Fehlermeldungen und CTR;
• aktuelles heruntergeladenes Konfigurationsbackup;
• Backup-Verschlüsselungspasswort und zugehörigen Secure Storage Master Key sicher verfügbar halten, aber nur über den von Sophos vorgesehenen sicheren Weg teilen;
• Lizenz- und Supportstatus.

Ein SMART-Wert löst nicht automatisch eine RMA aus. Gemäss Sophos umfasst der RMA-Prozess zuerst Fehleridentifikation und Gerätedaten, danach Support Case und Validierung; Sophos kann weitere Diagnosen verlangen. Modell, Revision, Firmware-Version, Seriennummer und HA-Zugehörigkeit gehören zum RMA-Formular.

Bei HA ist zusätzlich zu klären, welcher Node ersetzt wird. Der hier beschriebene Wiederaufbau gilt nur für Active-Passive, nicht für Active-Active, und verursacht Ausfallzeit. Vorab Modell, Revision, initiales Primary sowie Firmwareversion und Build beider Geräte mit system diagnostics show version-info erfassen.

• Ersatzgerät vorbereiten: Wenn der identische Firmware-Build nicht verfügbar ist, ihn beim Sophos Support anfordern. Einen DHCP-Client an Port 1 anschliessen und https://172.16.16.16:4444 öffnen. Port 2 über den Setup Assistant nur für WAN und Internetzugang konfigurieren; zunächst keine weiteren Interfaces anlegen. Nach Reimage oder Update den Build nochmals mit system diagnostics show version-info verifizieren.
• Auxiliary ersetzen: Das gesunde Primary läuft vorübergehend allein. Das Ersatzgerät auf denselben Firmwarestand und Build bringen, in Central claimen und die Lizenz des defekten Auxiliary übertragen. Auf dem gesunden Primary HA deaktivieren, mit service -S | grep msync den Zustand UNTOUCHED oder STOPPED bestätigen, Verkabelung umstecken und Active-Passive-HA mit dem gesunden Gerät als Primary neu aufbauen.
• Primary ersetzen: Das gesunde Auxiliary aus Central deregistrieren und unter My Products > Firewall Management > Firewalls bestätigen, dass es nicht mehr aufgeführt wird. Sein aktuelles Backup sichern. Das Ersatzgerät auf denselben Firmwarestand und Build bringen, claimen, Lizenz übertragen, das Backup wiederherstellen und nach dem Kabelwechsel standalone den Verkehr übernehmen lassen. Danach das gesunde frühere Auxiliary auf Werkseinstellungen setzen, erneut claimen und Active-Passive-HA mit dem Ersatzgerät als Primary neu konfigurieren.

Der Austausch stellt Hardware bereit, aber keine garantierte Betriebsbereitschaft. Lizenztransfer, Backup-Kompatibilität, Central-Zuordnung, Verkabelung und Funktionstest vor dem Wartungsfenster dokumentieren. Grundlagen zu Rollen stehen unter Sophos Firewall HA-Cluster: Active-Passive, Active-Active und Auxiliary Appliance.

Die Garantie- und Supportgrundlagen fasst Wie lange bekomme ich Garantie auf Sophos Hardware? zusammen. Falls Sophos ein Reimage verlangt, folgt man dem separaten Ablauf Sophos Firewall OS neu installieren: Reimage mit USB-Stick.

Abschlusskontrolle

• Disk usage und Zeitraum geprüft, ohne Kapazität als SSD-Gesundheit zu interpretieren.
• Symptome, Zeitverlauf, Modell, Seriennummer, SFOS-Version und HA-Node dokumentiert.
• Aktuelles Backup ausserhalb der Appliance gespeichert und Wiederherstellungsgeheimnisse verfügbar.
• CTR mit System snapshot und All log files erzeugt und sicher gespeichert.
• Keine erratenen Gerätepfade sowie keine SMART-Selbsttests, fsck-, Lösch- oder Reparaturbefehle ohne Freigabe ausgeführt.
• Bei Hardwareverdacht Support Case eröffnet; zusätzliche Diagnose nur nach konkreter Supportanweisung.
• RMA oder Hardwaretausch erst nach Validierung durch Sophos geplant.

FAQ