Check Sophos Firewall storage and manage reports

If a Sophos Firewall warns of low storage space, files should not be deleted and reports should not be turned off immediately. First it must be clear which partition is affected, whether local reports, logs, mail queues, quarantine, support files or a virtual hard drive that is too small are the cause.

The article explains how to check the storage status on the Sophos Firewall, manage local reports in a controlled manner and only disable on-box reporting when the implications are understood. For long-term log retention, Central Firewall Reporting is often a better addition because you don’t just depend on local report data on the appliance.

⚠️ Important: Deleting reports or deactivating on-box reports can irretrievably remove local reports and log data. Before taking such steps, it should be checked whether the required data is exported, stored centrally or is no longer required for support and audit purposes.

When storage space becomes critical

Storage problems don’t always show up straight away. Typical notices are:

• Warning email or Control Center notice about high memory consumption.
• Reports load slowly, remain empty or do not show current data.
• Local log files are growing rapidly.
• Report or database services produce errors.
• Firmware upgrade or hotfix installation reports insufficient free memory.
• Virtual Firewall was deployed with a disk that was too small.
• Mail protection, quarantine or high web/application traffic generate a lot of local data.

If I/O errors, unusual restarts or database problems also occur at the same time, not only storage space should be freed up. Then you can also check the SSD health via SMART and the relevant Services and Logs.

Reports have an important threshold: by default, the firewall warns when the relevant partition reaches 70 percent usage. From 80 percent, report generation stops. If reporting stops for this reason, it is not enough to get just below 80 percent; usage must fall below the warning threshold again so that reports are generated reliably.

For very small appliances, also check whether local reports are supported at all. Sophos lists XGS 87/87w and XGS 88/88w as models without On-Appliance Reporting. In such environments, central retention through Sophos Central or Syslog is not just convenience, but part of the design.

What uses storage on the firewall

Many local operating data items are stored under /var. The firewall stores reports, event logs, troubleshooting logs and data from other components there, among other things. The individual areas have their own quotas depending on appliance model and function. A small branch firewall therefore does not behave like a large appliance with more local capacity.

The distinction is important:

• Reports: Reports are no longer stored cleanly or need to be shortened or deleted. The risk is a shorter local history and missing evaluations.
• Event Logs: Older logs are removed and new events can continue to be written. Historical analysis becomes shorter as a result.
• Troubleshooting Logs: Older compressed log files are removed. This can remove an important time window for support analysis.
• Email quarantine: Older quarantine messages can be removed. Traceability and release processes suffer.
• Temporary files or manually copied files: Such files can block storage unnecessarily. The cause remains hidden if only reports are deleted.

The disk-usage graph in WebAdmin helps with the first classification. It shows signatures, configuration data, reports and temporary storage separately. This does not replace detailed analysis, but it does show whether reports, temporary data or other areas are more conspicuous.

The most important trap is mixing up reports and logs. Report retention under Reports > Show Reports settings > Data management affects reports. Event logs for Log Viewer, Sophos Central and Syslog are controlled under System services > Log settings. If you only shorten report retention, local event logs do not automatically become smaller.

After upgrades, another point matters: since SFOS 21.0, the firewall can handle reports before and after an upgrade in separate report databases. When evaluating an upgrade day, a selection between data before and after the migration may therefore appear. If you roll back to an older firmware after an upgrade, reports generated since the upgrade can be lost. Relevant local reports should therefore be exported or available centrally before firmware work.

Check storage space in the Device Console

For a quick overview, you can check the used storage in the Device Console. The command shows the relevant memory areas of the Sophos Firewall:

system diagnostics show disk

The Device Console is intended for Sophos-specific commands. If access via SSH needs to be prepared, Sophos Firewall connect via SSH helps. It also describes why SSH should only be allowed from trustworthy admin networks.

Check storage space in the Advanced Shell

In the Advanced Shell you can take a closer look at the file systems. This command shows size, used memory, free memory and percentage usage:

df -hkm

If it is unclear whether the full output is too wide, you can specifically look at /var because there is a lot of local operating data there:

df -h /var

The command is pure reading. Files in system directories should not be manually deleted just because a partition looks full. First, the cause should be narrowed down.

If /var is conspicuous, first check the intended Sophos areas instead of deleting directories indiscriminately. Reports, Event Logs and Troubleshooting Logs are particularly relevant for a rough classification. Also check whether Packet Capture, debug logging, support files or manually copied files are consuming storage.

For the three typical storage blocks, Sophos names these read commands in the Advanced Shell:

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

These commands are intended for classification. They do not replace supported cleanup through WebAdmin, Device Console or the intended diagnostic functions.

Limit the cause

A full disk can have several causes. The right next step depends on what data is growing.

• Reports take up a lot of storage: Check retention under Reports > Show Reports settings > Data management, export reports or use Central Reporting.
• Local logs are growing strongly: Check log settings, debug logging and affected services.
• Troubleshooting Logs are growing strongly: Check debug logging, active support analysis or recurring service errors.
• /var is noticeably full: Check reports, logs, database, support files or mail queue.
• Disk graph shows a lot of temporary storage: Check running captures, support files or temporary processes.
• Email quarantine or mail spool is growing: Check Email > Quarantine settings and Email > Mail spool. Stuck messages should be checked, redelivered in a controlled way or deleted.
• Virtual firewall is too small: Check disk size and platform specifications in the hypervisor.
• Storage warning before firmware upgrade: Do not start the upgrade blindly; first carry out the SFOS 22 Upgrade Check.
• HA cluster affected: Check both nodes separately because local logs and reports do not have to be identical.

If there are active faults, logs should first be saved while the error is fresh. The article Sophos Firewall Backing up logs for support and analysis describes how to export the local log data.

If event logs are consuming local storage, report retention is not the right lever. In that case, check under System services > Log settings which modules are stored locally, sent to Sophos Central or forwarded to Syslog. Log suppression can help reduce unnecessary repetition. However, security-relevant events required later for incident response, support or compliance must not disappear.

Do not delete manually in the file system

Even if the Advanced Shell shows free memory and directories, files should not be deleted directly in /var, /log or database directories. Manual deletion actions can damage reports, services, databases or support analytics and make subsequent root cause analysis more difficult.

Better process:

• Document storage status and affected partition.
• Save relevant logs or CTR if a support case is likely.
• Check whether Packet Capture or debug logging is still active.
• Check report retention via WebAdmin.
• Only empty reports via the intended console point if it is clear that local data can be omitted.
• If consumption continues to grow, check the cause: debug logging, mail queue, quarantine, database, virtual disk or unusually high local traffic.

If it is unclear which data is occupying the storage, rm should not be used. It is safer to back up logs and involve support or Avanet with the current findings.

There are separate Device Console commands for purging troubleshooting logs. They are not a substitute for root-cause analysis and should only be used once required logs have been saved. Roughly speaking, system diagnostics purge-old-logs removes older compressed logs, while system diagnostics purge-all-logs removes all troubleshooting logs. Specific variants exist for individual subsystems. When in doubt, a targeted export under Diagnostics > Tools is cleaner than a blanket purge.

Adjust report retention in WebAdmin

If local reports are the cause, the retention period should be checked first. In many environments, on-box reports have historically been carried out, although the actual evaluation is now carried out centrally.

The Sophos path for local report retention is:

Reports > Show Reports settings > Data management

There you can adjust the retention period per report module and save it with Apply. The change affects reports, not event logs. Sophos also points out that changes to report retention only take effect at 00:00.

Useful questions before making a change:

• Are local reports really still being evaluated?
• Is there already central reporting, syslog or a SIEM?
• How long must log and report data be stored internally?
• Are there any compliance or support requirements?
• Is shorter local retention sufficient when central storage is active?

If logs and reports are required in Sophos Central, it is also worth checking which log types are sent to Central under System services > Log settings. Activation is described in Activate Central Firewall Reporting.

Delete reports in a controlled manner

If services no longer work properly due to full memory, manual cleaning of reports may become necessary. But this should be a controlled recovery measure, not the normal operating process.

Check beforehand:

• current configuration backup available
• required reports exported or centrally available
• affected periods documented
• Reason for the storage growth understood
• Maintenance window or support case prepared if the firewall is already unstable

The first path should be WebAdmin:

Reports > Show Reports settings > Manual purge

This lets you delete reports by module and period in a targeted way. This process can be slow because the firewall deliberately purges reports in a controlled way to conserve system resources.

If that is not enough or the firewall is already in a recovery state, there is the console item:

5. Device Management > 4. Flush Device Reports

After deleting, daily operations should not simply resume. It is important to check whether the free memory really increases and whether reports, Log Viewer, central reporting and the affected services then work plausibly again.

Flush Device Reports deletes the reports stored on the firewall and restarts the firewall. During this time, it is not reachable over the network for approximately ten minutes. This step therefore belongs in a maintenance window or a documented recovery process.

If services are already affected because the firewall is full, it should be clear before deletion which data will be missing afterwards. Local reports are often useful for change reviews, user analysis, security traceability or support questions. Anyone deleting them needs a short note with period, reason and available replacement source, for example Central Reporting or Syslog.

Check or deactivate On-Box Reports

On-Box Reports save reports locally on the firewall. This is practical, but can use up memory for small appliances, high traffic or long storage.

You can check the status in the Device Console:

show on-box-reports

This command does not answer the same question as system diagnostics show disk: show on-box-reports shows whether local reports are generally enabled, while system diagnostics show disk shows the current storage usage of the individual areas. A clean diagnosis usually needs both views.

If local reports are not needed and another storage is available, you can deactivate on-box reports:

set on-box-reports off

This should just be made aware. Reports are important for analysis, support and operations. In many productive environments it is better to reduce local storage and use central reporting, syslog or a SIEM in parallel. If longer central retention is required, Sophos Central Firewall Reporting Advanced is a possible option.

Important: On-Box Reports can only be switched on or off as a whole, not selectively per module. If only individual report areas use a lot of storage, shorter retention or targeted purging is usually better than switching off On-Box Reporting completely.

If On-Box Reports are disabled, do not only check storage afterwards. Internal processes also change: local report views, scheduled reports, security evaluations and quick ad-hoc analyses on the firewall may disappear or become less useful. This step therefore belongs in an operational decision, not in a spontaneous storage cleanup.

Classify warning thresholds and alerts

Sophos Firewall can generate Control Center alerts and event logs when /var usage is high. The warning threshold can be controlled in the Device Console with set var-partition-usage watermark. However, this is not a storage fix. A lower or higher warning threshold only changes when a warning appears, not why storage is being consumed.

The allowed range is 50 to 75 percent, with 70 percent as the default. Reporting stops at 80 percent, and that stop is not the actual operating boundary but already an error state. A higher warning threshold therefore does not make the firewall more stable; it only reduces reaction time.

For operations, it is usually more useful to:

• Enable email or SNMP notifications for storage warnings.
• Check storage warnings before the next maintenance window.
• Adjust retention, debug logging and local report usage when warnings recur.
• Deliberately check free storage before firmware upgrades.

If usage increases significantly or reports already stop, first free up storage and clarify the cause. A changed warning threshold must not be used to hide a real capacity problem.

Pay attention to virtual firewalls

With virtual Sophos Firewalls the cause is not always in reports or logs. Sometimes the virtual appliance was deployed with too little disk or grew over several years without re-evaluating the platform requirements.

In virtual environments, also check:

• Size of the virtual disk.
• Free space on the datastore.
• Snapshots, backup jobs and storage latency.
• Monitoring the hypervisor.
• Whether the firewall version specifies additional memory requirements.
• Whether the virtual disk may be expanded online or whether reimage with restore is the cleaner path.

If the disk is fundamentally too small, deleting reports is only a short-term relief. The virtual platform should then be properly adapted and secured with a backup, maintenance window and restore plan.

This point is especially important before SFOS 22: if the firewall shows a storage warning or upgrade blocker for the virtual disk, first work through the SFOS 22 Upgrade Check. The official Sophos notes on the virtual disk are linked there. Expansion belongs in a planned maintenance window with backup, checked hypervisor storage and subsequent validation of the partitions.

For hardware appliances, by contrast, disk expansion is not the normal path. Check storage consumption, reports, logs, quarantine and SSD health, and prepare a support or RMA process if hardware is suspected.

Checklist

Check immediately

• Warning message, time and affected firewall documented.
• system diagnostics show disk executed in the Device Console.
• df -hkm checked in the Advanced Shell.
• Noticed unusual partition.
• Disk-usage graph in WebAdmin checked for rough classification.
• Reports, logs, mail queue, quarantine and virtual disk evaluated as possible causes.
• Packet Capture and debug logging checked as short-term storage sources.

Before deleting or deactivating

• Required reports and logs backed up.
• Central reporting, syslog or other central storage checked.
• Backup and recovery path available.
• Maintenance window defined when productive services are affected.
• At HA both nodes checked separately.
• Period and reason for report cleanup documented.

After cleaning

• Free memory checked again.
• Reports and Log Viewer tested.
• Central Reporting or Syslog checked for current data.
• Cause of memory growth documented.
• Retention period, log settings and review process adjusted.
• Notifications for future storage warnings checked.

FAQ