Sophos Firewall Backup erstellen oder wiederherstellen

Ein Sophos Firewall Backup ist die Grundlage für Firmware-Updates, Hardwaretausch, Reimage, HA-Arbeiten und Migrationen. Die Datei allein reicht jedoch nicht: Für einen verlässlichen Restore braucht es zusätzlich das Backup-Passwort, den passenden Secure Storage Master Key (SSMK), eine kompatible Zielversion und einen funktionierenden Managementzugang.

⚠️ Wichtig: Vor einem riskanten Change müssen Backup-Datei, Passwort, SSMK, Zielversion, Management-IP und Restore-Pfad auffindbar und geprüft sein. Ein Backup, das nur lokal auf der Firewall liegt oder dessen Schlüssel fehlt, ist kein belastbarer Rückweg.

Recovery-Weg und Voraussetzungen

Passenden Recovery-Weg wählen

Ein Restore ist nicht für jedes Problem die richtige erste Massnahme:

• Firmware-Update planen: Sophos Firewall Firmware Update: Vorbereitung und Best Practices.
• Firmware im WebAdmin installieren: Sophos Firewall Firmware Update durchführen.
• Central-Task hängt: Sophos Central Firewall Management Task Queue prüfen.
• SFOS vollständig neu installieren: Sophos Firewall OS per USB-Stick neu installieren.
• Hardwaredefekt oder RMA: Sophos Supportticket eröffnen.
• HA-Cluster wiederherstellen: Sophos Firewall HA-Cluster Varianten.

Vor einem Reimage ist ein Restore-Backup fast immer nötig. Ein Firmware-Rollback ersetzt dagegen kein Backup, weil Firmware-Slot und gesicherter Konfigurationsstand unterschiedliche Rückwege sind.

Backup-Passwort und Secure Storage Master Key

Aktuelle Sophos-Firewall-Backups sind mit einem Passwort verschlüsselt. Wurde das Backup nach Einrichtung des SSMK erstellt, benötigt der Restore das Backup-Passwort und zusätzlich den damaligen SSMK.

Der SSMK schützt sensible Informationen wie Passwörter, Secrets und Schlüssel. Er wird vom standardmässigen admin-Konto eingerichtet und gehört in einen Passwortmanager oder ein anderes abgesichertes Recovery-Verfahren. Mindestens zwei berechtigte Personen sollten wissen, wo er liegt.

Wird der SSMK später geändert, bleiben ältere Backups an den früheren Schlüssel gebunden. Deshalb müssen aktuelle und frühere SSMK-Versionen mit Zeitraum und Firewallbezug aufbewahrt werden.

Legacy-Backups ohne SSMK lassen sich ohne Master Key wiederherstellen. Wird ein geplantes Backup ohne SSMK restauriert, läuft der gespeicherte Zeitplan weiter; die Frequenz lässt sich aber erst nach Einrichtung eines SSMK ändern. Danach sollte sofort ein neues manuelles Backup erstellt werden.

Die öffentliche SFOS-22-Hilfe widerspricht sich beim Factory Reset: Die spezifische Reset-Seite sagt, der SSMK werde nicht gelöscht, während die allgemeine Firmware-Seite seine Entfernung nennt. Deshalb wird der Schlüssel vor jedem Reset extern gesichert und sein Zustand danach geprüft, statt sich auf seine Verfügbarkeit zu verlassen. Ein Reimage entfernt den aktuellen SSMK eindeutig; Boot with factory default configuration in der Firmware-Ansicht behält ihn laut Sophos. Ein Firmware-Rollback aktiviert den Konfigurationsstand der vorherigen Partition. Die gesicherte Schlüsselhistorie bleibt bei jedem dieser Wege nötig.

SSMK nur als geplanten Break-Glass-Change zurücksetzen

Der Secure Storage Master Key lässt sich nur über die CLI mit dem default Super Administrator admin zurücksetzen. Der Menüpunkt erscheint erst, nachdem ein SSMK erstellt wurde. Ein anderer Administrator kann diesen Change nicht ausführen.

⚠️ Der neue SSMK kann alte, mit dem bisherigen Schlüssel erstellte Backups nicht entschlüsseln. Ein Reset ersetzt deshalb weder die gesicherte Schlüsselhistorie noch den alten SSMK. Der Vorgang ist kein risikoloser Test.

Vor dem Reset werden ein aktuelles Backup, das Backup-Passwort und der bisherige SSMK extern gesichert. Danach führt der Weg über 2. System Configuration > 5. Reset secure storage master key:

1. Passwort des default admin eingeben.
2. Neuen SSMK eingeben.
3. Den neuen Schlüssel zur Bestätigung erneut eingeben.

Der neue Schlüssel benötigt mindestens 12 Zeichen sowie mindestens einen Grossbuchstaben, einen Kleinbuchstaben, eine Ziffer und eines der von SFOS unterstützten Sonderzeichen:

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

Er gehört direkt mit Firewall, Seriennummer und Aktivierungsdatum in den geschützten Recovery-Speicher, niemals in ein Ticket, einen Screenshot oder die Shell-History.

Nach dem erfolgreichen Reset wird sofort ein neues manuelles Backup erstellt und extern gesichert. Zusätzlich werden geplante Backups, gespeicherte Zugangsdaten, VPNs, Zertifikate, Central-Verbindung und Managementzugriff geprüft. Frühere Backups bleiben zusammen mit dem jeweils damaligen SSMK aufbewahrt; der neue Schlüssel macht sie nicht wiederherstellbar.

Recovery-Paket pro Firewall

Pro Standort oder Mandant sollte neben dem Backup ein geschütztes Recovery-Paket vorhanden sein:

• letztes geprüftes Backup mit Datum und Zweck
• Backup-Passwort sowie aktueller und frühere SSMK
• Firewallname, Seriennummer, Modell und SFOS-Version
• WAN-Zugangsdaten, Providerinformationen und Default Gateway
• Interface-, VLAN-, LAG-, Bridge- und HA-Portbelegung
• lokaler Admin- und Break-Glass-Zugang
• Lizenz- und Sophos-Central-Zuordnung
• kritische Dienste mit konkreten Abnahmetests

Backup und Zugangsdaten sollten nicht ungeschützt nebeneinander liegen. Nach Personal-, Provider-, Port-, HA- oder Standortänderungen ist das Recovery-Paket zu aktualisieren.

Backups erstellen und sicher betreiben

Manuelles Backup vor Changes

Backup & Firmware > Backup & Restore

Mit Backup Now wird ein sofortiges Backup erzeugt. Danach die Datei extern speichern und mindestens Firewallname, Seriennummer, SFOS-Version, Datum und Change-Zweck dokumentieren.

Unter Download kann entweder Download encrypted backup oder Encrypt backup with a different password before you download gewählt werden. Das zweite Passwort gilt nur für diese heruntergeladene Kopie; es ändert nicht das unter Encryption password hinterlegte Passwort für weitere Backups. Datei und tatsächlich verwendetes Passwort werden deshalb zusammen eindeutig dem Recovery-Paket zugeordnet.

Ein manuelles Backup ist besonders wichtig vor:

• Firmware-, Interface-, VLAN-, Routing-, SD-WAN- oder VPN-Änderungen
• HA-Einrichtung, Rollenwechsel oder Clusterwartung
• grösseren NAT-, WAF- oder Firewall-Regeländerungen
• Reimage, Factory Reset, Hardwaretausch oder Plattformmigration

Für grössere Changes kann Sophos Firewall Config Studio zusätzlich Konfigurationsunterschiede sichtbar machen. Ein Entities.xml-Vergleich ersetzt aber kein Restore-Backup.

Soll nur ein klar abgegrenzter Konfigurationsteil übertragen oder angepasst werden, beschreibt Konfiguration selektiv exportieren und importieren den getrennten WebAdmin-Ablauf. Auch dieser Import ersetzt den vollständigen Recovery-Weg nicht.

Automatische Backups

Unter Frequency lassen sich tägliche, wöchentliche oder monatliche Backups konfigurieren. Als Ziele stehen je nach Konfiguration lokale Ablage, FTP und E-Mail zur Verfügung.

Wichtig für den Betrieb:

• Ein lokales Backup hilft nicht, wenn die Appliance ausfällt oder neu installiert wird.
• Auf der Firewall bleibt nur das letzte lokale Backup erhalten; benötigte ältere Stände müssen extern gesichert werden.
• FTP- und E-Mail-Backups gelten erst nach einem echten Zustell-, Abruf- und Entschlüsselungstest als funktionsfähig.
• SFOS 22 begrenzt Backup prefix auf 32 Zeichen und akzeptiert dort unter anderem kein /, \, :, *, ?, ", <, >, |, ~, `, .. oder nicht englische UTF-8-Buchstaben. Ein FTP-Benutzername darf kein \ enthalten; in FTP-Benutzername und -Passwort sind als Sonderzeichen nur @, / und $ unterstützt. Der Hostname im Betreff eines E-Mail-Backups wird auf 25 Zeichen begrenzt.
• Automatische Backups ersetzen kein frisches manuelles Backup direkt vor einem riskanten Change.
• Aufbewahrungsfrist, Zugriff und Löschprozess müssen zum Schutzbedarf der Konfiguration passen.

Firewall-Backups enthalten vertrauliche Informationen zu Netzen, Regeln, VPNs, Zertifikaten und Kontodaten. Der Zugriff sollte auf Admins und Recovery-Verantwortliche begrenzt sein; Passwort und SSMK bleiben getrennt, aber im Notfall auffindbar.

Sophos Central Backups

Sophos dokumentiert derzeit zwei Central-Navigationspfade, abhängig von Ansicht und Hilfeseite:

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

Die Firewall muss mit Sophos Central verbunden und für Konfigurationsbackups freigegeben sein. Die Einrichtung der Verbindung beschreibt Sophos Firewall mit Sophos Central verbinden.

Den Zeitplan immer ausdrücklich prüfen, statt sich auf einen vermuteten Default zu verlassen. Wird die erste Firewall automatisch zu einem leeren Zeitplan mit Never hinzugefügt, kann Central einmalig auf Monthly und den ersten Monatstag wechseln. Bestehende Zeitpläne werden dadurch nicht geändert.

Weitere feste Eigenschaften:

• Backups laufen um 08:00 Uhr in der Zeitzone der Central-Region; die Uhrzeit ist nicht änderbar.
• Central versucht eine Erstellung bis zu fünf Mal und erzeugt danach Alert und Admin-E-Mail.
• Die fünf neuesten Backups bleiben erhalten; zusätzlich kann genau ein Backup dauerhaft gespeichert werden.
• Beim Download wird das Backup mit einem neu vergebenen Passwort erneut verschlüsselt.
• Wird die Firewall aus Central Management entfernt, löscht Sophos die zugehörigen Central-Backups. Vor Account-Wechsel, RMA oder Tenant-Bereinigung benötigte Dateien herunterladen.
• Bei HA werden Primary und Auxiliary in den Zeitplan aufgenommen, das Backup wird aber vom Primary erzeugt.

Wenn eine registrierte Firewall nicht im Zeitplan erscheint, unter Schedule Backup hinzufügen. Ist Send configuration backup to Sophos Central bereits aktiv, den Haken entfernen, anwenden, erneut setzen, wieder anwenden und danach die ausstehende Service-Freigabe in Central akzeptieren.

Central ist ein guter zusätzlicher Speicherort, aber kein Ersatz für SSMK, lokalen Zugang, WAN-Daten und eine unabhängig erreichbare Backup-Kopie.

Restore vorbereiten und durchführen

Vorbereitung und sicherer Restore-Test

Vor dem Restore klären:

• richtige Backup-Datei, Passwort und damaliger SSMK vorhanden
• Quellversion, Zielversion, Modell und Plattform kompatibel
• Ist-Backup der aktuellen Konfiguration extern gesichert
• Management-IP aus dem Backup und lokaler Zugriff bekannt
• WAN-, NTP-, DNS-, Lizenz- und Central-Daten dokumentiert
• HA-Ziel und Restore-Reihenfolge festgelegt
• Interface-Mapping und abweichende Portbelegung vorbereitet

⚠️ Achtung: Ein Restore überschreibt die aktuelle Konfiguration und startet die Firewall neu. Eine Warnung vor einem nicht unterstützten Migrationspfad darf nicht routinemässig bestätigt werden; die Firewall kann danach mit Factory-Konfiguration starten.

Ein echter Restore-Test gehört auf eine geeignete Labor- oder Ersatzfirewall. Vor dem Test produktive WAN-, VPN- und Central-Verbindungen deaktivieren oder isolieren, damit keine Adresskonflikte, Tunnel oder doppelte Registrierungen entstehen.

Ohne Testgerät ist zumindest ein organisatorischer Test möglich: Backup aus der vorgesehenen Ablage abrufen, Zuordnung prüfen, Passwort und SSMK bestätigen, Zielplattform bewerten sowie Managementzugang und Abnahmetests im Runbook durchspielen. Das ersetzt keinen echten Restore, beseitigt aber viele klassische Notfallprobleme.

Backup wiederherstellen

Backup & Firmware > Backup & Restore

1. Ziel-Firewall über WebAdmin erreichen.
2. Aktuellen Zustand sichern, falls noch möglich.
3. Unter Restore configuration mit Choose file die Backup-Datei auswählen.
4. Encryption password und bei einem SSMK-geschützten Backup zusätzlich den damaligen SSMK eingeben.
5. Upload and Restore starten.
6. Neustart und Wiederherstellung abwarten.
7. WebAdmin über die Management-IP aus dem Backup öffnen.
8. Zeitzone, NTP und aktuelle Uhrzeit prüfen.
9. Netzwerk, Dienste, VPN, HA und Central-Anbindung validieren.

Der Restore löscht das lokal gespeicherte Backup auf der Ziel-Firewall. Die verwendete Datei muss deshalb extern verfügbar bleiben. Bei einer neuen Appliance zuerst den Einrichtungswizard abschliessen und danach das Backup einspielen.

Was ein Restore nicht automatisch löst

Mit Ausnahme des Passworts des standardmässigen admin-Kontos stellt SFOS die Konfiguration einschliesslich MFA-Token aller Benutzer, VPN-Benutzer, RED, Site-to-Site- und Remote-Access-VPN sowie Sophos-Connect-Konfigurationen wieder her. Auch ApplianceCertificate, Default CA, SecurityAppliance_SSL_CA und Pre-Shared Keys kommen aus dem Backup. Sobald Routing und Interfaces wieder aktiv sind, können diese Vertrauensstellungen und Tunnel erneut wirksam werden. Ein Labor-Restore bleibt deshalb isoliert, bis VPN, RED, Zertifikate, Central und die Zielnetze kontrolliert wurden.

• Das Passwort des standardmässigen admin-Kontos wird nicht aus dem Backup übernommen; die Ziel-Firewall behält ihr vorhandenes Passwort. Ist es verloren, erklärt der separate Passwort-Recovery-Artikel den seriellen Weg für physische Appliances sowie die Grenzen für virtuelle und Cloud-Firewalls.
• Management-IP, Device Access, Routen und Dienste stammen nach dem Neustart wieder aus dem Backup.
• Benutzerdefinierte Datum- und Uhrzeitwerte unter Administration > Time sind nicht im Backup enthalten. Nur Zeitzone und NTP-Server werden restauriert; manuelle Zeitwerte müssen nach dem Restore neu gesetzt und geprüft werden.
• Modell- oder instanzabhängige Werte können auf Defaults zurückfallen, wenn sie auf dem Ziel nicht passen. Sophos nennt die Anzahl der IPS-Instanzen als Beispiel: Wird sie während des Restore modellspezifisch geändert, übernimmt das Ziel seinen Default statt des Werts aus dem Backup.
• Sophos Central bleibt nur beim Restore auf dieselbe Firewall registriert. Eine andere Firewall oder ein HA-Cluster muss neu registriert werden; danach Security Heartbeat, ZTNA, Central Management, Backup, Reporting, Task Queue und Gruppenzuordnung prüfen.
• Logs, Reports und externe Monitoring-Daten sind kein Bestandteil eines vollständigen Konfigurations-Rollbacks.

Bei einer Migration in den FIPS-140-3-Modus ist der Backup-Status zusätzlich entscheidend: Ein Backup mit deaktiviertem FIPS stellt auch den Nicht-FIPS-Zustand wieder her und ist deshalb Rückweg, aber keine unveränderte Übernahme in den FIPS-Modus.

Restore auf andere Hardware und Plattformen

Kompatibilität und SFOS-Versionen

Vor einer Migration Quellversion, Zielversion, Zielmodell und Plattform notieren. Der Backup-restore compatibility check ist inzwischen Teil von Sophos Firewall Config Studio. Dort Backup-restore compatibility öffnen und die Kompatibilität der XG-/XGS-Modelle sowie der eingesetzten Flexi-Port-Module und Transceiver prüfen. Das Tool gilt für SFOS 20.0 MR2 und neuer; zusätzlich die Upgrade-Informationen der aktuellen Release Notes und die Hinweise im SFOS 22 Upgrade-Check berücksichtigen.

Für SFOS 22 gelten harte Grenzen:

• SFOS 22.0 GA und neuer unterstützt keine XG- oder SG-Hardware.
• Backups mit Legacy-CLI-VLAN-Tagging auf Bridge-Interfaces lassen sich nicht auf SFOS 22.0 GA oder neuer restaurieren. Die Bereinigung beschreibt Bridge-VLANs vor SFOS 22 prüfen.
• Legacy Remote Access IPsec blockiert das Upgrade auf SFOS 22.0 MR1 und neuer. Bei Restore oder Import auf diese Versionen wird die alte Konfiguration nicht migriert; vorab auf den unterstützten Weg umstellen. Der Ablauf steht unter Legacy Remote Access IPsec migrieren.

Backup-Restore Assistant und Interface-Mapping

Der Assistant erscheint nur, wenn alle Bedingungen erfüllt sind:

• Backup stammt von XG, SG mit SFOS, XGS, virtuell oder Cloud mit SFOS 19.5 MR4 oder neuer.
• Ziel läuft mit SFOS 20.0 MR2 oder neuer.
• Ziel ist XGS, virtuelle oder Cloud-Appliance.

Auf XG- oder SG-Zielen sowie bei Backups aus SFOS 19.5 MR3 oder älter erscheint kein Assistant. Die Firewall mappt dann automatisch; Interfaces, Zonen, Gateways, VLANs, HA-Link, SD-WAN, NAT und VPN sind danach besonders sorgfältig zu prüfen.

Der Assistant kann auch auf derselben geeigneten Appliance genutzt werden, um VLANs oder Interface-Konfigurationen auf einen anderen physischen Port zu verschieben.

Im Assistant werden Quell- und Zielmodell, Interface-Details und die möglichen Zuordnungen gemeinsam angezeigt. Beim Überfahren eines Quellinterfaces zeigt SFOS dessen IP-Adresse, Subnetzmaske, IP-Zuweisungstyp und Link mode. Diese Werte werden vor dem Mapping mit Portplan und Verkabelung abgeglichen; ein ähnlicher Portname allein ist kein ausreichendes Zuordnungskriterium.

SFOS ordnet standardmässig gleichwertige Ports zu. Fehlt der entsprechende Port auf dem Zielgerät, wählt es den nächsten verfügbaren Port. Diese Automatik ist nur ein Vorschlag und muss kontrolliert werden; mit Don’t map. Creates Pseudo port bleibt die Konfiguration stattdessen bewusst an einem nicht funktionalen Pseudo-Port erhalten.

Physische und logische Interfaces

• Physischer Port: bewusst auf einen Zielport mappen oder nicht mappen; Verkabelung, Zone und WAN-/LAN-Funktion prüfen.
• VLAN oder Alias: folgt dem gemappten Parent-Interface; der Parent-Port muss fachlich stimmen.
• LAG oder Bridge: wird aus den gemappten physischen Ports neu erstellt; Member-Anzahl und Switch-Konfiguration kontrollieren.
• RED oder Cellular: zugehörige Konfiguration wird migriert; Verbindung nach Restore gezielt testen.

Pseudo-Ports, Breakout, Management und HA

• Pseudo-Port: bewahrt Konfiguration, verarbeitet aber keinen Traffic. Routing, NAT, VLANs und Regeln auf einen aktiven Port umstellen.
• Breakout Root Port: nur Root-Ports, nicht einzelne Member, lassen sich mappen. Das Ziel braucht eine unterstützte Portanzahl und -kombination. Anlage, Neustart und Abnahme erklärt Breakout-Interfaces konfigurieren.
• Management-Port: wird auf einen vorhandenen Management-Port gemappt oder als Pseudo-Port erhalten. Managementnetz und lokalen Zugang vorab planen.
• Dedicated HA-Link: Porttyp muss gleich bleiben; der Assistant kann den HA-Link-Port nicht ändern. Bei LAG müssen Member-Anzahl, bei VLAN die VLAN-ID und bei monitored ports der Zielstatus passen.

Ein Pseudo-Port hat den Status Not available und normalerweise den Hardwarenamen Pseudo<port number>. Bei Backups aus SFOS 19.5 MR3 oder älter kann stattdessen der ursprüngliche Portname stehen; funktional verfügbar ist das Interface trotzdem nicht. Bei Breakout muss das Ziel mindestens gleich viele Breakout-Ports konfiguriert haben wie das Backup. Gemappt werden nur Root-Ports; ein physischer Quellport darf auf einen unterstützten Breakout Root Port zeigen.

Vor dem Löschen eines Pseudo-Ports alle abhängigen Routen, NAT-, Firewall- und VLAN-Konfigurationen umstellen. Danach unter Network > Interfaces die Zone auf None setzen und die Firewall in einem Wartungsfenster neu starten. Anschliessend prüfen, ob der Port entfernt wurde; ungebundene Pseudo-Ports mit VLAN-Konfiguration werden nicht automatisch gelöscht.

Der Backup-Restore Assistant ordnet Interfaces neu zu, macht eine auf dem Ziel nicht unterstützte Wireless- oder Bridge-Konfiguration aber nicht kompatibel. Solche Abhängigkeiten müssen vor dem Migrationsbackup auf der Quelle bereinigt oder für das Ziel neu geplant werden.

HA-, Wireless-, virtuelle und Cloud-Ziele

Soll die HA-Konfiguration erhalten bleiben, darf ein HA-Backup nur auf einen HA-Cluster zurückgespielt werden. Entweder zuerst den neuen Cluster konfigurieren und das Backup auf dem Primary restaurieren oder zuerst restaurieren und danach HA konfigurieren. Rollen, Firmwarestand, Dedicated HA-Link und überwachte Ports anschliessend prüfen.

Sophos unterscheidet für diesen Restore drei Wireless-Gruppen: Gen.2 umfasst XGS 88w, 108w, 118w und 128w, Gen.1 umfasst XGS 87w, 107w, 116w, 126w und 136w, und zur XG-Serie gehören XG 86w, 106w, 115w, 125w und 135w. Diese Gruppenzuordnung entscheidet über die unterstützte Restore-Richtung; ein ähnlich klingender Modellname genügt nicht.

Wireless-Migrationen haben zusätzliche Grenzen:

• Für Wireless-zu-Non-Wireless müssen Wireless Networks vor dem Backup entfernt werden.
• Backups von Gen.2-XGS-Wireless-Modellen lassen sich nicht auf XG- oder Gen.1-XGS-Wireless-Modelle restaurieren.
• Bei älteren Wireless-Modellen auf Gen.2-XGS gelten weitere Grenzen für SSIDs, WPA, Bridge-Modus und Funkbänder.

LocalWiFi und Bridge-Konfigurationen bei der Migration

Für den Restore eines Backups von XG-Wireless oder Gen.1-XGS-Wireless auf ein Gen.2-XGS-W-Modell gelten diese Voraussetzungen und Einschränkungen:

• Auf LocalWiFi0 und LocalWiFi1 sind nur SSIDs mit mindestens WPA2 zugewiesen.
• Die Verschlüsselung verwendet weder TKIP noch TKIP/AES.
• Kein Wireless-Interface ist Mitglied einer physischen Bridge.
• LocalWiFi0 und LocalWiFi1 verwenden zusammen höchstens acht eindeutige SSIDs.
• Verwenden beide Radios dasselbe Frequenzband, werden nur die Einstellungen von LocalWiFi0 restauriert.

Der Bridge-Unterschied ist dabei entscheidend. Für ein Wireless Network vom Typ Bridge to AP LAN verbinden die Gen.1-Modelle XGS 87w, 107w, 116w, 126w und 136w das lokale WLAN über eine physische Bridge mit dem LAN. Die Gen.2-Modelle XGS 88w, 108w, 118w und 128w unterstützen dieses Design nicht; dort wird unter Wireless > Access points > LocalWiFi > Advanced settings die Option Bridge to Ethernet mit genau einem Ethernet-Port und der Zone LAN verwendet. Die Konfiguration auf Gen.2 beschreibt WLAN direkt auf Sophos Firewall einrichten.

Enthält das Gen.1-Backup noch eine physische Bridge mit dem Interface eines Wireless Networks vom Typ Bridge to AP LAN, schlägt der Restore auf Gen.2 fehl. Sophos führt dieses Verhalten als Known Issue NC-135094. Referenzieren OSPF, OSPFv3, RIP, SPX Portal Setting oder Quarantine dieses Interface, läuft der Restore durch, die abhängige Konfiguration funktioniert auf Gen.2 jedoch nicht.

Vor dem Migrationsbackup daher unter Network > Interfaces prüfen, ob ein Wireless-Interface in einer Bridge steckt, und alle abhängigen Einstellungen dokumentieren. Eine produktive Bridge nicht spontan löschen: IP-Adresse, Zone, DHCP, angeschlossene Ports und Routing-Abhängigkeiten zuerst in einem Wartungsfenster auf ein Gen.2-kompatibles Design umstellen. Danach ein neues Backup erstellen. Auf dem Ziel Bridge to Ethernet neu konfigurieren und anschliessend SSIDs, Sicherheitsmodus, Frequenzbänder, DHCP sowie die zuvor abhängigen Dienste gezielt testen.

Vor einer XG-zu-XGS-Migration hilft zusätzlich die Gegenüberstellung von XG und XGS.

Für virtuelle und Cloud-Firewalls ist das integrierte Sophos-Backup-Restore-Verfahren der einzige unterstützte SFOS-Recovery-Pfad. Hypervisor-Snapshots, Cloud-Images und Drittanbieter-Backups werden von Sophos dafür nicht unterstützt und können Datenintegritätsprobleme oder nicht unterstützte Konfigurationen verursachen.

Nach dem Restore validieren

Technische Kontrolle

Direkt nach dem Restore prüfen:

• WebAdmin-IP, erlaubte Management-Netze und Device Access
• Interfaces, Zonen, VLANs, Bridges, LAGs und Alias-Interfaces
• WAN, PPPoE, Default Gateway, statische und SD-WAN-Routen
• Firewall-, NAT- und WAF-Regeln samt Reihenfolge
• IPsec, SSL VPN, Sophos Connect, RED und Remote Access
• Zertifikate, TLS Inspection, DNS, DHCP, NTP und Authentication Server
• HA-Status, Rollen und Synchronisation
• Lizenzstatus, Pattern Updates, Hotfixes und Central-Synchronisation
• Log Viewer, Syslog, Central Reporting und lokales Reporting

Je nach Fehler helfen Log Viewer, Policy Test und Packet Capture, Packet Capture im WebAdmin und die Übersicht Services und Logs. Sophos nennt für allgemeine Restore-Fehler keinen belastbaren universellen SSH-Logpfad; deshalb wird hier kein Shell-Befehl geraten.

Eine detaillierte Fehlermeldung in WebAdmin ist laut Sophos nur für einen engeren Restore-Pfad zugesichert: Das Backup stammt von einer kompatiblen Appliance mit SFOS 19.5 MR4 oder neuer, das Ziel läuft mit SFOS 20.0 MR2 oder neuer und ist ein XGS 88/88w, 108/108w, 118/118w, 128/128w oder 138. Bei anderen Zielen bedeutet eine fehlende UI-Meldung nicht, dass kein Fehler vorliegt. Zeitpunkt, Quell- und Zielversion, Modelle und genaue Restore-Aktion werden deshalb gesichert und mit Logs beziehungsweise einem Supportfall korreliert. Hardware-Revisionen Rev.1, Rev.2 und Rev.3 folgen denselben Kompatibilitätsregeln; das konkrete Modellpaar wird trotzdem im Compatibility Check geprüft.

Abnahmetests

Ein erreichbarer WebAdmin beweist nicht, dass produktiver Traffic funktioniert. Pro Standort sollten konkrete Quelle, Ziel, erwartete Regel und erwarteter Logeintrag für diese Tests dokumentiert sein:

• Management: Zugriff aus dem Managementnetz und zweiter Adminzugang.
• Internet: Testclient erreicht ein definiertes externes Ziel über richtige Regel, NAT und WAN-Route.
• DNS und DHCP: Client erhält Adresse und löst interne sowie externe Namen auf.
• Site-to-Site VPN: definierte Hosts sind in beide Richtungen erreichbar.
• Remote Access: Testbenutzer prüft Login, MFA, Profil, DNS und internes Ziel.
• WAF oder DNAT: externer Test bestätigt Zertifikat, Regel, Backend und Logging.
• Authentifizierung: AD, LDAP, RADIUS, STAS oder Entra SSO erkennt einen Testbenutzer korrekt.
• Logging: Testtraffic ist in Log Viewer, Syslog, Central Reporting oder SIEM sichtbar.
• HA: Rollen, Clusterstatus und Synchronisation entsprechen dem Plan.

Wenn WAN, DNS, Remote Access oder HA nicht funktionieren, nicht gleichzeitig an mehreren Stellen ändern. Fehlerfall mit Uhrzeit, Testquelle, Ziel, Regel und Logauszug eingrenzen und nach jeder Korrektur erneut testen.

Troubleshooting und Betrieb

Typische Fehler

• Backup liegt nur auf der Firewall: bei Defekt oder Reimage nicht erreichbar; extern und geschützt speichern.
• SSMK fehlt: geschützte Daten lassen sich nicht restaurieren; aktuellen und frühere Schlüssel dokumentieren.
• Datei ohne Geräte- oder Versionsbezug: falsches Backup wird gewählt; Firewallname, Seriennummer, Version und Datum festhalten.
• Kein Ist-Backup vor Restore: Rückweg zum vorherigen Zustand fehlt.
• Wiederhergestellte Management-IP unbekannt: Firewall wirkt offline; Adresse und lokalen Zugriff vorab dokumentieren.
• Zeit oder NTP falsch: VPN, Zertifikate, Authentifizierung und Central können scheitern.
• Nicht unterstützter Restore-Pfad bestätigt: Restore schlägt fehl oder Ziel startet mit Factory-Konfiguration.
• Interface-Mapping ungeprüft: WAN, VLAN, VPN oder HA-Link landen auf falschen Ports.
• Wireless-Grenzen ignoriert: Backup ist inkompatibel oder Funkkonfiguration funktioniert nicht wie erwartet.
• HA-Kontext ignoriert: Clusterkonfiguration oder Rollen gehen verloren beziehungsweise starten falsch.
• Central als einzige Kopie: nach Entfernung aus Central sind die dortigen Backups gelöscht.
• Nur WebAdmin geprüft: Routing, NAT, VPN, WAF, DNS oder Logging bleiben unbemerkt defekt.

Betriebsrhythmus

Regelmässig:

• automatische Backups, Zustellung, Abruf und Aufbewahrung prüfen
• Backup-Ablage, Berechtigungen sowie aktueller und frühere SSMK kontrollieren
• Recovery-Paket und Abnahmetests aktuell halten
• stichprobenweise Datei, Passwort, SSMK und Zielkompatibilität prüfen

Vor grösseren Änderungen:

• manuelles Backup erstellen, extern speichern und eindeutig beschriften
• Managementzugang, Restore-Pfad und Abbruchkriterien festlegen
• bei Migration Compatibility, SFOS-Version und Interface-Mapping prüfen

Nach einem Restore:

• technische Kontrolle und Abnahmetests vollständig dokumentieren
• Abweichungen korrigieren und bei Bedarf mit Config Studio vergleichen
• neues Backup des geprüften Zielzustands erstellen und Recovery-Paket aktualisieren