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 Sophos Fusion 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.

Ist die Firewall bereits im Failsafe-Modus, werden nicht zuerst Reports oder Dateien gelöscht. Mit Sophos Firewall im Failsafe-Modus prüfen wird die von SFOS erkannte Ursache gesichert; erst danach folgt die gezielte Speicheranalyse.

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.

Die E-Mail- und SNMP-Benachrichtigung am höheren Schwellwert ist standardmässig ausgeschaltet. Unter System services > Notification list > Disk/Memory wird dafür Reports disk usage exceeded threshold für E-Mail, SNMP oder beide Ziele aktiviert. Das ersetzt nicht die Kontrolle der früheren Warnung: Control Center und Log Viewer melden bereits den unteren Schwellwert sowie die spätere Überschreitung.

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 Fusion (ehemals 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.

Bei Event Logs hängt das Kontingent vom Appliance-Modell ab. Als Beispiel nennt Sophos für grössere Modelle höchstens 15 Prozent der gesamten /var-Partition oder 50 Prozent des aktuell freien /var-Speichers, je nachdem, welcher Wert kleiner ist. Das ist keine feste Quote für jedes Modell und kein Versprechen für eine bestimmte Aufbewahrungsdauer.

Nur für Reports erzeugt SFOS bei knappem Komponenten-Speicher standardmässig einen Alert. Event Logs löschen ältere Einträge, Troubleshooting Logs ältere komprimierte Dateien und die E-Mail-Quarantäne ältere Nachrichten, ohne dafür einen eigenen Speicher-Alert zu erzeugen. Externe Aufbewahrung und Monitoring müssen deshalb geplant sein, bevor ein benötigtes Zeitfenster automatisch verschwindet.

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 Fusion 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 einem Herunterfahren oder Neustart kann SFOS noch unverarbeitete Reportdaten nachträglich verarbeiten und dabei dem Tag vor dem Neustart zuordnen, nicht dem tatsächlichen Ereigniszeitpunkt. Ein Treffer an diesem Datum beweist deshalb nicht allein, dass der Traffic wirklich dann stattgefunden hat. Bei einer Incident-Zeitlinie werden Report, Uptime, Event Logs und vorhandene externe Logs gemeinsam korreliert.

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 Sophos Fusion 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.

Die automatische Bereinigung des Quarantänebereichs bei 90 Prozent sowie Digest, Benutzerzuweisung und Release-Test erklärt Sophos Firewall Quarantäne-Digest einrichten und testen.

• 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 Fusion 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. Sie sind kein Ersatz für Ursachenanalyse und werden erst verwendet, wenn die benötigten Logs gesichert und das betroffene Subsystem eindeutig bestimmt sind:

system diagnostics purge-old-logs
system diagnostics purge-all-logs
system diagnostics subsystems <subsystem> purge-old-log
system diagnostics subsystems <subsystem> purge-log

Die ersten beiden Befehle wirken auf alle Troubleshooting Logs; purge-old-logs entfernt die komprimierten Rotationen, purge-all-logs auch die aktuellen Dateien. Die beiden Subsystemvarianten begrenzen dieselben Aktionen auf ein unterstütztes Subsystem. Vor dem Ausführen den gültigen Namen mit der CLI-Hilfe beziehungsweise Tab Completion prüfen. Ein Purge lässt sich nicht rückgängig machen; im Zweifel ist ein gezielter Export unter Diagnostics > Tools sauberer.

Schreibrechte der Report-Partition nur gezielt ändern

Die Device Console kann Schreibzugriffe auf die Report-Partition global erlauben oder sperren. Die SFOS-22-Syntax nennt nur report; partition-name ist ein Schlüsselwort und kein Platzhalter für einen frei gewählten Pfad. Vor einer Änderung wird der Zustand gelesen:

system filesystem enforce-disk-write partition-name report show

Standard ist enable. disable ist keine Speicherbereinigung und löscht keine Reports. Es verhindert Schreibzugriffe auf die Report-Partition und kann dadurch lokale Reportdaten, Auswertungen und davon abhängige Abläufe unvollständig machen. Die Einstellung wird deshalb nur als geplante Recovery- oder Supportmassnahme geändert, nicht als Tuning:

system filesystem enforce-disk-write partition-name report disable
system filesystem enforce-disk-write partition-name report show

Für den Rückweg werden Schreibzugriffe wieder erlaubt und der Zustand erneut geprüft:

system filesystem enforce-disk-write partition-name report enable
system filesystem enforce-disk-write partition-name report show

enable allein beweist noch nicht, dass Reportdatenbank und lokale Ansichten wieder fehlerfrei schreiben. Nach dem Rückweg folgen ein neuer Reportzeitraum, Generate now, lokale Dashboards, geplante Reports und der Speichertrend. Bleibt die Partition read-only oder treten I/O-Fehler auf, wird nicht wiederholt umgeschaltet, sondern SSD, virtuelle Report Disk, Mount-Zustand und Supportfall geprüft.

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 noch aus Gewohnheit vorgehalten, obwohl die 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 auf höchstens ein Jahr festlegen und mit Apply speichern. SFOS zählt die Monate rückwärts ab dem Vormonat; der laufende Monat ist also nicht der erste Aufbewahrungsmonat. Änderungen werden erst um 00:00 Uhr wirksam. Diese Einstellung betrifft Reports, nicht Event Logs.

Sinnvolle Fragen vor einer Änderung:

• Werden lokale Reports wirklich noch ausgewertet?
• Gibt es bereits Sophos Fusion 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 Fusion benötigt werden, sollte zusätzlich geprüft werden, welche Logtypen unter System services > Log settings an Sophos Fusion gesendet werden. Die Aktivierung ist in Sophos Fusion Firewall Reporting aktivieren beschrieben.

Reportexport anpassen und vollständig durchführen

Unter Reports > Show Reports settings > Data management steuert Export customization, welche Reports ein Export enthält und wie viele Datensätze pro Report exportiert werden. Vor dem Export werden nur die benötigten Reports ausgewählt und die Anzahl der Datensätze pro Report festgelegt. Diese Einstellung ist von der Aufbewahrung getrennt und löscht keine lokalen Daten.

Der Export wird vollständig in WebAdmin durchgeführt; über die CLI lassen sich Reports nicht herunterladen:

1. Reports öffnen und Applications & web wählen.
2. Unter Show die Reportkriterien und danach den Datumsbereich auswählen.
3. Generate wählen und das Ergebnis prüfen.
4. Das benötigte Dateiformat wählen, um die Reportdaten herunterzuladen.
5. Die heruntergeladene Datei öffnen und kontrollieren, ob die vorgesehenen Reports, der Zeitraum und die Anzahl der Datensätze enthalten sind, bevor sie als Backup- oder Auditnachweis verwendet wird.

Die konfigurierte Anzahl der Datensätze pro Report begrenzt den Download. Eine erfolgreich heruntergeladene Datei beweist deshalb nicht, dass alle lokalen Datensätze exportiert wurden; ihr Umfang muss mit der betrieblichen oder regulatorischen Anforderung verglichen werden.

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

Nach Auswahl von Reportmodul und Kriterium kann man einen eigenen Zeitraum angeben oder alle Daten des Moduls löschen. Mit Purge beginnt die Bereinigung sofort und lässt sich nicht rückgängig machen. Die Bereinigung ist bewusst langsam: SFOS verarbeitet fünf Datenbanktabellen pro Minute, um die 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, Sophos Fusion 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 Sophos Fusion 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

Der Rückweg wird vor dem Abschalten vorbereitet. Mit on startet die lokale Reporterzeugung wieder; eine Lücke aus dem deaktivierten Zeitraum wird nicht als nachträglich aufgefüllt vorausgesetzt:

set on-box-reports on
show on-box-reports

Danach werden ein neuer lokaler Report, Log Viewer, ein geplanter Report und der Speichertrend geprüft. Der Status on allein beweist noch nicht, dass Reporting-Datenbank und Reportansichten wieder plausibel arbeiten.

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 Sophos Fusion 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 PDF-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.

Vor einer Änderung wird der aktuelle Wert in der Device Console gelesen. Die vollständige SFOS-22-Syntax lautet:

show var-partition-usage watermark
set var-partition-usage watermark <50-75>
set var-partition-usage watermark default

default setzt die Warnschwelle auf 70 Prozent und stellt nicht automatisch einen früheren individuellen Wert wieder her. Für einen Rollback wird deshalb die zuvor mit show gesicherte Zahl explizit gesetzt. Der Schalter verändert weder die 80-Prozent-Grenze für den Reporting-Stopp noch löscht er Reports, Logs oder einen bereits bestehenden Kapazitätsengpass.

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.
• Sophos Fusion 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.
• Sophos Fusion 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