Skip to content
Avanet

Create or Restore a Sophos Firewall Backup

Sophos Firewall

A Sophos Firewall backup is the foundation for firmware updates, hardware replacement, reimage, HA work, and migrations. The file alone is not enough: a reliable restore also requires the backup password, the correct Secure Storage Master Key (SSMK), a compatible target version, and working management access.

⚠️ Important: Before a risky change, the backup file, password, SSMK, target version, management IP, and restore path must be available and verified. A backup stored only on the firewall, or whose key is missing, is not a reliable fallback.

The video shows backup and restore on Sophos Firewall and complements the practical recovery guidance in this article.

Recovery Path and Requirements

Choose the Appropriate Recovery Path

A restore is not the right first action for every problem:

A restore backup is almost always required before a reimage. A firmware rollback, however, does not replace a backup because the firmware slot and the saved configuration state are separate recovery paths.

Backup Password and Secure Storage Master Key

Current Sophos Firewall backups are encrypted with a password. If the backup was created after the SSMK was configured, the restore requires the backup password and the SSMK that was valid at that time.

The SSMK protects sensitive information such as passwords, secrets, and keys. It is configured by the default admin account and belongs in a password manager or another protected recovery process. At least two authorized people should know where it is stored.

If the SSMK is changed later, older backups remain tied to the previous key. Current and previous SSMK versions must therefore be retained with their validity period and firewall association.

Legacy backups without an SSMK can be restored without the master key. If a scheduled backup without an SSMK is restored, its saved schedule continues, but the frequency cannot be changed until an SSMK is configured. Create a new manual backup immediately afterward.

Recovery Package per Firewall

Each site or tenant should have a protected recovery package in addition to the backup:

  • latest verified backup with date and purpose
  • backup password and current and previous SSMKs
  • firewall name, serial number, model, and SFOS version
  • WAN credentials, provider information, and default gateway
  • interface, VLAN, LAG, bridge, and HA port assignments
  • local admin and break-glass access
  • license and Sophos Central assignment
  • critical services with concrete acceptance tests

Do not store the backup and credentials together without protection. Update the recovery package after personnel, provider, port, HA, or site changes.

Create and Operate Backups Securely

Manual Backup Before Changes

Backup & Firmware > Backup & Restore
Create a backup of the SFOS configuration
Sophos Firewall Backup & Restore: create a manual backup and configure scheduled backups

Backup Now creates an immediate backup. Store the file externally and document at least the firewall name, serial number, SFOS version, date, and purpose of the change.

A manual backup is particularly important before:

  • firmware, interface, VLAN, routing, SD-WAN, or VPN changes
  • HA setup, role changes, or cluster maintenance
  • major NAT, WAF, or firewall rule changes
  • reimage, factory reset, hardware replacement, or platform migration

For larger changes, Sophos Firewall Config Studio can also show configuration differences. An Entities.xml comparison does not replace a restore backup.

If only a clearly scoped configuration part needs to be transferred or changed, selectively export and import configuration describes the separate WebAdmin workflow. This import doesn’t replace the complete recovery path either.

Automatic Backups

Under Frequency, daily, weekly, or monthly backups can be configured. Depending on the configuration, the available destinations are local storage, FTP, and email.

Important operational points:

  • A local backup does not help if the appliance fails or is reinstalled.
  • Only the latest local backup remains on the firewall; older required versions must be stored externally.
  • FTP and email backups are only considered functional after an actual delivery, retrieval, and decryption test.
  • Do not use special characters in Backup prefix, FTP username, or password without testing.
  • Automatic backups do not replace a fresh manual backup immediately before a risky change.
  • Retention period, access, and deletion process must match the protection needs of the configuration.

Firewall backups contain confidential information about networks, rules, VPNs, certificates, and account data. Access should be limited to administrators and recovery owners; the password and SSMK remain separate but accessible in an emergency.

Sophos Central Backups

Sophos currently documents two Central navigation paths, depending on the view and help page:

Global Settings > Products and Services > Firewall
My Products > Firewall Management > Backup

The firewall must be connected to Sophos Central and enabled for configuration backups. Connect Sophos Firewall to Sophos Central describes the connection setup.

Always verify the schedule explicitly instead of assuming a default. When the first firewall is automatically added to an empty schedule set to Never, Central can change it once to Monthly and the first day of the month. Existing schedules are not changed.

Other fixed properties:

  • Backups run at 08:00 in the Central region’s time zone; the time cannot be changed.
  • Central attempts creation up to five times and then generates an alert and administrator email.
  • The five latest backups are retained; exactly one additional backup can be stored permanently.
  • On download, the backup is re-encrypted with a newly assigned password.
  • Removing the firewall from Central Management deletes its Central backups. Download required files before an account change, RMA, or tenant cleanup.
  • With HA, Primary and Auxiliary are added to the schedule, but the Primary creates the backup.

If a registered firewall does not appear in the schedule, add it under Schedule Backup. If Send configuration backup to Sophos Central is already enabled, clear the checkbox, apply, enable it again, apply, and then accept the pending service approval in Central.

Central is a useful additional storage location, but it does not replace the SSMK, local access, WAN data, and an independently accessible backup copy.

Prepare and Perform a Restore

Preparation and Safe Restore Test

Before the restore, confirm:

  • correct backup file, password, and SSMK from that time are available
  • source version, target version, model, and platform are compatible
  • current-state backup of the existing configuration is stored externally
  • management IP from the backup and local access are known
  • WAN, NTP, DNS, license, and Central data are documented
  • HA target and restore sequence are defined
  • interface mapping and differing port assignments are prepared

⚠️ Caution: A restore overwrites the current configuration and restarts the firewall. A warning about an unsupported migration path must not be routinely confirmed; the firewall can subsequently start with factory configuration.

Perform an actual restore test on a suitable lab or replacement firewall. Disable or isolate production WAN, VPN, and Central connections before the test to prevent address conflicts, tunnels, or duplicate registrations.

Without a test device, at least perform an organizational test: retrieve the backup from its intended storage, verify its assignment, confirm the password and SSMK, assess the target platform, and walk through management access and acceptance tests in the runbook. This does not replace a real restore, but it eliminates many common emergency problems.

Restore a Backup

Backup & Firmware > Backup & Restore
  1. Access the target firewall through WebAdmin.
  2. Save the current state if still possible.
  3. Under Restore configuration, select the backup file with Choose file.
  4. Enter the Encryption password and, for an SSMK-protected backup, the SSMK that was valid at that time.
  5. Start Upload and Restore.
  6. Wait for the restart and restoration.
  7. Open WebAdmin using the management IP from the backup.
  8. Check the time zone, NTP, and current time.
  9. Validate the network, services, VPN, HA, and Central connection.

The restore deletes the backup stored locally on the target firewall. The file used must therefore remain available externally. On a new appliance, complete the setup wizard first and then restore the backup.

What a Restore Does Not Solve Automatically

  • The password of the default admin account is not restored from the backup; the target firewall retains its existing password. If it has been lost, the separate password recovery article explains serial recovery for physical appliances and the limitations for virtual and cloud firewalls.
  • After the restart, the management IP, Device Access, routes, and services come from the backup again.
  • Time zone, NTP, and time must be checked as current operational state.
  • Model- or instance-dependent values can revert to defaults if they do not fit the target.
  • Sophos Central remains registered only when restoring to the same firewall. A different firewall or HA cluster must be registered again; then check Security Heartbeat, ZTNA, Central Management, Backup, Reporting, Task Queue, and group assignment.
  • Logs, reports, and external monitoring data are not part of a complete configuration rollback.

During a migration to FIPS 140-3 mode, the backup status is also decisive: A backup with FIPS disabled restores the non-FIPS state and is therefore a return path, not an unchanged transfer into FIPS mode.

Restore to Other Hardware and Platforms

Compatibility and SFOS Versions

Before a migration, record the source version, target version, target model, and platform. The backup-restore compatibility check is now part of Sophos Firewall Config Studio. Open Backup-restore compatibility there and check the compatibility of the XG/XGS models as well as the Flexi Port modules and transceivers in use. The tool applies to SFOS 20.0 MR2 and later; also consider the upgrade information in the current release notes and the SFOS 22 Upgrade Check.

Hard limits apply to SFOS 22:

  • SFOS 22.0 GA and later do not support XG or SG hardware.
  • Backups containing legacy CLI VLAN tagging on bridge interfaces cannot be restored to SFOS 22.0 GA or later. Check Bridge VLANs Before SFOS 22 describes the cleanup.
  • Legacy Remote Access IPsec blocks upgrades to SFOS 22.0 MR1 and later. Restoring or importing to these versions does not migrate the old configuration; move to the supported method first. See Migrate Legacy Remote Access IPsec.

Backup-Restore Assistant and Interface Mapping

The assistant appears only when all conditions are met:

  • The backup comes from XG, SG with SFOS, XGS, virtual, or cloud running SFOS 19.5 MR4 or later.
  • The target runs SFOS 20.0 MR2 or later.
  • The target is an XGS, virtual, or cloud appliance.

The assistant does not appear on XG or SG targets or for backups from SFOS 19.5 MR3 or earlier. The firewall then maps automatically; carefully check interfaces, zones, gateways, VLANs, HA link, SD-WAN, NAT, and VPN afterward.

The assistant can also be used on the same suitable appliance to move VLANs or interface configurations to another physical port.

Physical and Logical Interfaces

  • Physical port: deliberately map to a target port or leave unmapped; check cabling, zone, and WAN/LAN function.
  • VLAN or alias: follows the mapped parent interface; the parent port must be operationally correct.
  • LAG or bridge: recreated from the mapped physical ports; check member count and switch configuration.
  • RED or Cellular: associated configuration is migrated; specifically test the connection after restore.

Pseudo Ports, Breakout, Management, and HA

  • Pseudo port: retains configuration but does not process traffic. Move routing, NAT, VLANs, and rules to an active port.
  • Breakout root port: only root ports, not individual members, can be mapped. The target requires a supported port count and combination.
  • Management port: maps to an available management port or is retained as a pseudo port. Plan the management network and local access beforehand.
  • Dedicated HA link: the port type must remain the same; the assistant cannot change the HA link port. For LAG, the member count must match; for VLAN, the VLAN ID; and for monitored ports, the target status.

Before deleting a pseudo port, move all dependent routes, NAT, firewall, and VLAN configurations. Then set the zone to None under Network > Interfaces and restart the firewall in a maintenance window. Verify afterward that the port was removed; unbound pseudo ports with a VLAN configuration are not deleted automatically.

The Backup-Restore Assistant remaps interfaces, but it does not make a wireless or bridge configuration that is unsupported on the target compatible. Such dependencies must be cleaned up on the source before creating the migration backup or replanned for the target.

HA, Wireless, Virtual, and Cloud Targets

To retain the HA configuration, an HA backup may only be restored to an HA cluster. Either configure the new cluster first and restore the backup on the Primary, or restore first and configure HA afterward. Then check roles, firmware version, Dedicated HA link, and monitored ports.

Wireless migrations have additional limits:

  • For Wireless-to-Non-Wireless, remove Wireless Networks before creating the backup.
  • Backups from Gen.2 XGS Wireless models cannot be restored to XG or Gen.1 XGS Wireless models.
  • Additional limits for SSIDs, WPA, bridge mode, and radio bands apply when moving older Wireless models to Gen.2 XGS.

LocalWiFi and Bridge Configurations During Migration

The following prerequisites and restrictions apply when restoring a backup from XG Wireless or Gen.1 XGS Wireless to a Gen.2 XGS W model:

  • Only SSIDs with at least WPA2 are assigned to LocalWiFi0 and LocalWiFi1.
  • The encryption uses neither TKIP nor TKIP/AES.
  • No wireless interface is a member of a physical bridge.
  • LocalWiFi0 and LocalWiFi1 use no more than eight unique SSIDs in total.
  • If both radios use the same frequency band, only the LocalWiFi0 settings are restored.

The bridge difference is crucial. For a Wireless Network of the Bridge to AP LAN type, the Gen.1 models XGS 87w, 107w, 116w, 126w, and 136w connect the local wireless network to the LAN through a physical bridge. The Gen.2 models XGS 88w, 108w, 118w, and 128w do not support this design. On these models, use Bridge to Ethernet with exactly one Ethernet port and the zone LAN under Wireless > Access points > LocalWiFi > Advanced settings. Set up Wi-Fi directly on Sophos Firewall explains the Gen.2 configuration.

If the Gen.1 backup still contains a physical bridge with the interface of a Wireless Network of the Bridge to AP LAN type, the restore to Gen.2 fails. Sophos lists this behavior as Known Issue NC-135094. If OSPF, OSPFv3, RIP, SPX Portal Setting, or Quarantine reference this interface, the restore completes, but the dependent configuration does not work on Gen.2.

Before creating the migration backup, check under Network > Interfaces whether a wireless interface is part of a bridge and document all dependent settings. Do not delete a production bridge without preparation: first migrate the IP address, zone, DHCP, connected ports, and routing dependencies to a Gen.2-compatible design in a maintenance window. Then create a new backup. Configure Bridge to Ethernet on the target and specifically test the SSIDs, security mode, frequency bands, DHCP, and the previously dependent services.

Before an XG-to-XGS migration, the Comparison of XG and XGS also helps.

For virtual and cloud firewalls, the integrated Sophos backup-and-restore process is the only supported SFOS recovery path. Sophos does not support hypervisor snapshots, cloud images, or third-party backups for this purpose, and they can cause data-integrity problems or unsupported configurations.

Validate After the Restore

Technical Checks

Immediately after the restore, check:

  • WebAdmin IP, allowed management networks, and Device Access
  • interfaces, zones, VLANs, bridges, LAGs, and alias interfaces
  • WAN, PPPoE, default gateway, static routes, and SD-WAN routes
  • firewall, NAT, and WAF rules including order
  • IPsec, SSL VPN, Sophos Connect, RED, and Remote Access
  • certificates, TLS Inspection, DNS, DHCP, NTP, and Authentication Server
  • HA status, roles, and synchronization
  • license status, Pattern Updates, Hotfixes, and Central synchronization
  • Log Viewer, Syslog, Central Reporting, and local reporting

Depending on the issue, Log Viewer, Policy Test, and Packet Capture, Packet Capture in WebAdmin, and the Services and Logs overview can help. Sophos does not specify a reliable universal SSH log path for general restore errors, so no shell command is suggested here.

Acceptance Tests

An accessible WebAdmin does not prove that production traffic works. For each site, document the concrete source, target, expected rule, and expected log entry for these tests:

  • Management: access from the management network and a second administrator login.
  • Internet: a test client reaches a defined external target through the correct rule, NAT, and WAN route.
  • DNS and DHCP: a client receives an address and resolves internal and external names.
  • Site-to-Site VPN: defined hosts are reachable in both directions.
  • Remote Access: a test user verifies login, MFA, profile, DNS, and an internal target.
  • WAF or DNAT: an external test confirms certificate, rule, backend, and logging.
  • Authentication: AD, LDAP, RADIUS, STAS, or Entra SSO correctly identifies a test user.
  • Logging: test traffic is visible in Log Viewer, Syslog, Central Reporting, or SIEM.
  • HA: roles, cluster status, and synchronization match the plan.

If WAN, DNS, Remote Access, or HA does not work, do not change several areas simultaneously. Narrow the failure down using time, test source, target, rule, and log extract, and retest after each correction.

Troubleshooting and Operations

Typical Errors

  • Backup exists only on the firewall: unavailable after failure or reimage; store it externally and securely.
  • SSMK is missing: protected data cannot be restored; document current and previous keys.
  • File lacks device or version reference: the wrong backup is selected; record firewall name, serial number, version, and date.
  • No current-state backup before restore: no path back to the previous state.
  • Restored management IP unknown: the firewall appears offline; document the address and local access beforehand.
  • Time or NTP is wrong: VPN, certificates, authentication, and Central can fail.
  • Unsupported restore path confirmed: restore fails or the target starts with factory configuration.
  • Interface mapping not checked: WAN, VLAN, VPN, or HA link ends up on the wrong ports.
  • Wireless limits ignored: backup is incompatible or wireless configuration does not work as expected.
  • HA context ignored: cluster configuration or roles are lost or start incorrectly.
  • Central is the only copy: removing the firewall from Central deletes those backups.
  • Only WebAdmin checked: routing, NAT, VPN, WAF, DNS, or logging failures remain unnoticed.

Operating Rhythm

Regularly:

  • verify automatic backups, delivery, retrieval, and retention
  • check backup storage, permissions, and current and previous SSMKs
  • keep the recovery package and acceptance tests current
  • periodically verify the file, password, SSMK, and target compatibility

Before major changes:

  • create a manual backup, store it externally, and label it unambiguously
  • define management access, restore path, and abort criteria
  • for migrations, verify compatibility, SFOS version, and interface mapping

After a restore:

  • fully document technical checks and acceptance tests
  • correct deviations and compare with Config Studio if necessary
  • create a new backup of the verified target state and update the recovery package