Create or Restore a Sophos Firewall Backup

A Sophos Firewall backup is more than just a file for emergencies. It is the foundation for firmware updates, hardware replacement, XG-to-XGS migrations, reimage, HA operations, and clean recovery processes. If the backup, Secure Storage Master Key, and restore compatibility are not prepared, a planned change can quickly turn into an unnecessarily long outage.

This article explains how to create and restore Sophos Firewall backups, what additional information should be documented, and what checks are important before restoring to other hardware or platforms.

⚠️ Important: A backup is only helpful if it is findable, decryptable, and compatible with the target environment. Before firmware updates, reimage, HA changes, or migrations, you should consciously check the backup file, backup password, Secure Storage Master Key, target version, and restore process.

Video Guide

Which Recovery Path Fits?

Backup and restore are often only part of the problem. Depending on the situation, a different procedure may be appropriate:

In practice, these processes overlap. Before a reimage, a backup is almost always needed. Before a support case, serial number, firmware version, logs, and previous steps are important. After a Central-controlled update, the task queue can explain why a change has not yet reached the firewall.

Why a Backup Alone Is Not Enough

A downloaded backup reduces risk but does not automatically solve every recovery problem. In practice, it also requires:

• a secure storage location outside the firewall
• a clear assignment to firewall, serial number, location, and SFOS version
• the appropriate Secure Storage Master Key (SSMK)
• the backup password if the backup was encrypted
• documented WAN, VLAN, HA, VPN, and license information
• a tested restore plan for hardware replacement, reimage, or migration

Especially before a firmware update, a reimage via USB stick, or an SFOS 22 upgrade check, the backup should not only be created but also professionally reviewed.

Before the First Backup: Check Secure Storage Master Key

Before encrypted backups are used productively, the Secure Storage Master Key (SSMK) should be set and securely documented. Without this key, a restore on a fresh appliance or in certain recovery scenarios can fail.

This is especially relevant when:

• preparing a replacement firewall
• planning a migration to another model
• moving configurations between hardware, virtual appliance, and cloud
• storing backups outside the firewall

The SSMK belongs in a password manager or another secured recovery procedure. It should not be known only to a single person. If the key is only searched for in an emergency, valuable recovery time is already lost.

Create Backup: Manually and Automatically

The WebAdmin path is:

Backup & Firmware > Backup & Restore

Manual Backup Before Changes

Use Backup Now for an immediate backup. The backup should not just remain in the browser download folder but be consciously stored.

A manual backup should always be created before these operations:

• Firmware update or hotfix with risk of restart or behaviour change
• Interface, VLAN, routing, SD-WAN, or VPN restructuring
• HA setup, HA role change, or HA maintenance
• Major NAT, WAF, or firewall rule change
• Reimage, factory reset, or hardware replacement
• Migration from XG to XGS, hardware to virtual, or virtual to cloud

After downloading, at least the date, firewall name, serial number, SFOS version, and purpose of the backup should be documented. For major changes, a comparison with Sophos Firewall Config Studio later helps to understand configuration differences before and after the change.

Set Up Automatic Backups

To ensure backups are not forgotten, an automatic backup should be set up. Under Frequency, you can define daily, weekly, or monthly backups.

Automatically generated backups can be stored locally on the firewall, on an FTP server, or via email. The storage location is less important than the surrounding process:

• Those who store backups via email or on an external server should check encryption and access protection.
• Local backups on the firewall are not helpful if the appliance needs to be completely replaced or reinstalled.
• Central backups are practical but should not be the only known recovery path.
• Automatic backups do not replace a manual backup directly before risky changes.
• Old backups should be managed with retention period, access, and deletion process.

If the firewall is connected to Sophos Central, central storage of configuration backups can also be useful. The Central connection is described in the article Connect Sophos Firewall to Sophos Central.

Store Backup Securely

Firewall backups contain sensitive information about network structure, objects, rules, services, VPNs, certificates, and partially protected account data. Therefore, they should be treated like confidential infrastructure files.

For operations, these rules are sensible:

• Do not store backup files unencrypted in general team folders.
• Limit access to firewall backups to admins and recovery responsible persons.
• Document backup password and SSMK separately but findably.
• Use a clear naming convention per location or firewall.
• After admin departures, check if backup storage and password manager access still fit.
• Document restore-relevant information such as WAN access data, PPPoE, static provider data, or HA port allocation separately.

A backup is not a substitute for operational documentation. Especially with HA clusters, multiple WAN uplinks, or complex VPN environments, it should also be documented which interfaces, provider data, and dependencies need to be checked first after a restore.

Prepare Recovery Package Per Firewall

In an emergency, most time is not lost uploading the backup file but searching for additional information. Therefore, a small recovery package should exist per location or tenant for productive firewalls.

This package should not be an unprotected text file next to the backup. Better is a combination of password manager, internal operational documentation, and clear responsibility. At least two authorized persons should know where this information is and how to access it in an emergency.

After personnel changes, site restructuring, provider changes, HA changes, or major migration, the recovery package should be checked. A formally current backup is of little help if the documented WAN IP, port allocation, or Central assignment is no longer correct.

Prepare for Restore

Before a restore, it should first be clarified what the goal is. A restore on the same appliance after a misconfiguration is different from a restore after reimage, hardware replacement, or platform change.

Preparation:

• Is there a fresh backup of the current state?
• Is the backup file clearly assigned to the correct firewall?
• Are backup password and SSMK available?
• Does the SFOS version of the target system match the backup?
• Is the restore path for source version, target version, and target platform approved?
• Is it being restored to identical hardware, another model, virtual appliance, or cloud?
• Will the Backup-Restore Assistant appear, or will automatic interface mapping occur?
• Is HA involved, or is an HA backup being restored to a single appliance?
• Is there local management access if WAN, VPN, or Central do not work immediately after restore?

⚠️ A restore overwrites the current configuration. On a productive firewall, you should create a new backup of the current state before the restore, even if the current configuration is faulty. In unsupported migration paths, the firewall can start with factory configuration after confirmation. This warning should not be treated and confirmed as a normal restore message.

Plan Restore Test Without Production Risk

A restore test is sensible but should not be lightly conducted on a productive firewall. The goal is not to regularly overwrite productive appliances but to verifiably check if the most important recovery prerequisites work.

A safe restore test can look like this depending on the environment:

• Retrieve backup file from planned storage.
• Check file name, date, firewall name, serial number, and SFOS version.
• Verify backup password and SSMK in the password manager.
• Perform backup-restore compatibility check for the planned target model.
• Document interface mapping and port deviations before a migration.
• Check planned target version against supported upgrade and backup-restore paths.
• Test in a lab or replacement firewall if the backup is fundamentally accepted.
• After a test restore, do not leave productive VPNs, WAN accesses, or Central connections uncontrolled active.

If no lab or replacement firewall is available, at least an organizational test is possible: find backup, check access, confirm password/SSMK, evaluate target platform with the Compatibility Check, and run through the process in the recovery runbook. This does not replace a real restore but prevents many classic emergency problems.

For critical locations, it should also be clear how the firewall becomes accessible again after a reimage or hardware replacement: local access, management port, WAN data, license status, Sophos Central assignment, and local contact person. This information belongs not only in the backup but in separate operational documentation.

Restore Backup

The restore is also done under:

Backup & Firmware > Backup & Restore

Basic procedure:

1. Access target firewall via WebAdmin.
2. Secure current state if still possible.
3. Select backup file.
4. Start Upload and Restore.
5. Enter backup password or SSMK if required.
6. Wait for restart and restoration.
7. Then check network, services, VPN, HA, and Central connection.

When a new or replaced Sophos Firewall is deployed, the backup can be applied after initial access to the appliance. The initial IP address and first access depend on the respective model and deployment type. For hardware appliances, local initial access via the standard management IP or setup wizard is common.

Once the firewall is accessible and the setup wizard is completed, the restore can be performed as described above.

Restore to Other Hardware or Platforms

Especially for migrations between XG and XGS or between hardware, virtual appliance, and cloud, it should be checked before the restore whether the backup is compatible. Sophos offers a public backup-restore compatibility check for this.

Additionally, the target version must fit. Sophos distinguishes between approved upgrade and backup-restore paths and unsupported migrations. If a firewall warns before restart that the planned migration is not supported, you should not simply confirm. After confirming an unsupported migration, the firewall can start with factory configuration, causing the current configuration to be lost.

For a productive restore, this means:

• First note source version, target version, target model, and platform
• Bring target firewall to a supported SFOS version before restore
• Perform backup-restore compatibility check for the specific combination
• Take warnings in the restore or upgrade dialog seriously and document them
• If unsure, first test on replacement hardware or in a test environment

Backup-Restore Assistant and Automatic Interface Mapping

For backups from newer SFOS versions, the Backup-Restore Assistant appears depending on the target platform. It helps assign interfaces when restoring a backup from XG, SG with SFOS, or XGS to an XGS series, virtual appliance, or cloud firewall. This is especially important if the target firewall has fewer ports, different port names, wireless variants, or Flexi-Port modules.

For very old backups, the assistant may be missing. Then the firewall assigns interfaces automatically. This is faster but riskier because you do not consciously confirm the assignment in the assistant. After such a restore, interfaces, zones, gateways, VLANs, HA link, SD-WAN routes, NAT rules, and VPNs must be checked particularly carefully.

Additionally, you should pay attention to:

• Do the available ports and zone types match the target platform?
• Do interfaces need to be reassigned after the restore?
• Is an HA backup being restored to a single appliance or vice versa?
• Is the target system firmware on a reasonable level?
• Does an old XG or SG appliance need to be replaced due to lifecycle or SFOS-22 compatibility?
• Are license status, serial number, and Sophos Central assignment clarified after the restore?

If the port allocation differs, you usually need to check or rework an interface mapping after the restore. Before XG-to-XGS migrations, the article What is the Difference Between an XG and XGS Firewall? is also relevant.

After major restore or migration work, a comparison of configurations can help. Using Sophos Firewall Config Studio shows how to compare backups before and after a change and specifically check unexpected differences.

Check After Restore

After the restore, it should not only be checked whether WebAdmin is accessible. The firewall can be reachable and still process important services incorrectly.

Directly after the restore, check:

• Interfaces, zones, VLANs, bridges, LAGs, and alias interfaces.
• WAN uplinks, PPPoE, static provider data, and default gateway.
• SD-WAN routes, static routes, and dynamic routing.
• Firewall rules, NAT rules, WAF rules, and rule order.
• IPsec, SSL VPN, Sophos Connect, RED, and remote access.
• Certificates, CA certificates, WebAdmin certificate, and TLS inspection.
• DNS, DHCP, NTP, and authentication server.
• HA status if a cluster is used.
• License status, pattern updates, hotfixes, and Sophos Central synchronization.
• Logging, syslog targets, Central Firewall Reporting, and local reports.

For technical checks, depending on the problem, Log Viewer, Policy Test, and Packet Capture, Packet Capture in WebAdmin, and Services and Logs can help.

Acceptance Test After a Restore

A restore is only complete when the most important operational functions have been confirmed with real tests. An accessible WebAdmin only proves that the firewall is operable. It does not prove that routing, NAT, VPN, WAF, authentication, or logging are working correctly again.

For productive firewalls, there should therefore be a short acceptance matrix. This matrix does not have to be complicated but should specify per location which test must be performed after a restore and who documents the result.

A defined abort point is important. If basic tests like WAN, DNS, remote access, or HA do not work after a restore, corrections should not be made in many places simultaneously. Better is a narrow error case with time, test source, target, affected rule, and log excerpt. This keeps it traceable whether the problem comes from the backup, interface mapping, target hardware, or a subsequent change.

Typical Errors

Operational Checklist

Regularly:

• Activate automatic backups or define a central backup process.
• Check backup storage, access, and retention.
• Verify SSMK and backup password in password manager.
• Keep recovery package per location or firewall up to date.
• At least sporadically check if backups are findable and assignable.

Before major changes:

• Create manual backup and store externally.
• Document firewall name, serial number, SFOS version, and change purpose.
• Check SSMK, backup password, and admin access.
• Define rollback or restore plan.
• For migrations, check compatibility and interface mapping.
• Do not confirm warnings about unsupported restore or migration paths before an alternative plan is available.

After a restore:

• Test interfaces, routing, NAT, VPN, WAF, authentication, and Central.
• Work through acceptance matrix with real test sources, test targets, and expected logs.
• Check HA status and roles.
• Check logs and monitoring.
• For target versions from SFOS 22.0 MR1, check again if a restore or import has brought back old Legacy Remote Access IPsec configurations.
• Create new backup of the restored target state.
• Document deviations and compare with Config Studio if necessary.

FAQ