Check Sophos Firewall storage and manage reports

If a Sophos Firewall warns of low storage space, do not immediately delete files or turn off reporting. First identify the affected partition and determine whether the cause is local reports, logs, mail queues, quarantine, support files, or an undersized virtual disk.

This article explains how to check storage on the Sophos Firewall, manage local reports safely, and disable on-box reporting only after assessing the consequences. For long-term retention, Sophos Fusion Firewall Reporting is often a useful addition because it avoids relying solely on report data stored on the appliance.

⚠️ Important: Deleting reports permanently removes local report data. Disabling On-Box Reports turns off local report generation as a whole. These actions are separate from the storage and cleanup of Event Logs and Troubleshooting Logs. Before taking either step, confirm that the required data has been exported, is stored centrally, or is no longer needed 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 storage usage.
• 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 storage.
• 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.

If the firewall is already in Failsafe mode, do not delete Reports or files first. Check Sophos Firewall in Failsafe mode preserves the displayed state and available error messages before targeted storage analysis begins.

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.

Email and SNMP notification at the higher threshold is turned off by default. Under System services > Notification list > Disk/Memory, enable Reports disk usage exceeded threshold for email, SNMP, or both destinations. This does not replace monitoring the earlier warning: Control Center and Log Viewer already show the lower threshold and the later exceedance.

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 Fusion (formerly 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 saved correctly or must be retained for less time or deleted. The risk is a shorter local history and missing analysis data.
• 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.

Reports occupy the available space in /var. Troubleshooting logs (tslog), by contrast, have a separate allocation for each component based on the appliance model; critical components receive more space. New troubleshooting logs continue to be generated after older compressed files are removed. You select the email quarantine allocation under Email > Quarantine settings. New emails continue to be quarantined after older messages are removed there too. None of this guarantees a particular retention period.

The event-log quota depends on the appliance model. As an example for higher-end models, Sophos states a maximum of 15 percent of the entire /var partition or 50 percent of the currently free /var space, whichever is lower. This isn’t a fixed quota for every model or a promise of a specific retention period.

SFOS generates a default near-full component alert only for reports. Event logs remove older entries, troubleshooting logs remove older compressed files, and email quarantine removes older messages without their own storage alert. External retention and monitoring must therefore be planned before a required time window disappears automatically.

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 Fusion and Syslog are controlled under System services > Log settings. If you only shorten report retention, local event logs do not automatically become smaller.

After a shutdown or restart, SFOS can process report data that was still pending and assign it to the day before the restart rather than to the actual event time. An entry on that date therefore does not prove on its own that the traffic occurred then. For an incident timeline, correlate the report, uptime, event logs, and any available external logs.

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, check storage usage in the Device Console. The command shows the relevant storage areas on 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 inspect the file systems in more detail. This command shows size, used space, free space, 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 read-only. 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 areas of disk usage, Sophos lists these read-only commands in the Advanced Shell. The relative directory names assume that /var is the working directory; check that you are in that directory before running them. The output shows disk space, not memory (RAM):

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.

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

Set up and test Sophos Firewall quarantine digests explains automatic cleanup of the quarantine area at 90 percent, digest delivery, user assignment and the release test.

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

Reduce quarantine and mail spool usage deliberately

Before reducing quarantine space, review retention and release requirements and save any required messages. If those requirements permit it, select the lowest available disk-area option for Email quarantine under Email > Quarantine settings. Under Email > Mail spool, Retry makes a controlled redelivery attempt and Delete removes messages. Check message identity, delivery requirements, and evidence preservation first: Delete is irreversible. Afterwards, check the queue, delivery outcome, and free space; Retry does not guarantee successful delivery.

Stop diagnostic collection before further cleanup

Coordinate any active support collection with support first. Download the required evidence under Diagnostics > Tools using Troubleshooting logs or Consolidated troubleshooting report, and check the saved files. Once the required logs have been obtained, turn off debug logging for the affected components. Also turn off packet capture under Diagnostics > Packet capture. Confirm that both collections have stopped and recheck the storage trend before purging further logs. Re-enable debug or capture later only for a time-bounded diagnostic need, not routinely after cleanup.

Control central reporting and local event logs separately

Select Central reporting for the required modules under System services > Log settings. Registration for central firewall management in Sophos Fusion (formerly Sophos Central) is a prerequisite. The firewall sends event logs there, which are used to generate and store reports centrally. This is separate from both local report retention and the global On-Box Reports switch. For capacity planning, estimate storage requirements using the Data Storage Estimation Tool and compare them with the storage plans available under the reporting licence. Enabling transmission alone does not guarantee a suitable retention period.

Optionally, you can turn off local event-log storage for selected or all modules under System services > Log settings. First confirm receipt at the external syslog server, retention, and suitability for support and compliance; record the original module selections. After the change, verify continued external receipt, the expected limitation in local Log Viewer, and the storage trend. If necessary, restore the original local selections and check new local events. This rollback has not been product-tested here and does not backfill missing events. Local service logs may still be needed; the log-suppression warning still applies.

Do not delete manually in the file system

Even though the Advanced Shell shows free space and directories, do not delete files directly from /var, /log, or database directories. Manual deletion can damage reports, services, databases, or support data and make subsequent root-cause analysis more difficult.

A narrowly limited exception is positively identified files that you personally copied into /var as the administrator. Before removal, record the exact path, origin, and purpose, rule out active dependencies, and preserve required evidence outside the firewall. Remove only that identified copy, not system, log, or database files. If provenance is uncertain, stop and involve support. Deletion is not a reversible recovery step. Afterwards, recheck free space and the health of affected services; no manual deletion command or wildcard is deliberately provided here.

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.
• Purge reports deliberately only after preserving the required data: use Manual purge in WebAdmin first; use Flush Device Reports only if this does not free enough disk space and preparations have been made for the reboot and internet outage.
• 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 don’t replace root-cause analysis and are used only after the required logs have been saved and the affected subsystem has been identified unambiguously:

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

The first two commands affect all troubleshooting logs: purge-old-logs removes compressed rotations, while purge-all-logs also removes current files. The two subsystem variants limit the same actions to a supported subsystem. Verify the valid name with CLI help or tab completion before running the command. A purge can’t be undone; when in doubt, a targeted export under Diagnostics > Tools is cleaner.

Change report partition write permissions only deliberately

The Device Console can globally allow or block writes to the report partition. The SFOS 22 syntax only names report; partition-name is a keyword, not a placeholder for an arbitrary path. Before making a change, record the state read with show as the approved baseline; the product default is no substitute for this record:

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

The default is enable. disable isn’t storage cleanup and doesn’t delete reports. It prevents writes to the report partition and can therefore leave local report data, views, and dependent processes incomplete. Change the setting only as a planned recovery or support action, not as tuning:

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

Rollback restores the exact documented, approved baseline. The following commands allow writes again only if that baseline was enable and this procedure changed it to disable. If the approved policy was already disable, leave it disabled or restore it using the disable command shown above, then read the state again with show. Enabling a deliberately disabled policy with support approval is a new recovery measure, not a rollback:

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

enable alone does not prove that the report database and local views are writing correctly again. After restoring an enabled baseline or enabling writes under a new approval, check a new reporting period, Generate now, local dashboards, scheduled reports, and the storage trend if On-Box Reporting is active. For a deliberately disabled baseline, confirm disable with show instead; local report generation is not a success criterion in this case. Still check the storage trend and any workflows that remain necessary, such as external retention. These steps do not backfill missing data or history. If the partition remains read-only despite an approved enable setting, or if I/O errors occur, do not toggle the setting repeatedly. Check the SSD, virtual report disk, mount state, and support case instead.

Adjust report retention in WebAdmin

If local reports are the cause, check their retention period first. Many environments still retain on-box reports out of habit even though reporting is now handled centrally.

The Sophos path for local report retention is:

Reports > Show Reports settings > Data management

There you can set retention for each report module to a maximum of one year and save it with Apply. SFOS counts backward from the previous month, so the current month is not the first retention month. Changes take effect at 00:00. This setting affects reports, not event logs.

Useful questions before making a change:

• Are local reports really still being evaluated?
• Is there already Sophos Fusion 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 Fusion, it is also worth checking which log types are sent to Sophos Fusion under System services > Log settings. Activation is described in Activate Sophos Fusion Firewall Reporting.

Customize and complete a report export

Under Reports > Show Reports settings > Data management, Export customization controls which reports are included in an export and how many records are exported per report. Select only the required reports and set the records per report before starting the export; this is separate from retention and does not purge local data.

Complete the export in WebAdmin as follows; report downloads aren’t available from the CLI:

1. Go to Reports and open Applications & web.
2. Select the report criteria from Show and choose the date range.
3. Select Generate and review the result.
4. Select the required file format to download the report data.
5. Open the downloaded file and confirm that the intended reports, period, and number of records are present before relying on it as a backup or audit artifact.

The configured records-per-report value limits the downloaded content. A successfully downloaded file therefore isn’t proof that every local record was exported; compare its scope with the operational or compliance requirement.

Delete reports in a controlled manner

If services no longer work correctly because storage is full, reports may need to be purged manually. Treat this as a controlled recovery measure, not routine maintenance.

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

Use WebAdmin first:

Reports > Show Reports settings > Manual purge

After selecting the report module and criterion, you can specify a custom period or purge all data for that module. Selecting Purge starts the operation immediately, and it cannot be undone. The purge is intentionally slow: SFOS processes five database tables per minute to conserve system resources.

Flush Device Reports is used only if Manual purge in WebAdmin does not free enough disk space. A recovery state alone does not meet this documented prerequisite. The console menu item is:

5. Device Management > 4. Flush Device Reports

⚠️ Flush Device Reports deletes the reports stored on the firewall and reboots it. The firewall is unreachable over the network for about ten minutes. Until it is back online, the current internet gateway connection is also interrupted: internet traffic passing through this firewall stops. Prepare a maintenance window, notify affected users and arrange suitable console access before proceeding. The exports and backups mentioned above must have been checked; do not assume that a configuration backup can restore deleted reports.

Once the firewall is back online, check the internet gateway connection, free disk space, reports, Log Viewer, Sophos Fusion Reporting and affected services. If disk space remains low or services do not appear to be working correctly, preserve the current findings and involve support rather than blindly repeating the step.

Flush Device Reports refers to the documented report deletion and reboot operation, not to instructions for formatting the report disk. It must not be taken to imply an additional console menu item for formatting. Formatting would be a separate destructive operation and is not presented here as a cleanup procedure.

If full storage is already affecting services, identify which data will be lost before deleting it. Local reports are often useful for change reviews, user analysis, security investigations, or support. Record the affected period, the reason for deletion, and any replacement source such as Sophos Fusion Reporting or Syslog.

Check or deactivate On-Box Reports

On-Box Reports stores report data locally on the firewall. This is convenient but can consume significant storage on small appliances, with high traffic, or with long retention periods.

Before making a change, check the status in the Device Console and record the displayed on or off state as the baseline:

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 alternative retention is available, you can disable on-box reports:

set on-box-reports off

Prepare the rollback before disabling reporting; it must restore the exact documented baseline. The following commands using on apply only if the saved state was on and this procedure actually changed it to off. If On-Box Reporting was already off, leave it off or restore it using the off command shown above, then check again with show on-box-reports. Deliberately enabling previously disabled reporting under a new approval is a new operational or recovery decision, not a rollback. on starts local report generation again; do not assume that a gap from the disabled period will be backfilled:

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

After restoring on, check a new local report, Log Viewer, a scheduled report, and the storage trend. The on status alone does not prove that the reporting database and report views are working correctly again. For a saved off baseline, use show on-box-reports to confirm that the state is still off, and check the storage trend, the intended alternative retention, and any Log Viewer or reporting workflows that remain necessary. A new local report is not required for this disabled baseline.

Only disable the feature after considering the consequences. Reports are important for analysis, support, and operations. In many production environments, reducing local retention while also using Sophos Fusion Reporting, Syslog, or a SIEM is the better approach. If longer central retention is required, Sophos Central Firewall Reporting Advanced is one 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.

After disabling On-Box Reports, check more than storage usage. Local report views, scheduled PDF reports, security analysis, and quick ad-hoc investigations on the firewall may become unavailable or less useful. Disabling the feature is therefore an operational decision, not an ad-hoc cleanup step.

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.

Read and record the current value in Device Console before making a change. The SFOS 22 documentation uses report-disk-usage for reading and var-partition-usage for setting the threshold. Check the syntax with CLI help on the target release; if the current value cannot be read, do not change the warning threshold:

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

default sets the warning threshold to 70 percent and doesn’t automatically restore a previous custom value. For rollback, explicitly set the number recorded with show. The switch neither changes the 80-percent reporting-stop boundary nor deletes reports, logs, or an existing capacity bottleneck.

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 storage 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 provides only short-term relief. Resize or rebuild the virtual platform through a planned change with a backup, maintenance window, and restore plan.

This is especially important before SFOS 22: if the firewall shows a storage warning or upgrade blocker for the virtual disk, first complete the SFOS 22 Upgrade Check. It links to the official Sophos guidance for virtual disks. Perform any expansion in a planned maintenance window with a backup, verified hypervisor capacity, and subsequent partition checks.

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.
• Affected partition noted.
• 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.
• Sophos Fusion reporting, syslog or other central storage checked.
• Backup and recovery path available.
• Maintenance window defined when productive services are affected.
• For HA, both nodes checked separately.
• Period and reason for report cleanup documented.

After cleaning

• Free storage checked again.
• Reports checked according to the documented active or disabled baseline, and Log Viewer checked; new local report generation not required as a success criterion when local reporting is disabled.
• Sophos Fusion Reporting or Syslog checked for current data.
• Cause of storage growth documented.
• Retention period, log settings and review process adjusted.
• Notifications for future storage warnings checked.

FAQ