Zum Inhalt springen
Avanet

Sophos Firewall Backup erstellen oder wiederherstellen

Sophos Firewall

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.

Das Video zeigt Backup und Restore auf der Sophos Firewall und ergänzt die praktischen Recovery-Hinweise im Artikel.

Recovery-Weg und Voraussetzungen

Passenden Recovery-Weg wählen

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

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.

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
Backup der SFOS Konfiguration erstellen
Sophos Firewall Backup & Restore: manuelles Backup erstellen und geplante Sicherungen konfigurieren

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

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.

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.
  • Sonderzeichen in Backup prefix, FTP-Benutzername oder Passwort nicht ungeprüft verwenden.
  • 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

  • Das Passwort des standardmässigen admin-Kontos wird nicht aus dem Backup übernommen; die Ziel-Firewall behält ihr vorhandenes Passwort.
  • Management-IP, Device Access, Routen und Dienste stammen nach dem Neustart wieder aus dem Backup.
  • Zeitzone, NTP und Uhrzeit müssen als aktueller Betriebszustand geprüft werden.
  • Modell- oder instanzabhängige Werte können auf Defaults zurückfallen, wenn sie auf dem Ziel nicht passen.
  • 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.

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.

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.
  • 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.

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.

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.

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.

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.

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