Sophos Firewall Backup erstellen oder wiederherstellen

Ein Sophos Firewall Backup ist mehr als eine Datei für den Notfall. Es ist die Grundlage für Firmware-Updates, Hardwaretausch, XG-zu-XGS-Migrationen, Reimage, HA-Arbeiten und saubere Recovery-Prozesse. Wenn Backup, Secure Storage Master Key und Restore-Kompatibilität nicht vorbereitet sind, wird aus einem geplanten Change schnell ein unnötig langer Ausfall.

Der Artikel erklärt, wie man Sophos Firewall Backups erstellt und wiederherstellt, welche Informationen zusätzlich dokumentiert werden sollten und welche Prüfungen vor einem Restore auf andere Hardware oder Plattformen wichtig sind.

⚠️ Wichtig: Ein Backup ist nur dann hilfreich, wenn es auffindbar, entschlüsselbar und zur Zielumgebung kompatibel ist. Vor Firmware-Updates, Reimage, HA-Änderungen oder Migrationen sollte man Backup-Datei, Backup-Passwort, Secure Storage Master Key, Zielversion, Managementzugang und Restore-Ablauf bewusst prüfen.

Videoanleitung

Welcher Recovery-Weg passt?

Backup und Restore sind oft nur ein Teil des Problems. Je nach Situation ist ein anderer Ablauf sinnvoll:

• Firmware-Update planen: Sophos Firewall Firmware Update: Vorbereitung und Best Practices.
• Firmware-Image im WebAdmin installieren: Sophos Firewall Firmware Update durchführen.
• Central-Update oder Gruppenrichtlinie hängt: Sophos Central Firewall Management Task Queue prüfen.
• Firewall OS komplett neu installieren: Sophos Firewall OS neu installieren: Reimage mit USB-Stick.
• Hardwaredefekt, wiederholter Fehler oder RMA: Sophos Supportticket eröffnen: Vorbereitung und Portal.
• HA-Cluster wiederherstellen oder umbauen: Sophos Firewall HA-Cluster Varianten.

In der Praxis überschneiden sich diese Abläufe. Vor einem Reimage braucht es fast immer ein Backup. Vor einem Supportfall sind Seriennummer, Firmwareversion, Logs und bisherige Schritte wichtig. Nach einem Central-gesteuerten Update kann die Task Queue erklären, warum eine Änderung noch nicht auf der Firewall angekommen ist.

Warum ein Backup allein nicht reicht

Ein heruntergeladenes Backup reduziert das Risiko, löst aber nicht automatisch jedes Recovery-Problem. In der Praxis braucht es zusätzlich:

• einen sicheren Speicherort ausserhalb der Firewall
• eine klare Zuordnung zu Firewall, Seriennummer, Standort und SFOS-Version
• den passenden Secure Storage Master Key (SSMK)
• das Backup-Passwort, falls das Backup verschlüsselt wurde
• dokumentierte WAN-, VLAN-, HA-, VPN- und Lizenzinformationen
• einen geprüften Restore-Plan für Hardwaretausch, Reimage oder Migration

Gerade vor einem Firmware-Update, einem Reimage per USB-Stick oder einem SFOS 22 Upgrade-Check sollte das Backup nicht nur erstellt, sondern auch fachlich geprüft werden.

Vor dem ersten Backup: Secure Storage Master Key prüfen

Bevor manuelle oder geplante Backups produktiv genutzt werden, sollte der Secure Storage Master Key (SSMK) gesetzt und sicher dokumentiert werden. Ohne diesen Schlüssel kann ein Restore auf einer frischen Appliance oder bei bestimmten Recovery-Szenarien scheitern.

Das ist vor allem dann relevant, wenn:

• eine Ersatzfirewall vorbereitet wird
• eine Migration auf ein anderes Modell geplant ist
• Konfigurationen zwischen Hardware, virtueller Appliance und Cloud verschoben werden
• Backups ausserhalb der Firewall gespeichert werden

Der SSMK gehört in einen Passwortmanager oder ein anderes abgesichertes Recovery-Verfahren. Er sollte nicht nur einer einzelnen Person bekannt sein. Wenn der Schlüssel erst im Notfall gesucht wird, ist bereits wertvolle Wiederherstellungszeit verloren.

Wichtig: Ältere Backups bleiben an den SSMK gebunden, mit dem sie erstellt wurden. Wenn der Schlüssel später geändert oder zurückgesetzt wird, reicht der neue Schlüssel für diese alten Backups nicht aus. Deshalb sollten auch frühere SSMK-Versionen mit Datum, Gültigkeitszeitraum und betroffener Firewall dokumentiert werden. Ein SSMK-Wechsel ist keine beiläufige Aufräumaktion, sondern eine Recovery-relevante Änderung.

Geplante Backups ohne gesetzten SSMK sind ebenfalls ein Sonderfall. Sophos Firewall kann solche Backups zwar weiter nach dem wiederhergestellten Zeitplan erzeugen, aber die zusätzliche SSMK-Absicherung fehlt. Ausserdem sollte man die Backup-Frequenz erst als wirklich verwaltbar betrachten, wenn der SSMK gesetzt ist. Für produktive Firewalls ist deshalb sinnvoll: SSMK setzen, danach ein neues manuelles Backup erstellen und erst dann geplante Backups als belastbaren Recovery-Pfad bewerten.

Backup erstellen: manuell und automatisch

Der WebAdmin-Pfad lautet:

Backup & Firmware > Backup & Restore

Manuelles Backup vor Changes

Für ein sofortiges Backup Backup Now verwenden. Die Sicherung sollte danach nicht nur im Browser-Download-Ordner liegen bleiben, sondern bewusst abgelegt werden.

Vor diesen Arbeiten sollte immer ein manuelles Backup erstellt werden:

• Firmware-Update oder Hotfix mit Risiko für Neustart oder Verhaltensänderung
• Interface-, VLAN-, Routing-, SD-WAN- oder VPN-Umbau
• HA-Einrichtung, HA-Rollenwechsel oder HA-Wartung
• grössere NAT-, WAF- oder Firewall-Regeländerung
• Reimage, Factory Reset oder Hardwaretausch
• Migration von XG auf XGS, Hardware auf virtuell oder virtuell auf Cloud

Nach dem Download sollte man mindestens Datum, Firewallname, Seriennummer, SFOS-Version und Zweck des Backups dokumentieren. Für grössere Änderungen hilft später ein Vergleich mit Sophos Firewall Config Studio, um Konfigurationsunterschiede vor und nach dem Change nachvollziehen zu können.

Automatische Backups einrichten

Damit Backups nicht vergessen gehen, sollte eine automatische Sicherung eingerichtet werden. Unter Frequency kann man tägliche, wöchentliche oder monatliche Backups definieren.

Die automatisch generierten Sicherungen können lokal auf der Firewall, auf einem FTP-Server oder per E-Mail gespeichert werden. Entscheidend ist weniger der Speicherort als der Prozess rundherum:

• Wer Backups per E-Mail oder auf einen externen Server ablegt, sollte Verschlüsselung und Zugriffsschutz prüfen.
• Lokale Backups auf der Firewall helfen nicht, wenn die Appliance vollständig ersetzt oder neu installiert werden muss.
• Auf der Firewall selbst bleibt nur das jeweils letzte lokale Backup relevant. Wer ältere Stände behalten muss, sollte sie bewusst herunterladen oder extern sichern.
• Bei FTP- oder E-Mail-Backups sollte nicht nur die Einstellung geprüft werden. Auch Zustellung, Abruf, Berechtigungen und Wiederauffindbarkeit müssen getestet werden.
• Central-Backups sind praktisch, sollten aber nicht der einzige bekannte Recovery-Pfad sein.
• Automatische Backups ersetzen kein manuelles Backup direkt vor riskanten Änderungen.
• Alte Backups sollten mit Aufbewahrungsfrist, Zugriff und Löschprozess verwaltet werden.

Bei FTP-Backups und Backup prefix sollte man Sonderzeichen nicht blind verwenden. Sophos hat Einschränkungen bei Präfix, Benutzername und Passwort. Nach der Einrichtung zählt deshalb nicht die gespeicherte Einstellung, sondern ein echter Backup-, Download- und Restore-Vortest.

Wenn die Firewall mit Sophos Central verbunden ist, kann auch die zentrale Ablage von Konfigurationsbackups sinnvoll sein. Die Central-Anbindung ist im Artikel Sophos Firewall mit Sophos Central verbinden beschrieben.

Central Backups richtig einordnen

Sophos Central kann Firewall-Konfigurationsbackups planen, sofort erzeugen, herunterladen und für einen späteren Restore bereitstellen. Der Central-Pfad liegt unter:

My Products > Firewall Management > Backup

Central-Backups sind hilfreich, weil sie nicht auf der Firewall selbst liegen und in den Account Health Check einfliessen. Trotzdem braucht dieser Backup-Pfad einen bewussten Betrieb:

• Die globale Backup-Frequenz in Sophos Central startet als Never. Beim manuellen Einrichten über Schedule Backup kann die UI einen anderen Vorschlagswert zeigen. Wenn eine Firewall automatisch als erste zum Backup-Zeitplan hinzugefügt wird, stellt Sophos Central die Frequenz einmalig auf Monthly mit Startdatum am Monatsersten. Wenn eine Firewall trotz aktiviertem Send configuration backup to Sophos Central nicht im Zeitplan erscheint, hilft Schedule Backup > Add new firewall; alternativ Haken entfernen, Apply, erneut setzen, Apply und danach in Sophos Central accept-services ausführen.
• Geplante Central-Backups laufen um 08:00 Uhr in der Zeitzone der Sophos-Central-Region. Diese Uhrzeit kann nicht angepasst werden.
• Sophos Central versucht eine Backup-Erstellung bis zu fünf Mal. Wenn sie danach weiterhin fehlschlägt, entsteht ein Alert und eine E-Mail an den Central-Administrator.
• Central behält die fünf neuesten Backups. Ein Backup kann zusätzlich dauerhaft gespeichert werden, bis es ersetzt oder gelöscht wird.
• Beim Download aus Central wird das Backup mit einem neuen Passwort re-encrypted. Dieses Passwort gehört danach ebenfalls in das Recovery-Verfahren.
• Wenn eine Firewall aus Sophos Central Management entfernt wird, entfernt Sophos auch die zugehörigen Central-Backup-Dateien. Vor Account-Wechsel, Tenant-Cleanup oder RMA sollte man benötigte Backups vorher herunterladen.
• Bei HA-Clustern werden Primary und Auxiliary in den Backup-Zeitplan aufgenommen, erzeugt wird das Backup aber vom Primary.

Central Backup ist damit ein guter zusätzlicher Recovery-Pfad, aber kein Grund, lokale Wiederherstellung, SSMK, Adminzugang und Standortdokumentation zu vernachlässigen.

Backup sicher speichern

Firewall-Backups enthalten sensible Informationen über Netzstruktur, Objekte, Regeln, Dienste, VPNs, Zertifikate und teilweise geschützte Kontodaten. Deshalb sollten sie wie vertrauliche Infrastrukturdateien behandelt werden.

Für den Betrieb sind diese Regeln sinnvoll:

• Backup-Dateien nicht unverschlüsselt in allgemeinen Teamordnern ablegen.
• Zugriff auf Firewall-Backups auf Admins und Recovery-Verantwortliche begrenzen.
• Backup-Passwort und SSMK getrennt, aber auffindbar dokumentieren.
• Pro Standort oder Firewall eine klare Namenskonvention verwenden.
• Nach Admin-Austritten prüfen, ob Backup-Ablage und Passwortmanager-Zugriff noch passen.
• Restore-relevante Informationen wie WAN-Zugangsdaten, PPPoE, statische Providerdaten oder HA-Portbelegung separat dokumentieren.

Ein Backup ist kein Ersatz für Betriebsdokumentation. Besonders bei HA-Clustern, mehreren WAN-Uplinks oder komplexen VPN-Umgebungen sollte zusätzlich dokumentiert sein, welche Schnittstellen, Providerdaten und Abhängigkeiten nach einem Restore zuerst geprüft werden müssen.

Recovery-Paket pro Firewall vorbereiten

Im Notfall verliert man die meiste Zeit nicht beim Hochladen der Backup-Datei, sondern beim Suchen der Zusatzinformationen. Für produktive Firewalls sollte deshalb pro Standort oder Mandant ein kleines Recovery-Paket existieren.

In dieses Paket gehören:

• Letztes geprüftes Backup: Grundlage für Restore, Migration oder Reimage.
• Backup-Passwort und Secure Storage Master Key: Notwendig für verschlüsselte Backups und geschützte Daten.
• Seriennummer, Modell und SFOS-Version: Wichtig für Support, Lizenzierung und Kompatibilitätsprüfung.
• WAN-Daten und Providerinformationen: Nötig, wenn nach dem Restore Internetzugang oder Central-Anbindung fehlt.
• Interface- und Portbelegung: Entscheidend bei XG-zu-XGS-Migrationen, Flexi-Ports, VLAN-Trunks und HA.
• Admin- und Break-Glass-Zugriff: Erlaubt lokalen Zugriff, wenn VPN, Central oder SSO noch nicht funktionieren.
• Lizenz- und Central-Zuordnung: Verhindert Verwechslungen bei Ersatzhardware, virtuellen Firewalls oder Cloud-Instanzen.
• Kritische Dienste und Abnahmetests: Zeigt nach dem Restore schnell, ob VPN, NAT, WAF, DNS, DHCP und Logging wieder funktionieren.

Dieses Paket sollte nicht als ungeschützte Textdatei neben dem Backup liegen. Besser ist eine Kombination aus Passwortmanager, interner Betriebsdokumentation und klarer Zuständigkeit. Mindestens zwei berechtigte Personen sollten wissen, wo diese Informationen liegen und wie man im Ernstfall darauf zugreift.

Nach Personalwechsel, Standortumbau, Providerwechsel, HA-Änderung oder grosser Migration sollte das Recovery-Paket geprüft werden. Ein formal aktuelles Backup hilft wenig, wenn die dokumentierte WAN-IP, Portbelegung oder Central-Zuordnung nicht mehr stimmt.

Restore vorbereiten

Vor einem Restore sollte zuerst geklärt werden, welches Ziel verfolgt wird. Ein Restore auf dieselbe Appliance nach einer Fehlkonfiguration ist anders zu bewerten als ein Restore nach Reimage, Hardwaretausch oder Plattformwechsel.

Vorbereitung:

• Ist ein frisches Backup des aktuellen Zustands vorhanden?
• Ist die Backup-Datei eindeutig der richtigen Firewall zugeordnet?
• Sind Backup-Passwort und SSMK verfügbar?
• Passt die SFOS-Version des Zielsystems zum Backup?
• Ist der Restore-Pfad für Quellversion, Zielversion und Zielplattform freigegeben?
• Wird auf identische Hardware, anderes Modell, virtuelle Appliance oder Cloud wiederhergestellt?
• Wird der Backup-Restore Assistant erscheinen oder erfolgt ein automatisches Interface-Mapping?
• Ist HA beteiligt oder wird ein HA-Backup auf eine Einzelappliance zurückgeführt?
• Gibt es einen lokalen Managementzugang, falls WAN, VPN oder Central nach dem Restore nicht sofort funktionieren?
• Ist bekannt, welche WebAdmin-IP nach dem Restore aktiv wird?
• Sind Zeitzone, NTP-Server und allfällige manuelle Datum-/Zeit-Einstellungen dokumentiert?

⚠️ Ein Restore überschreibt die aktuelle Konfiguration. Auf einer produktiven Firewall sollte man vor dem Restore möglichst ein neues Backup des Ist-Zustands erstellen, auch wenn die aktuelle Konfiguration fehlerhaft ist. Bei nicht unterstützten Migrationspfaden kann die Firewall nach einer Bestätigung mit Factory-Konfiguration starten. Diese Warnung darf nicht als normale Restore-Meldung behandelt und bestätigt werden.

Was ein Restore nicht automatisch löst

Ein Restore stellt die Konfiguration wieder her, ersetzt aber keinen vollständigen Betriebscheck. Nach dem Neustart gelten wieder Management-IP, Interface-Konfiguration, Device Access, Zertifikate, Routen und Dienste aus der wiederhergestellten Konfiguration. Dadurch kann der WebAdmin plötzlich unter einer anderen IP erreichbar sein als während der Erstkonfiguration der Ersatzfirewall.

Zusätzlich sollte man diese Punkte bewusst prüfen:

• Manuelle Datum- und Zeitwerte werden nicht vollständig als Betriebszustand wiederhergestellt. Zeitzone, NTP und aktuelle Uhrzeit sollten nach dem Restore kontrolliert werden.
• Das Passwort des standardmässigen admin-Kontos wird beim Restore nicht durch das Backup ersetzt. Die Ziel-Firewall behält das vorhandene Default-Admin-Passwort.
• Logs, Reports und externe Monitoring-Daten sind kein Ersatz für ein Konfigurationsbackup und sollten separat gesichert oder zentral abgelegt werden.
• Zertifikate, VPNs, Central-Anbindung, Syslog-Ziele und Benachrichtigungen können nach einem Restore technisch vorhanden sein, aber trotzdem wegen Zeit, DNS, Routing oder geänderter Zielplattform nicht sauber funktionieren.
• Ein Restore auf andere Hardware löst Port- und Interface-Unterschiede nicht automatisch fachlich. Das Mapping muss zum Verkabelungs- und Zonenmodell passen.
• Modellabhängige Einstellungen können beim Restore auf eine andere Plattform auf Standardwerte zurückfallen, wenn sie auf dem Zielgerät nicht passen. Das betrifft zum Beispiel hardware- oder instanzspezifische Leistungs- und Portoptionen.
• Sophos Central Registrierung bleibt nur beim Restore auf dieselbe Firewall erhalten. Bei Restore auf andere Hardware oder HA wird die Firewall aus Sophos Central deregistriert. Nach dem Restore muss sie neu registriert werden, und Security Heartbeat, Sophos ZTNA, Central Management, Central Backup, Central Reporting sowie die Task Queue müssen einzeln neu geprüft und bei Bedarf neu konfiguriert werden. Bei Gruppenrichtlinien gehört auch die Gruppenzuordnung zur Nachkontrolle.

Restore-Test ohne Produktionsrisiko planen

Ein Restore-Test ist sinnvoll, sollte aber nicht leichtfertig auf einer produktiven Firewall durchgeführt werden. Ziel ist nicht, regelmässig produktive Appliances zu überschreiben, sondern nachweisbar zu prüfen, ob die wichtigsten Recovery-Voraussetzungen funktionieren.

Ein sicherer Restore-Test kann je nach Umgebung so aussehen:

• Backup-Datei aus der geplanten Ablage abrufen.
• Dateiname, Datum, Firewallname, Seriennummer und SFOS-Version prüfen.
• Backup-Passwort und SSMK im Passwortmanager kontrollieren.
• Backup-restore compatibility check für das geplante Zielmodell ausführen.
• Interface-Mapping und Port-Abweichungen vor einer Migration dokumentieren.
• Geplante Zielversion gegen die unterstützten Upgrade- und Backup-Restore-Pfade prüfen.
• In einer Labor- oder Ersatzfirewall testen, ob das Backup grundsätzlich angenommen wird.
• Nach einem Testrestore keine produktiven VPNs, WAN-Zugänge oder Central-Verbindungen unkontrolliert aktiv lassen.

Wenn keine Labor- oder Ersatzfirewall vorhanden ist, bleibt zumindest ein organisatorischer Test möglich: Backup finden, Zugriff prüfen, Passwort/SSMK bestätigen, Zielplattform mit dem Compatibility Check bewerten und den Ablauf im Recovery-Runbook durchspielen. Das ersetzt keinen echten Restore, verhindert aber viele klassische Notfallprobleme.

Für kritische Standorte sollte zusätzlich klar sein, wie die Firewall nach einem Reimage oder Hardwaretausch wieder erreichbar wird: lokaler Zugriff, Management-Port, WAN-Daten, Lizenzstatus, Sophos Central-Zuordnung und Ansprechpartner vor Ort. Diese Informationen gehören nicht nur in das Backup, sondern in eine separate Betriebsdokumentation.

Backup wiederherstellen

Der Restore erfolgt ebenfalls unter:

Backup & Firmware > Backup & Restore

Grundablauf:

1. Ziel-Firewall über WebAdmin erreichen.
2. Aktuellen Zustand sichern, falls noch möglich.
3. Im Bereich Restore configuration über Choose file die Backup-Datei auswählen.
4. Falls erforderlich Encryption password oder SSMK eingeben.
5. Upload and Restore starten.
6. Neustart und Wiederherstellung abwarten.
7. WebAdmin über die Management-IP aus der wiederhergestellten Konfiguration öffnen.
8. Zeitzone, NTP und aktuelle Uhrzeit prüfen.
9. Danach Netzwerk, Dienste, VPN, HA und Central-Anbindung prüfen.

Beim Restore ersetzt die eingespielte Konfiguration die aktuelle Konfiguration, löscht das lokal gespeicherte Backup auf der Firewall und startet die Firewall neu. Deshalb sollte das verwendete Backup vor dem Restore extern verfügbar bleiben. Wenn die einzige Kopie auf der Ziel-Firewall liegt, ist der Recovery-Prozess unnötig fragil.

Wenn eine neue oder ersetzte Sophos Firewall bereitgestellt wird, kann das Backup nach dem Erstzugriff auf die Appliance eingespielt werden. Die initiale IP-Adresse und der Erstzugriff hängen vom jeweiligen Modell und Deployment-Typ ab. Bei Hardware-Appliances ist der lokale Erstzugriff über die Standard-Management-IP oder den Einrichtungswizard üblich.

Sobald die Firewall erreichbar ist und der Einrichtungswizard abgeschlossen wurde, kann der Restore wie oben beschrieben durchgeführt werden.

Restore auf andere Hardware oder andere Plattformen

Gerade bei Migrationen zwischen XG und XGS oder zwischen Hardware, virtueller Appliance und Cloud sollte vor dem Restore geprüft werden, ob das Backup kompatibel ist. Sophos bietet dafür einen öffentlichen Backup-restore compatibility check an.

Zusätzlich muss die Zielversion passen. Sophos unterscheidet zwischen freigegebenen Upgrade- und Backup-Restore-Pfaden und nicht freigegebenen Migrationen. Wenn eine Firewall vor dem Neustart warnt, dass die geplante Migration nicht unterstützt ist, sollte man nicht einfach bestätigen. Nach einer bestätigten, nicht freigegebenen Migration kann die Firewall mit Factory-Konfiguration starten, wodurch die aktuelle Konfiguration verloren geht.

Für einen produktiven Restore heisst das:

• zuerst Quellversion, Zielversion, Zielmodell und Plattform notieren
• Ziel-Firewall vor dem Restore auf eine unterstützte SFOS-Version bringen
• Backup-restore compatibility check für die konkrete Kombination ausführen
• Warnungen im Restore- oder Upgrade-Dialog ernst nehmen und dokumentieren
• bei Unsicherheit zuerst auf Ersatzhardware oder in einer Testumgebung prüfen

Backup-Restore Assistant und automatisches Interface-Mapping

Ob der Backup-Restore Assistant erscheint, hängt von konkreten Versions- und Plattformbedingungen ab, nicht nur vom “neueren” Backup:

• Das Backup stammt von einer Appliance (XG, SG mit SFOS, XGS, virtuell oder Cloud), die SFOS 19.5 MR4 oder neuer verwendet hat.
• Der Restore erfolgt auf SFOS 20.0 MR2 oder neuer.
• Der Restore erfolgt auf eine XGS-Serie, eine virtuelle oder eine Cloud-Appliance.
• Bei einem Restore auf XG- oder SG-Serie erscheint der Assistant nicht.

Der Assistant hilft beim Zuordnen von Interfaces, wenn ein Backup von XG, SG mit SFOS oder XGS auf eine XGS-Serie, virtuelle Appliance oder Cloud-Firewall wiederhergestellt wird. Das ist besonders wichtig, wenn die Ziel-Firewall weniger Ports, andere Portnamen, Wireless-Varianten oder Flexi-Port-Module hat.

Bei Backups aus SFOS 19.5 MR3 oder älter sowie bei jedem Restore auf XG/SG fehlt der Assistant. Dann ordnet die Firewall Interfaces automatisch zu. Das ist schneller, aber riskanter, weil man die Zuordnung nicht bewusst im Assistenten bestätigt. Nach einem solchen Restore müssen Interfaces, Zonen, Gateways, VLANs, HA-Link, SD-WAN-Routen, NAT-Regeln und VPNs besonders sorgfältig geprüft werden.

Die wichtigsten Sonderfälle beim Interface-Mapping im Überblick:

Pseudo-Ports sind ein Hinweis, dass eine fachliche Portentscheidung offen ist. Nach dem Restore sollte man sie prüfen, auf einen aktiven Port umziehen oder sauber entfernen. Zum Entfernen öffnet man den Pseudo-Port unter Network > Interfaces, setzt die Zone auf None und startet die Firewall neu. Ungebundene Pseudo-Ports mit VLAN-Konfiguration werden dabei nicht automatisch gelöscht und brauchen zusätzliche Bereinigung.

Weitere Punkte, die nach dem Restore zu klären sind:

• Stimmen die verfügbaren Ports und Zonentypen mit der Zielplattform überein?
• Müssen Interfaces nach dem Restore neu zugeordnet werden?
• Wird ein HA-Backup auf eine Einzelappliance oder umgekehrt wiederhergestellt?
• Ist das Zielsystem firmwareseitig auf einem sinnvollen Stand?
• Muss eine alte XG- oder SG-Appliance wegen Lifecycle oder SFOS-22-Kompatibilität ersetzt werden?
• Sind Lizenzstatus, Seriennummer und Sophos Central-Zuordnung nach dem Restore geklärt?

Wenn die Portbelegung abweicht, muss man nach dem Restore meist ein Interface-Mapping prüfen oder nacharbeiten. Vor XG-zu-XGS-Migrationen ist auch der Artikel Was ist der Unterschied zwischen einer XG und XGS Firewall? relevant.

Nach grösseren Restore- oder Migrationsarbeiten kann ein Vergleich der Konfigurationen helfen. Sophos Firewall Config Studio nutzen zeigt, wie man Backups vor und nach einem Change vergleicht und unerwartete Unterschiede gezielt prüft.

Cloud- und virtuelle Firewalls

Bei virtuellen oder Cloud-Firewalls sollte man nicht nur auf Hypervisor-, Snapshot- oder Cloud-Provider-Backups vertrauen. Sophos unterstützt für Firewall-Konfigurationsbackups den integrierten Backup-and-Restore-Mechanismus der Firewall. Plattform-Backups können als zusätzlicher Infrastruktur-Schutz nützlich sein, ersetzen aber nicht das unterstützte Konfigurationsbackup.

In der Praxis heisst das: VM-Snapshot, Cloud-Image oder Marketplace-Mechanismus können beim Wiederherstellen der Instanz helfen. Für eine saubere SFOS-Konfiguration, Migration oder Supportanalyse braucht es trotzdem ein gültiges Sophos-Firewall-Backup mit passendem SSMK, Backup-Passwort, Zielversion und dokumentiertem Interface-Mapping.

Nach dem Restore prüfen

Nach dem Restore sollte nicht nur kontrolliert werden, ob der WebAdmin erreichbar ist. Die Firewall kann erreichbar sein und trotzdem wichtige Dienste falsch verarbeiten.

Direkt nach dem Restore prüfen:

• WebAdmin-IP, erlaubte Management-Netze und Device Access.
• Interfaces, Zonen, VLANs, Bridges, LAGs und Alias-Interfaces.
• WAN-Uplinks, PPPoE, statische Providerdaten und Default Gateway.
• SD-WAN-Routen, statische Routen und dynamisches Routing.
• Firewall-Regeln, NAT-Regeln, WAF-Regeln und Rule-Reihenfolge.
• IPsec, SSL VPN, Sophos Connect, RED und Remote Access.
• Zertifikate, CA-Zertifikate, WebAdmin-Zertifikat und TLS Inspection.
• DNS, DHCP, NTP, Zeitzone und Authentication Server.
• HA-Status, wenn ein Cluster verwendet wird.
• Lizenzstatus, Pattern Updates, Hotfixes und Sophos Central Synchronisation.
• Logging, Syslog-Ziele, Central Firewall Reporting und lokale Reports.

Für die technische Prüfung helfen je nach Problem Log Viewer, Policy Test und Packet Capture, Packet Capture im WebAdmin und Services und Logs.

Abnahmetest nach einem Restore

Ein Restore ist erst abgeschlossen, wenn die wichtigsten Betriebsfunktionen mit echten Tests bestätigt wurden. Ein erreichbarer WebAdmin beweist nur, dass die Firewall bedienbar ist. Er beweist nicht, dass Routing, NAT, VPN, WAF, Authentifizierung oder Logging wieder korrekt funktionieren.

Für produktive Firewalls sollte es deshalb eine kurze Abnahmematrix geben. Diese Matrix muss nicht kompliziert sein, sollte aber pro Standort festlegen, welcher Test nach einem Restore zwingend durchgeführt wird und wer das Ergebnis dokumentiert.

Sinnvolle Pflichttests sind:

• Management: WebAdmin aus dem Management-Netz öffnen und zweiten Adminzugang testen. Erwartet wird, dass Zugriff nur aus erlaubten Netzen funktioniert.
• Internetzugang: Testclient in LAN oder Client-VLAN ruft definierte externe Ziele auf. Richtige Firewall-Regel, NAT-Regel und WAN-Route müssen greifen.
• DNS und DHCP: Client erhält Adresse und löst interne sowie externe Namen auf. DHCP-Bereich, DNS-Server und DNS Request Routes müssen passen.
• Site-to-Site VPN: Ein definierter Host pro Standort wird in beide Richtungen erreicht. Tunnel, Routing und Firewall-Regel müssen matchen.
• Remote Access: Testbenutzer baut SSL VPN, IPsec oder Sophos Connect auf. Login, MFA, Profil, DNS und interne Ziele müssen funktionieren.
• WAF oder DNAT: Veröffentlichter Dienst wird von extern getestet. Zertifikat, Regel, Backend und Logging müssen passen.
• Authentifizierung: AD, LDAP, RADIUS, STAS oder Entra SSO mit Testbenutzer prüfen. Der Benutzer sollte erkannt werden und die erwartete Regel treffen.
• Logging: Log Viewer, Syslog, Central Reporting oder SIEM kontrollieren. Restore und Testtraffic sollten nachvollziehbar sichtbar sein.
• HA: Clusterstatus, Rollen und Synchronisation prüfen. Primary und Auxiliary sollten im erwarteten Zustand sein.

Wichtig ist ein definierter Abbruchpunkt. Wenn nach einem Restore grundlegende Tests wie WAN, DNS, Remote Access oder HA nicht funktionieren, sollte nicht parallel an vielen Stellen korrigiert werden. Besser ist ein enger Fehlerfall mit Uhrzeit, Testquelle, Ziel, betroffener Regel und Logauszug. So bleibt nachvollziehbar, ob das Problem aus dem Backup, dem Interface-Mapping, der Zielhardware oder einer nachträglichen Änderung stammt.

Typische Fehler

• Backup liegt nur lokal auf der Firewall: Bei Hardwaredefekt oder Reimage ist es nicht erreichbar. Backups sollten extern und geschützt abgelegt werden.
• SSMK nicht dokumentiert: Restore geschützter Daten kann scheitern oder deutlich länger dauern. Der SSMK gehört in das Recovery-Verfahren.
• Alter SSMK nach Schlüsselwechsel nicht mehr auffindbar: Ältere Backups können nicht mehr entschlüsselt werden. Frühere SSMK-Versionen sollten mit Zeitraum und Firewallbezug dokumentiert bleiben.
• Backup ohne Versions- oder Gerätebezug: Die falsche Datei wird eingespielt. Firewallname, Seriennummer, SFOS-Version und Datum gehören zur Backup-Dokumentation.
• Kein Ist-Backup vor Restore: Der Rückweg zum aktuellen Zustand fehlt. Vor produktivem Restore sollte ein neues Backup erstellt werden.
• Wiederhergestellte WebAdmin-IP nicht bekannt: Nach dem Restore wirkt die Firewall offline, obwohl sie auf einer anderen IP läuft. Management-IP aus dem Backup und lokalen Zugriff vorab planen.
• Zeit und NTP nach Restore nicht geprüft: VPN, Zertifikate, Authentifizierung oder Central-Anbindung können sich fehlerhaft verhalten. Zeitzone, NTP und aktuelle Uhrzeit direkt nach dem Restore kontrollieren.
• Nicht freigegebener Restore-Pfad bestätigt: Die Firewall startet mit Factory-Konfiguration oder der Restore schlägt unklar fehl. Zielversion, Quellversion und Compatibility Check müssen vor dem Restore geprüft werden.
• Port-Mapping nicht geprüft: Interfaces landen nach Migration falsch. Compatibility Check und Interface-Mapping sollten vorbereitet werden.
• Automatisches Interface-Mapping ungeprüft übernommen: WAN, VLAN, VPN oder HA-Link liegen auf falschen Ports. Nach Restore jedes Interface mit Verkabelung und Zonenmodell abgleichen.
• HA-Kontext ignoriert: Der Cluster startet nicht sauber oder die falsche Rolle wird aktiv. HA-Rollen, Firmwarestand und Restore-Reihenfolge müssen geplant sein.
• Nur WebAdmin geprüft: VPN, NAT, WAF oder DNS-Probleme bleiben unentdeckt. Nach dem Restore braucht es echte Diensttests.

Betriebscheckliste

Regelmässig:

• Automatische Backups aktivieren oder zentralen Backup-Prozess definieren.
• Backup-Ablage, Zugriff und Aufbewahrung prüfen.
• SSMK und Backup-Passwort im Passwortmanager kontrollieren.
• Recovery-Paket pro Standort oder Firewall aktuell halten.
• Mindestens stichprobenweise prüfen, ob Backups auffindbar und zuordenbar sind.

Vor grösseren Änderungen:

• Manuelles Backup erstellen und extern speichern.
• Firewallname, Seriennummer, SFOS-Version und Change-Zweck dokumentieren.
• SSMK, Backup-Passwort und Adminzugang prüfen.
• Rollback- oder Restore-Plan festlegen.
• Bei Migrationen Compatibility Check und Interface-Mapping prüfen.
• Warnungen zu nicht unterstützten Restore- oder Migrationspfaden nicht bestätigen, bevor ein alternativer Plan vorliegt.

Nach einem Restore:

• WebAdmin-IP, Management-Netze und Device Access kontrollieren.
• Interfaces, Routing, NAT, VPN, WAF, Authentifizierung und Central testen.
• Zeitzone, NTP und aktuelle Uhrzeit prüfen.
• Abnahmematrix mit echten Testquellen, Testzielen und erwarteten Logs abarbeiten.
• HA-Status und Rollen kontrollieren.
• Logs und Monitoring prüfen.
• Bei Zielversionen ab SFOS 22.0 MR1 erneut prüfen, ob ein Restore oder Import alte Legacy Remote Access IPsec-Konfigurationen zurückgebracht hat.
• Neues Backup des wiederhergestellten Zielzustands erstellen.
• Abweichungen dokumentieren und bei Bedarf mit Config Studio vergleichen.

FAQ