Sophos Firewall Speicherplatz prüfen und Reports verwalten

Wenn eine Sophos Firewall vor knappem Speicherplatz warnt, sollte man nicht sofort Dateien löschen oder Reports abschalten. Zuerst muss klar sein, welche Partition betroffen ist, ob lokale Reports, Logs, Mailqueue, Quarantäne, Supportdateien oder eine zu kleine virtuelle Festplatte die Ursache sind.

Der Artikel erklärt, wie man den Speicherstatus auf der Sophos Firewall prüft, lokale Reports kontrolliert verwaltet und On-Box Reporting nur dann deaktiviert, wenn die Auswirkungen verstanden sind. Für langfristige Logaufbewahrung ist Central Firewall Reporting oft die bessere Ergänzung, weil man nicht nur von lokalen Reportdaten auf der Appliance abhängig ist.

⚠️ Wichtig: Das Löschen von Reports oder das Deaktivieren von On-Box Reports kann lokale Berichte und Logdaten unwiederbringlich entfernen. Vor solchen Schritten sollte geprüft werden, ob die benötigten Daten exportiert, zentral gespeichert oder für Support- und Audit-Zwecke nicht mehr erforderlich sind.

Wann Speicherplatz kritisch wird

Speicherprobleme zeigen sich nicht immer gleich. Typische Hinweise sind:

• Warn-E-Mail oder Control-Center-Hinweis zu hohem Speicherverbrauch.
• Reports laden langsam, bleiben leer oder zeigen keine aktuellen Daten.
• Lokale Logdateien wachsen stark an.
• Report- oder Datenbankdienste erzeugen Fehler.
• Firmware-Upgrade oder Hotfix-Installation meldet zu wenig freien Speicher.
• Virtuelle Firewall wurde mit zu kleiner Disk bereitgestellt.
• Mail Protection, Quarantäne oder hoher Web-/Application-Traffic erzeugen viele lokale Daten.

Wenn parallel auch I/O-Fehler, ungewöhnliche Neustarts oder Datenbankprobleme auftreten, sollte nicht nur Speicherplatz freigegeben werden. Dann passt zusätzlich die Prüfung der SSD-Gesundheit per SMART und der relevanten Services und Logs.

Bei Reports gibt es eine wichtige Schwelle: Standardmässig warnt die Firewall bei 70 Prozent Nutzung der relevanten Partition. Ab 80 Prozent stoppt die Report-Erzeugung. Wenn Reporting deshalb stoppt, reicht es nicht, knapp unter 80 Prozent zu kommen; die Nutzung muss wieder unter die Warnschwelle sinken, damit Reports wieder zuverlässig erzeugt werden.

Bei sehr kleinen Appliances muss man zusätzlich prüfen, ob lokale Reports überhaupt unterstützt werden. Sophos nennt XGS 87/87w und XGS 88/88w als Modelle ohne On-Appliance-Reporting. In solchen Umgebungen ist zentrale Aufbewahrung über Sophos Central oder Syslog nicht nur Komfort, sondern Teil des Designs.

Was auf der Firewall Speicher belegt

Viele lokale Betriebsdaten liegen im Bereich /var. Dort speichert die Firewall unter anderem Reports, Event Logs, Troubleshooting Logs und Daten weiterer Komponenten. Die einzelnen Bereiche haben je nach Appliance-Modell und Funktion eigene Kontingente. Eine kleine Branch-Firewall verhält sich deshalb nicht wie eine grosse Appliance mit mehr lokaler Kapazität.

Wichtig ist die Unterscheidung:

• Reports: Reports werden nicht mehr sauber gespeichert oder müssen gekürzt beziehungsweise gelöscht werden. Das Risiko ist ein kürzerer lokaler Verlauf und fehlende Auswertungen.
• Event Logs: Ältere Logs werden entfernt, neue Events können weiter geschrieben werden. Die historische Analyse wird dadurch kürzer.
• Troubleshooting Logs: Ältere komprimierte Logdateien werden entfernt. Für Supportanalysen kann dadurch ein wichtiges Zeitfenster fehlen.
• E-Mail-Quarantäne: Ältere Quarantäne-Mails können entfernt werden. Nachvollziehbarkeit und Freigabeprozesse leiden.
• Temporäre Dateien oder manuell kopierte Dateien: Solche Dateien können Speicher unnötig blockieren. Die Ursache bleibt verborgen, wenn nur Reports gelöscht werden.

Der Disk-Usage-Graph im WebAdmin hilft bei der ersten Einordnung. Dort werden Signaturen, Konfigurationsdaten, Reports und temporärer Speicher getrennt dargestellt. Das ersetzt keine Detailanalyse, zeigt aber, ob eher Reports, temporäre Daten oder andere Bereiche auffällig sind.

Die wichtigste Denkfalle ist die Vermischung von Reports und Logs. Report-Aufbewahrung unter Reports > Show Reports settings > Data management betrifft Reports. Event Logs für Log Viewer, Sophos Central und Syslog werden dagegen unter System services > Log settings gesteuert. Wenn man nur die Report-Aufbewahrung kürzt, sind lokale Event Logs dadurch nicht automatisch kleiner.

Nach Upgrades ist ein weiterer Punkt wichtig: Seit SFOS 21.0 kann die Firewall Reports vor und nach einem Upgrade in getrennten Reportdatenbanken behandeln. Beim Auswerten eines Upgrade-Tages kann deshalb eine Auswahl zwischen Daten vor und nach der Migration erscheinen. Wenn man nach einem Upgrade auf eine ältere Firmware zurückrollt, können Reports verloren gehen, die seit dem Upgrade erzeugt wurden. Vor Firmwarearbeiten sollten relevante lokale Reports deshalb exportiert oder zentral verfügbar sein.

Speicherplatz in der Device Console prüfen

Für eine schnelle Übersicht kann man den belegten Speicher in der Device Console prüfen. Der Befehl zeigt die relevanten Speicherbereiche der Sophos Firewall:

system diagnostics show disk

Die Device Console ist für Sophos-spezifische Befehle gedacht. Wenn der Zugriff per SSH vorbereitet werden muss, hilft Sophos Firewall per SSH verbinden. Dort ist auch beschrieben, warum SSH nur aus vertrauenswürdigen Admin-Netzen erlaubt werden sollte.

Speicherplatz in der Advanced Shell prüfen

In der Advanced Shell kann man die Dateisysteme genauer ansehen. Dieser Befehl zeigt Grösse, belegten Speicher, freien Speicher und prozentuale Nutzung:

df -hkm

Wenn unklar ist, ob die volle Ausgabe zu breit ist, kann man gezielt auf /var schauen, weil dort viele lokale Betriebsdaten liegen:

df -h /var

Der Befehl ist rein lesend. Es sollten keine Dateien in Systemverzeichnissen manuell gelöscht werden, nur weil eine Partition voll aussieht. Zuerst sollte die Ursache eingegrenzt werden.

Wenn /var auffällig ist, sollte man zuerst die vorgesehenen Sophos-Bereiche prüfen statt wahllos Verzeichnisse zu löschen. Für eine grobe Einordnung sind besonders Reports, Event Logs und Troubleshooting Logs relevant. Zusätzlich sollte man prüfen, ob Packet Capture, Debug-Logging, Supportdateien oder manuell kopierte Dateien Speicher belegen.

Für die drei typischen Speicherblöcke nennt Sophos diese Lesebefehle in der Advanced Shell:

du -kh reportdb_16
du -kh eventlogs
du -kh tslog

Diese Befehle sind zur Einordnung gedacht. Eine supported Bereinigung über WebAdmin, Device Console oder die vorgesehenen Diagnosefunktionen ersetzen sie nicht.

Ursache eingrenzen

Eine volle Disk kann mehrere Ursachen haben. Der richtige nächste Schritt hängt davon ab, welche Daten wachsen.

• Reports belegen viel Speicher: Aufbewahrungsdauer unter Reports > Show Reports settings > Data management prüfen, Reports exportieren oder Central Reporting nutzen.
• Lokale Logs wachsen stark: Log settings, Debug-Logging und betroffene Services prüfen.
• Troubleshooting Logs wachsen stark: Debug-Logging, aktive Supportanalyse oder wiederkehrende Dienstfehler prüfen.
• /var ist auffällig voll: Reports, Logs, Datenbank, Supportdateien oder Mailqueue prüfen.
• Disk-Graph zeigt viel temporären Speicher: laufende Captures, Supportdateien oder temporäre Prozesse prüfen.
• E-Mail-Quarantäne oder Mail Spool wächst: Email > Quarantine settings und Email > Mail spool prüfen. Hängende Nachrichten sollten kontrolliert erneut zugestellt oder gelöscht werden.
• Virtuelle Firewall ist zu knapp dimensioniert: Disk-Grösse und Plattformvorgaben im Hypervisor prüfen.
• Vor Firmware-Upgrade wird Speicher gewarnt: Upgrade nicht blind starten, zuerst SFOS 22 Upgrade Check durchführen.
• HA-Cluster betroffen: Beide Nodes separat prüfen, weil lokale Logs und Reports nicht identisch sein müssen.

Bei aktiven Störungen sollte man zuerst Logs sichern, solange der Fehler frisch ist. Der Artikel Sophos Firewall Logs für Support und Analyse sichern beschreibt den Export der lokalen Logdaten.

Wenn Event Logs den lokalen Speicher belasten, ist die Report-Retention nicht der richtige Hebel. Dann prüft man unter System services > Log settings, welche Module lokal gespeichert, an Sophos Central gesendet oder an Syslog weitergeleitet werden. Log Suppression kann helfen, unnötige Wiederholungen zu reduzieren. Dabei dürfen aber keine sicherheitsrelevanten Events verschwinden, die später für Incident Response, Support oder Compliance gebraucht werden.

Nicht manuell im Dateisystem löschen

Auch wenn die Advanced Shell freien Speicher und Verzeichnisse zeigt, sollte man nicht direkt in /var, /log oder Datenbankverzeichnissen Dateien entfernen. Manuelle Löschaktionen können Reports, Dienste, Datenbanken oder Supportanalysen beschädigen und machen die spätere Ursachenanalyse schwieriger.

Besserer Ablauf:

• Speicherstatus und betroffene Partition dokumentieren.
• Relevante Logs oder CTR sichern, wenn ein Supportfall wahrscheinlich ist.
• Prüfen, ob Packet Capture oder Debug-Logging noch aktiv ist.
• Report-Aufbewahrung über WebAdmin prüfen.
• Reports nur über den vorgesehenen Konsolenpunkt leeren, wenn klar ist, dass lokale Daten entfallen dürfen.
• Bei weiter wachsendem Verbrauch Ursache prüfen: Debug-Logging, Mailqueue, Quarantäne, Datenbank, virtuelle Disk oder ungewöhnlich viel lokaler Traffic.

Wenn unklar ist, welche Daten den Speicher belegen, sollte man nicht mit rm arbeiten. Dann ist es sicherer, Logs zu sichern und Support oder Avanet mit dem aktuellen Befund einzubeziehen.

Für Troubleshooting Logs gibt es separate Device-Console-Befehle zum Purgen. Diese sind kein Ersatz für Ursachenanalyse und sollten erst verwendet werden, wenn benötigte Logs gesichert sind. Grob gilt: system diagnostics purge-old-logs entfernt komprimierte ältere Logs, system diagnostics purge-all-logs entfernt alle Troubleshooting Logs. Für einzelne Subsysteme gibt es spezifische Varianten. Im Zweifel ist ein gezielter Export unter Diagnostics > Tools sauberer als ein pauschaler Purge.

Report-Aufbewahrung im WebAdmin anpassen

Wenn lokale Reports die Ursache sind, sollte zuerst die Aufbewahrungsdauer geprüft werden. In vielen Umgebungen werden On-Box Reports historisch mitgeführt, obwohl die eigentliche Auswertung inzwischen zentral erfolgt.

Der Sophos-Pfad für die lokale Report-Aufbewahrung lautet:

Reports > Show Reports settings > Data management

Dort kann man die Aufbewahrungsdauer pro Reportmodul anpassen und mit Apply speichern. Die Änderung wirkt auf Reports, nicht auf Event Logs. Sophos weist ausserdem darauf hin, dass Änderungen an der Report-Aufbewahrung erst um 00:00 Uhr wirksam werden.

Sinnvolle Fragen vor einer Änderung:

• Werden lokale Reports wirklich noch ausgewertet?
• Gibt es bereits Central Reporting, Syslog oder ein SIEM?
• Wie lange müssen Log- und Reportdaten intern aufbewahrt werden?
• Gibt es Compliance- oder Supportanforderungen?
• Reicht eine kürzere lokale Aufbewahrung, wenn zentrale Speicherung aktiv ist?

Wenn Logs und Reports in Sophos Central benötigt werden, sollte zusätzlich geprüft werden, welche Logtypen unter System services > Log settings an Central gesendet werden. Die Aktivierung ist in Central Firewall Reporting aktivieren beschrieben.

Reports kontrolliert löschen

Wenn Dienste wegen vollem Speicher nicht mehr sauber arbeiten, kann das manuelle Bereinigen von Reports notwendig werden. Das sollte aber eine kontrollierte Recovery-Massnahme sein, nicht der normale Betriebsprozess.

Vorher prüfen:

• aktuelles Konfigurationsbackup vorhanden
• benötigte Reports exportiert oder zentral verfügbar
• betroffene Zeiträume dokumentiert
• Grund für das Speicherwachstum verstanden
• Wartungsfenster oder Supportfall vorbereitet, wenn die Firewall bereits instabil ist

Der erste Weg sollte der WebAdmin sein:

Reports > Show Reports settings > Manual purge

Damit kann man Reports gezielt nach Modul und Zeitraum löschen. Dieser Vorgang kann langsam sein, weil die Firewall Reports bewusst kontrolliert purgt, um Systemressourcen zu schonen.

Wenn das nicht ausreicht oder die Firewall bereits in einem Recovery-Zustand ist, gibt es den Konsolenpunkt:

5. Device Management > 4. Flush Device Reports

Nach dem Löschen sollte man nicht einfach zum Tagesbetrieb zurückkehren. Wichtig ist die Kontrolle, ob der freie Speicher wirklich steigt und ob Reports, Log Viewer, Central Reporting und betroffene Dienste danach wieder plausibel arbeiten.

Flush Device Reports löscht die auf der Firewall gespeicherten Reports und startet die Firewall neu. Währenddessen ist sie über das Netzwerk für ungefähr zehn Minuten nicht erreichbar. Deshalb gehört dieser Schritt in ein Wartungsfenster oder in einen dokumentierten Recovery-Ablauf.

Wenn die Firewall wegen vollem Speicher bereits Dienste beeinträchtigt, sollte vor dem Löschen klar sein, welche Daten danach fehlen. Lokale Reports sind oft für Change Reviews, Benutzeranalyse, Security-Nachvollziehbarkeit oder Supportfragen nützlich. Wer sie löscht, braucht einen kurzen Vermerk mit Zeitraum, Grund und vorhandener Ersatzquelle, zum Beispiel Central Reporting oder Syslog.

On-Box Reports prüfen oder deaktivieren

On-Box Reports speichern Berichte lokal auf der Firewall. Das ist praktisch, kann bei kleinen Appliances, viel Traffic oder langer Aufbewahrung aber Speicher verbrauchen.

Den Status prüft man in der Device Console:

show on-box-reports

Dieser Befehl beantwortet nicht dieselbe Frage wie system diagnostics show disk: show on-box-reports zeigt, ob lokale Reports grundsätzlich aktiv sind, während system diagnostics show disk den aktuellen Speicherverbrauch der Bereiche zeigt. Für eine saubere Diagnose braucht man meistens beide Sichtweisen.

Wenn lokale Reports nicht benötigt werden und eine andere Aufbewahrung vorhanden ist, kann man On-Box Reports deaktivieren:

set on-box-reports off

Das sollte nur bewusst gemacht werden. Reports sind für Analyse, Support und Betrieb wichtig. In vielen produktiven Umgebungen ist es besser, lokale Aufbewahrung zu reduzieren und parallel Central Reporting, Syslog oder ein SIEM zu nutzen. Wenn längere zentrale Aufbewahrung benötigt wird, ist Sophos Central Firewall Reporting Advanced eine mögliche Option.

Wichtig: On-Box Reports lassen sich nur insgesamt ein- oder ausschalten, nicht selektiv pro Modul. Wenn nur einzelne Reportbereiche viel Speicher brauchen, ist eine kürzere Aufbewahrung oder gezieltes Purging meist besser als On-Box Reporting komplett abzuschalten.

Wenn On-Box Reports deaktiviert werden, sollte danach nicht nur der Speicher geprüft werden. Auch interne Abläufe ändern sich: lokale Reportansichten, geplante Reports, Security-Auswertungen und schnelle Ad-hoc-Analysen auf der Firewall können wegfallen oder weniger nützlich werden. Deshalb gehört dieser Schritt in eine Betriebsentscheidung, nicht in eine spontane Speicherbereinigung.

Warnschwellen und Alerts einordnen

Die Sophos Firewall kann bei hoher /var-Nutzung Control-Center-Alerts und Event-Logs erzeugen. Die Warnschwelle lässt sich über die Device Console mit set var-partition-usage watermark steuern. Das ist aber kein Speicher-Fix. Eine tiefere oder höhere Warnschwelle ändert nur, wann eine Warnung erscheint, nicht warum Speicher verbraucht wird.

Der erlaubte Bereich liegt bei 50 bis 75 Prozent, Standard ist 70 Prozent. Reporting stoppt bei 80 Prozent und dieser Stopp ist nicht die eigentliche Betriebsgrenze, sondern bereits ein Fehlerzustand. Eine höhere Warnschwelle macht die Firewall also nicht stabiler, sondern reduziert nur die Reaktionszeit.

Für den Betrieb ist meist sinnvoller:

• E-Mail- oder SNMP-Benachrichtigungen für Speicherwarnungen aktivieren.
• Speicherwarnungen nicht erst im nächsten Wartungsfenster prüfen.
• Bei wiederkehrenden Warnungen Aufbewahrung, Debug-Logging und lokale Reportnutzung anpassen.
• Vor Firmware-Upgrades freien Speicher bewusst prüfen.

Wenn die Nutzung deutlich steigt oder Reports bereits stoppen, sollte zuerst Speicher freigegeben und die Ursache geklärt werden. Eine geänderte Warnschwelle darf nicht dazu dienen, ein echtes Kapazitätsproblem zu verdecken.

Virtuelle Firewalls beachten

Bei virtuellen Sophos Firewalls liegt die Ursache nicht immer in Reports oder Logs. Manchmal wurde die virtuelle Appliance mit zu wenig Disk bereitgestellt oder über mehrere Jahre gewachsen, ohne die Plattformanforderungen neu zu prüfen.

In virtuellen Umgebungen sollte man zusätzlich prüfen:

• Grösse der virtuellen Disk.
• Freier Speicher auf dem Datastore.
• Snapshots, Backup-Jobs und Storage-Latenz.
• Monitoring des Hypervisors.
• Ob die Firewall-Version zusätzliche Speicheranforderungen nennt.
• Ob die virtuelle Disk online erweitert werden darf oder ein Reimage mit Restore der sauberere Weg ist.

Wenn die Disk grundsätzlich zu klein ist, ist das Löschen von Reports nur eine kurzfristige Entlastung. Dann sollte die virtuelle Plattform sauber angepasst und mit Backup, Wartungsfenster und Restore-Plan abgesichert werden.

Vor SFOS 22 ist dieser Punkt besonders wichtig: Wenn die Firewall eine Speicherwarnung oder einen Upgrade-Blocker zur virtuellen Disk zeigt, sollte zuerst der SFOS 22 Upgrade Check abgearbeitet werden. Dort sind die offiziellen Sophos-Hinweise zur virtuellen Disk verlinkt. Die Erweiterung gehört in ein geplantes Wartungsfenster mit Backup, geprüftem Hypervisor-Speicher und anschliessender Validierung der Partitionen.

Bei Hardware-Appliances ist dagegen nicht die Disk-Erweiterung der normale Weg. Dort sollte man Speicherverbrauch, Reports, Logs, Quarantäne und SSD-Zustand prüfen und bei Hardwareverdacht einen Support- oder RMA-Prozess vorbereiten.

Checkliste

Sofort prüfen

• Warnmeldung, Zeitpunkt und betroffene Firewall dokumentiert.
• system diagnostics show disk in der Device Console ausgeführt.
• df -hkm in der Advanced Shell geprüft.
• Auffällige Partition notiert.
• Disk-Usage-Graph im WebAdmin zur groben Einordnung geprüft.
• Reports, Logs, Mailqueue, Quarantäne und virtuelle Disk als mögliche Ursachen bewertet.
• Packet Capture und Debug-Logging als kurzfristige Speicherquellen geprüft.

Vor dem Löschen oder Deaktivieren

• Benötigte Reports und Logs gesichert.
• Central Reporting, Syslog oder andere zentrale Aufbewahrung geprüft.
• Backup und Recovery-Pfad vorhanden.
• Wartungsfenster definiert, wenn produktive Dienste betroffen sind.
• Bei HA beide Nodes separat geprüft.
• Zeitraum und Grund für eine Report-Bereinigung dokumentiert.

Nach der Bereinigung

• Freier Speicher erneut geprüft.
• Reports und Log Viewer getestet.
• Central Reporting oder Syslog auf aktuelle Daten geprüft.
• Ursache des Speicherwachstums dokumentiert.
• Aufbewahrungsdauer, Log settings und Review-Prozess angepasst.
• Benachrichtigungen für zukünftige Speicherwarnungen geprüft.

FAQ