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.

The public SFOS 22 help contradicts itself about factory reset: the dedicated reset page says the SSMK isn’t cleared, while the general firmware page says it is removed. Therefore, store the key externally before every reset and verify its state afterward instead of relying on it remaining available. A reimage clearly removes the current SSMK; according to Sophos, Boot with factory default configuration in the Firmware view retains it. A firmware rollback activates the configuration state of the previous partition. The retained key history remains necessary for each of these paths.

Reset the SSMK only as a planned break-glass change

The Secure Storage Master Key can only be reset through the CLI with the default Super Administrator admin. The menu option appears only after an SSMK has been created. Another administrator cannot perform this change.

⚠️ The new SSMK cannot decrypt old backups created with the previous key. A reset therefore replaces neither the retained key history nor the old SSMK. This operation is not a harmless test.

Before the reset, store a current backup, its backup password, and the previous SSMK externally. Then go to 2. System Configuration > 5. Reset secure storage master key:

  1. Enter the password of the default admin.
  2. Enter the new SSMK.
  3. Reenter the new key to confirm it.

The new key requires at least 12 characters, including at least one uppercase letter, one lowercase letter, one digit, and one of the special characters supported by SFOS:

! # $ % & ( ) * + , - . / : ; < = > ? @ [ ] ^ _ ` { | } ~

Store it immediately with the firewall, serial number, and activation date in the protected recovery system, never in a ticket, screenshot, or shell history.

After a successful reset, immediately create and externally store a new manual backup. Also verify scheduled backups, stored credentials, VPNs, certificates, the Central connection, and management access. Retain previous backups together with their respective SSMK; the new key does not make them restorable.

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

Under Download, select either Download encrypted backup or Encrypt backup with a different password before you download. The second password applies only to that downloaded copy; it does not change the Encryption password stored for later backups. Therefore, associate the file and the password actually used unambiguously with the recovery package.

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.
  • SFOS 22 limits Backup prefix to 32 characters and does not accept /, \, :, *, ?, ", <, >, |, ~, `, .., or non-English UTF-8 letters, among other characters. An FTP username must not contain \; the only supported special characters in FTP usernames and passwords are @, /, and $. The hostname in the subject of an email backup is limited to 25 characters.
  • 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 Fusion 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 Fusion and enabled for configuration backups. Connect Sophos Firewall to Sophos Fusion 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 Sophos Fusion.

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

Except for the password of the default admin account, SFOS restores the configuration including MFA tokens for all users, VPN users, RED, site-to-site and remote-access VPN, and Sophos Connect configurations. ApplianceCertificate, Default CA, SecurityAppliance_SSL_CA, and pre-shared keys also come from the backup. Once routing and interfaces are active again, these trust relationships and tunnels can become effective. Therefore, keep a lab restore isolated until VPN, RED, certificates, Central, and the target networks have been checked.

  • 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.
  • Custom date and time values under Administration > Time are not included in the backup. Only the time zone and NTP servers are restored; manual time values must be reconfigured and verified after the restore.
  • Model- or instance-dependent values can revert to defaults if they do not fit the target. Sophos gives the number of IPS instances as an example: If it is changed for the target model during restore, the target applies its default instead of the value from the backup.
  • Sophos Fusion 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 and XGS Appliance 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, an XGS Appliance, virtual, or cloud running SFOS 19.5 MR4 or later.
  • The target runs SFOS 20.0 MR2 or later.
  • The target is an XGS Appliance, 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.

The assistant shows the source and target models, interface details, and available mappings together. Hovering over a source interface shows its IP address, subnet mask, IP assignment type, and link mode. Compare these values with the port plan and cabling before mapping; a similar port name alone is not a sufficient mapping criterion.

By default, SFOS maps equivalent ports. If the corresponding port does not exist on the target device, it selects the next available port. Treat this automation only as a proposal and verify it; Don’t map. Creates Pseudo port deliberately retains the configuration on a non-functional pseudo port instead.

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. Configure breakout interfaces explains creation, restart, and verification.
  • 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.

A pseudo port has the status Not available and normally the hardware name Pseudo<port number>. Backups from SFOS 19.5 MR3 or earlier can show the original port name instead, but the interface still is not functional. For breakout, the target must have at least as many breakout ports configured as the backup. Only root ports are mapped; a physical source port can map to a supported breakout root port.

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

A backup containing an HA configuration can also be restored to a standalone device, but SFOS then restores only the rest of the configuration, not HA. To retain HA, configure the new cluster first and restore the backup to the current Primary, or restore first and configure HA afterward. You can’t restore a backup to the Auxiliary.

On an existing active-passive or active-active cluster, the current Primary restarts after the restore without failover. The restore therefore causes downtime in both HA modes. If the backup contains an HA configuration, the Primary synchronizes the Auxiliary after restarting. Restoring to an HA cluster also deregisters both firewalls from Sophos Fusion. Register both firewalls with Sophos Fusion again and, if the Primary was used as a Sophos ZTNA gateway, add it as a gateway again. If a backup without HA configuration is restored to the current Primary, HA is disabled and must be configured again. Then specifically check roles, firmware version, Dedicated HA link, and monitored ports.

Sophos distinguishes three Wireless groups for this restore: Gen.2 includes XGS 88w, 108w, 118w, and 128w; Gen.1 includes XGS 87w, 107w, 116w, 126w, and 136w; and the XG series includes XG 86w, 106w, 115w, 125w, and 135w. This group membership determines the supported restore direction; a similar-looking model name is not sufficient.

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 migrating from XG to an XGS Appliance, the Comparison of XG and XGS Appliance 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.

According to Sophos, a detailed error message in WebAdmin is guaranteed only for a narrower restore path: The backup comes from a compatible appliance running SFOS 19.5 MR4 or later, the target runs SFOS 20.0 MR2 or later, and it is an XGS 88/88w, 108/108w, 118/118w, 128/128w, or 138. On other targets, the absence of a UI message does not mean that no error occurred. Record the time, source and target versions, models, and exact restore action, then correlate them with logs or a support case. Hardware revisions Rev.1, Rev.2, and Rev.3 follow the same compatibility rules, but the specific model pair must still be checked in the Compatibility Check.

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