Sophos Firewall Utwórz lub przywróć kopię zapasową

Kopia zapasowa Sophos Firewall jest podstawą aktualizacji firmware, wymiany sprzętu, reimage, prac związanych z HA i migracji. Sam plik jednak nie wystarczy: niezawodne przywracanie wymaga także hasła kopii zapasowej, właściwego Secure Storage Master Key (SSMK), zgodnej wersji docelowej i działającego dostępu administracyjnego.

⚠️ Ważne: Przed ryzykowną zmianą plik kopii zapasowej, hasło, SSMK, wersja docelowa, adres IP zarządzania i ścieżka przywracania muszą być dostępne i zweryfikowane. Kopia przechowywana wyłącznie na firewallu lub pozbawiona klucza nie jest niezawodnym sposobem powrotu.

Ścieżka odzyskiwania i wymagania

Wybór właściwej ścieżki odzyskiwania

Przywracanie nie jest właściwym pierwszym działaniem w przypadku każdego problemu:

• Planowanie aktualizacji firmware: Aktualizacja firmware Sophos Firewall: przygotowanie i dobre praktyki.
• Instalacja firmware w WebAdmin: Przeprowadzanie aktualizacji firmware Sophos Firewall.
• Zablokowane zadanie Central: Sprawdzanie kolejki zadań Sophos Central Firewall Management.
• Pełna ponowna instalacja SFOS: Ponowna instalacja Sophos Firewall OS za pomocą pamięci USB.
• Awaria sprzętu lub RMA: Otwieranie zgłoszenia do pomocy technicznej Sophos.
• Przywracanie klastra HA: Warianty klastra HA Sophos Firewall.

Przed reimage prawie zawsze potrzebna jest kopia do przywrócenia. Rollback firmware nie zastępuje jednak kopii zapasowej, ponieważ slot firmware i zapisany stan konfiguracji to dwie odrębne ścieżki odzyskiwania.

Hasło kopii zapasowej i Secure Storage Master Key

Aktualne kopie zapasowe Sophos Firewall są szyfrowane hasłem. Jeżeli kopię utworzono po skonfigurowaniu SSMK, przywracanie wymaga hasła kopii zapasowej oraz SSMK obowiązującego w chwili jej utworzenia.

SSMK chroni informacje poufne, takie jak hasła, secrets i klucze. Konfiguruje go domyślne konto admin; klucz należy przechowywać w menedżerze haseł lub innym zabezpieczonym procesie odzyskiwania. Co najmniej dwie upoważnione osoby powinny wiedzieć, gdzie się znajduje.

Po późniejszej zmianie SSMK starsze kopie pozostają powiązane z poprzednim kluczem. Dlatego należy zachować bieżące i wcześniejsze wersje SSMK wraz z okresem ich obowiązywania i przypisaniem do firewalla.

Legacy backups bez SSMK można przywrócić bez master key. Po przywróceniu zaplanowanej kopii bez SSMK zapisany harmonogram nadal działa, lecz częstotliwość można zmienić dopiero po skonfigurowaniu SSMK. Następnie należy natychmiast utworzyć nową kopię ręczną.

Pakiet odzyskiwania dla każdego firewalla

Dla każdej lokalizacji lub tenant oprócz kopii zapasowej powinien istnieć zabezpieczony pakiet odzyskiwania:

• ostatnia zweryfikowana kopia z datą i przeznaczeniem
• hasło kopii oraz bieżące i wcześniejsze SSMK
• nazwa firewalla, numer seryjny, model i wersja SFOS
• dane dostępowe WAN, informacje o dostawcy i default gateway
• przypisanie interfejsów, VLAN, LAG, bridge i portów HA
• lokalny dostęp administracyjny i break-glass
• przypisanie licencji i Sophos Central
• krytyczne usługi z konkretnymi testami akceptacyjnymi

Nie należy przechowywać kopii i danych dostępowych razem bez zabezpieczenia. Pakiet trzeba aktualizować po zmianach personelu, dostawcy, portów, HA lub lokalizacji.

Bezpieczne tworzenie i obsługa kopii zapasowych

Ręczna kopia przed zmianami

Backup & Firmware > Backup & Restore

Opcja Backup Now tworzy kopię natychmiast. Następnie plik należy zapisać zewnętrznie i udokumentować co najmniej nazwę firewalla, numer seryjny, wersję SFOS, datę i cel zmiany.

Ręczna kopia jest szczególnie ważna przed:

• zmianami firmware, interfejsów, VLAN, routingu, SD-WAN lub VPN
• konfiguracją HA, zmianą ról lub konserwacją klastra
• dużymi zmianami reguł NAT, WAF lub firewalla
• reimage, factory reset, wymianą sprzętu lub migracją platformy

Przy większych zmianach Sophos Firewall Config Studio może dodatkowo pokazać różnice w konfiguracji. Porównanie Entities.xml nie zastępuje jednak kopii do przywrócenia.

Jeśli trzeba przenieść lub zmienić tylko jasno wydzieloną część konfiguracji, selektywny eksport i import konfiguracji opisuje osobną procedurę WebAdmin. Również ten import nie zastępuje pełnej ścieżki odzyskiwania.

Automatyczne kopie zapasowe

W sekcji Frequency można skonfigurować kopie dzienne, tygodniowe lub miesięczne. W zależności od konfiguracji dostępne są zapis lokalny, FTP i e-mail.

Ważne zasady operacyjne:

• Lokalna kopia nie pomoże, gdy appliance ulegnie awarii lub zostanie ponownie zainstalowane.
• Na firewallu pozostaje tylko ostatnia lokalna kopia; potrzebne starsze wersje trzeba zapisać zewnętrznie.
• Kopie FTP i e-mail można uznać za działające dopiero po rzeczywistym teście dostarczenia, pobrania i odszyfrowania.
• Nie należy stosować znaków specjalnych w Backup prefix, nazwie użytkownika FTP lub haśle bez wcześniejszego testu.
• Kopie automatyczne nie zastępują świeżej kopii ręcznej wykonanej bezpośrednio przed ryzykowną zmianą.
• Okres przechowywania, dostęp i proces usuwania muszą odpowiadać wymaganiom ochrony konfiguracji.

Kopie firewalla zawierają poufne informacje o sieciach, regułach, VPN, certyfikatach i kontach. Dostęp powinien być ograniczony do administratorów i osób odpowiedzialnych za odzyskiwanie; hasło i SSMK pozostają oddzielone, ale muszą być możliwe do odnalezienia w sytuacji awaryjnej.

Kopie zapasowe Sophos Central

Sophos dokumentuje obecnie dwie ścieżki nawigacji w Central, zależnie od widoku i strony pomocy:

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

Firewall musi być połączony z Sophos Central i dopuszczony do tworzenia kopii konfiguracji. Artykuł Łączenie Sophos Firewall z Sophos Central opisuje konfigurację połączenia.

Harmonogram należy zawsze sprawdzić bezpośrednio, a nie zakładać wartość domyślną. Gdy pierwszy firewall zostanie automatycznie dodany do pustego harmonogramu ustawionego na Never, Central może jednorazowo zmienić go na Monthly i pierwszy dzień miesiąca. Istniejące harmonogramy nie są zmieniane.

Pozostałe stałe właściwości:

• Kopie są wykonywane o 08:00 w strefie czasowej regionu Central; godziny nie można zmienić.
• Central podejmuje do pięciu prób utworzenia kopii, a następnie generuje alert i wiadomość e-mail do administratora.
• Zachowywanych jest pięć najnowszych kopii; dokładnie jedną dodatkową można przechowywać bezterminowo.
• Podczas pobierania kopia jest ponownie szyfrowana nowo nadanym hasłem.
• Usunięcie firewalla z Central Management usuwa jego kopie w Central. Wymagane pliki należy pobrać przed zmianą konta, RMA lub porządkowaniem tenant.
• W HA Primary i Auxiliary są dodawane do harmonogramu, lecz kopię tworzy Primary.

Jeżeli zarejestrowany firewall nie pojawia się w harmonogramie, należy dodać go w Schedule Backup. Jeśli opcja Send configuration backup to Sophos Central jest już aktywna, trzeba wyczyścić pole wyboru, zastosować zmianę, ponownie je zaznaczyć, znów zastosować i następnie zaakceptować oczekującą zgodę na usługę w Central.

Central jest dobrym dodatkowym miejscem przechowywania, ale nie zastępuje SSMK, dostępu lokalnego, danych WAN i niezależnie dostępnej kopii zapasowej.

Przygotowanie i wykonanie przywracania

Przygotowanie i bezpieczny test przywracania

Przed przywracaniem należy potwierdzić:

• dostępność właściwego pliku kopii, hasła i ówczesnego SSMK
• zgodność wersji źródłowej, wersji docelowej, modelu i platformy
• zewnętrzne zapisanie kopii bieżącej konfiguracji
• znajomość adresu IP zarządzania z kopii i lokalnego dostępu
• udokumentowanie danych WAN, NTP, DNS, licencji i Central
• ustalenie celu HA i kolejności przywracania
• przygotowanie mapowania interfejsów i odmiennych przypisań portów

⚠️ Uwaga: Przywracanie nadpisuje bieżącą konfigurację i restartuje firewall. Ostrzeżenia o nieobsługiwanej ścieżce migracji nie wolno rutynowo potwierdzać; firewall może następnie uruchomić się z factory configuration.

Rzeczywisty test przywracania należy wykonywać na odpowiednim firewallu laboratoryjnym lub zastępczym. Przed testem trzeba wyłączyć lub odizolować produkcyjne połączenia WAN, VPN i Central, aby uniknąć konfliktów adresów, tuneli lub podwójnych rejestracji.

Bez urządzenia testowego można wykonać przynajmniej test organizacyjny: pobrać kopię z przewidzianego miejsca, sprawdzić jej przypisanie, potwierdzić hasło i SSMK, ocenić platformę docelową oraz przejść w runbook przez dostęp administracyjny i testy akceptacyjne. Nie zastępuje to prawdziwego przywracania, lecz eliminuje wiele typowych problemów awaryjnych.

Przywracanie kopii zapasowej

Backup & Firmware > Backup & Restore

1. Otwórz docelowy firewall przez WebAdmin.
2. Jeśli to nadal możliwe, zapisz bieżący stan.
3. W sekcji Restore configuration wybierz plik kopii za pomocą Choose file.
4. Wprowadź Encryption password, a dla kopii chronionej SSMK również SSMK obowiązujący w chwili jej utworzenia.
5. Uruchom Upload and Restore.
6. Poczekaj na restart i zakończenie przywracania.
7. Otwórz WebAdmin pod adresem IP zarządzania zapisanym w kopii.
8. Sprawdź strefę czasową, NTP i aktualny czas.
9. Zweryfikuj sieć, usługi, VPN, HA i połączenie z Central.

Przywracanie usuwa kopię przechowywaną lokalnie na docelowym firewallu. Używany plik musi zatem pozostać dostępny zewnętrznie. Na nowym appliance najpierw należy ukończyć setup wizard, a następnie przywrócić kopię.

Czego przywracanie nie rozwiązuje automatycznie

• Hasło domyślnego konta admin nie jest przywracane z kopii; docelowy firewall zachowuje istniejące hasło. Jeśli zostało utracone, na fizycznym urządzeniu resetuje się je oddzielnie przez konsolę szeregową. Dla firewalli wirtualnych i cloud trzeba sprawdzić konsolę platformy oraz obsługiwaną ścieżkę odzyskiwania.
• Po restarcie adres IP zarządzania, Device Access, trasy i usługi ponownie pochodzą z kopii.
• Strefę czasową, NTP i czas trzeba sprawdzić jako bieżący stan operacyjny.
• Wartości zależne od modelu lub instance mogą wrócić do defaults, jeśli nie pasują do celu.
• Sophos Central pozostaje zarejestrowany tylko przy przywracaniu na ten sam firewall. Inny firewall lub klaster HA trzeba zarejestrować ponownie, a następnie sprawdzić Security Heartbeat, ZTNA, Central Management, Backup, Reporting, Task Queue i przypisanie do grupy.
• Logs, reports i dane zewnętrznego monitoringu nie są częścią pełnego rollback konfiguracji.

Podczas migracji do trybu FIPS 140-3 decydujący jest również stan backupu: Backup z wyłączonym FIPS przywraca stan bez FIPS, dlatego stanowi drogę powrotu, a nie niezmienione przeniesienie do trybu FIPS.

Przywracanie na inny sprzęt i platformy

Zgodność i wersje SFOS

Przed migracją należy zanotować wersję źródłową, wersję docelową, model docelowy i platformę. Backup-restore compatibility check jest teraz częścią Sophos Firewall Config Studio. Należy tam otworzyć Backup-restore compatibility i sprawdzić zgodność modeli XG/XGS oraz używanych modułów Flexi Port i transceiverów. Narzędzie dotyczy SFOS 20.0 MR2 i nowszych wersji; dodatkowo trzeba uwzględnić informacje o aktualizacji w bieżących release notes i artykule SFOS 22 Upgrade Check.

W przypadku SFOS 22 obowiązują twarde ograniczenia:

• SFOS 22.0 GA i nowsze wersje nie obsługują sprzętu XG ani SG.
• Kopii zawierających legacy CLI VLAN tagging na interfejsach bridge nie można przywrócić do SFOS 22.0 GA ani nowszych wersji. Sposób oczyszczenia opisano w Sprawdzanie Bridge VLAN przed SFOS 22.
• Legacy Remote Access IPsec blokuje aktualizację do SFOS 22.0 MR1 i nowszych wersji. Przywracanie lub import do tych wersji nie migruje starej konfiguracji; wcześniej należy przejść na obsługiwaną metodę. Zobacz Migracja Legacy Remote Access IPsec.

Backup-Restore Assistant i mapowanie interfejsów

Assistant pojawia się tylko wtedy, gdy spełnione są wszystkie warunki:

• Kopia pochodzi z XG, SG z SFOS, XGS, virtual lub cloud z SFOS 19.5 MR4 albo nowszym.
• Urządzenie docelowe działa z SFOS 20.0 MR2 lub nowszym.
• Urządzenie docelowe to appliance XGS, virtual lub cloud.

Assistant nie pojawia się na urządzeniach docelowych XG lub SG ani przy kopiach z SFOS 19.5 MR3 lub starszego. Firewall wykonuje wtedy mapowanie automatyczne; po przywróceniu trzeba szczególnie dokładnie sprawdzić interfejsy, strefy, gateways, VLAN, HA link, SD-WAN, NAT i VPN.

Assistant może być również użyty na tym samym zgodnym appliance do przeniesienia VLAN lub konfiguracji interfejsów na inny port fizyczny.

Interfejsy fizyczne i logiczne

• Port fizyczny: świadomie przypisz do portu docelowego albo pozostaw bez mapowania; sprawdź okablowanie, strefę i funkcję WAN/LAN.
• VLAN lub alias: podąża za zmapowanym parent interface; port nadrzędny musi być operacyjnie właściwy.
• LAG lub bridge: jest tworzony ponownie ze zmapowanych portów fizycznych; sprawdź liczbę members i konfigurację switcha.
• RED lub Cellular: powiązana konfiguracja jest migrowana; po przywróceniu wykonaj ukierunkowany test połączenia.

Pseudo ports, breakout, management i HA

• Pseudo port: zachowuje konfigurację, ale nie obsługuje ruchu. Przenieś routing, NAT, VLAN i reguły na aktywny port.
• Breakout root port: mapować można tylko root ports, nie pojedyncze members. Cel wymaga obsługiwanej liczby i kombinacji portów.
• Management port: jest mapowany na dostępny management port albo zachowywany jako pseudo port. Wcześniej zaplanuj sieć zarządzającą i dostęp lokalny.
• Dedicated HA link: typ portu musi pozostać taki sam; Assistant nie może zmienić portu HA link. Dla LAG liczba members musi być zgodna, dla VLAN identyfikator VLAN ID, a dla monitored ports status docelowy.

Przed usunięciem pseudo port należy przenieść wszystkie zależne trasy oraz konfiguracje NAT, firewalla i VLAN. Następnie w Network > Interfaces ustawić strefę na None i zrestartować firewall w oknie serwisowym. Potem trzeba sprawdzić, czy port został usunięty; niepowiązane pseudo ports z konfiguracją VLAN nie są usuwane automatycznie.

Backup-Restore Assistant ponownie przypisuje interfejsy, ale nie zapewnia zgodności konfiguracji Wireless ani interfejsu bridge, których urządzenie docelowe nie obsługuje. Takie zależności trzeba uporządkować lub skorygować w urządzeniu źródłowym przed utworzeniem kopii migracyjnej albo zaplanować je od nowa dla urządzenia docelowego.

Cele HA, Wireless, virtual i cloud

Aby zachować konfigurację HA, kopię HA można przywrócić wyłącznie do klastra HA. Można najpierw skonfigurować nowy klaster i przywrócić kopię na Primary albo najpierw przywrócić, a potem skonfigurować HA. Następnie trzeba sprawdzić role, wersję firmware, Dedicated HA link i monitored ports.

Migracje Wireless mają dodatkowe ograniczenia:

• W przypadku Wireless-to-Non-Wireless przed utworzeniem kopii należy usunąć Wireless Networks.
• Kopii z modeli Gen.2 XGS Wireless nie można przywrócić na modele XG ani Gen.1 XGS Wireless.
• Przy przejściu ze starszych modeli Wireless na Gen.2 XGS obowiązują dodatkowe ograniczenia dotyczące SSID, WPA, bridge mode i radio bands.

Konfiguracje LocalWiFi i bridge podczas migracji

Przy przywracaniu kopii z XG Wireless lub Gen.1 XGS Wireless na model Gen.2 XGS W obowiązują następujące warunki i ograniczenia:

• Do LocalWiFi0 i LocalWiFi1 są przypisane wyłącznie SSID z zabezpieczeniem co najmniej WPA2.
• Szyfrowanie nie używa ani TKIP, ani TKIP/AES.
• Żaden interfejs Wireless nie jest członkiem fizycznego interfejsu bridge.
• LocalWiFi0 i LocalWiFi1 używają łącznie maksymalnie ośmiu unikatowych SSID.
• Jeśli oba moduły radiowe używają tego samego pasma częstotliwości, przywracane są tylko ustawienia LocalWiFi0.

Kluczowa jest tu różnica w sposobie tworzenia interfejsu bridge. W przypadku Wireless Network typu Bridge to AP LAN modele Gen.1 XGS 87w, 107w, 116w, 126w i 136w łączą lokalną sieć WLAN z LAN przez fizyczny interfejs bridge. Modele Gen.2 XGS 88w, 108w, 118w i 128w nie obsługują takiej konstrukcji; używa się w nich opcji Bridge to Ethernet w Wireless > Access points > LocalWiFi > Advanced settings z dokładnie jednym portem Ethernet i strefą LAN. Konfigurację w Gen.2 opisuje artykuł Konfiguracja WLAN bezpośrednio w Sophos Firewall.

Jeśli kopia Gen.1 nadal zawiera fizyczny interfejs bridge z interfejsem Wireless Network typu Bridge to AP LAN, przywracanie na Gen.2 kończy się niepowodzeniem. Sophos wymienia to zachowanie jako Known Issue NC-135094. Jeśli którakolwiek z konfiguracji OSPF, OSPFv3, RIP, SPX Portal Setting lub Quarantine odwołuje się do tego interfejsu, przywracanie zostaje ukończone, ale zależna konfiguracja nie działa w Gen.2.

Przed utworzeniem kopii migracyjnej należy więc sprawdzić w Network > Interfaces, czy interfejs Wireless należy do interfejsu bridge, i udokumentować wszystkie zależne ustawienia. Produkcyjnego interfejsu bridge nie należy usuwać bez przygotowania: najpierw w oknie serwisowym trzeba przenieść adres IP, strefę, DHCP, podłączone porty i zależności routingu do projektu zgodnego z Gen.2. Następnie należy utworzyć nową kopię. Na urządzeniu docelowym trzeba ponownie skonfigurować Bridge to Ethernet, a potem dokładnie przetestować SSID, tryb zabezpieczeń, pasma częstotliwości, DHCP oraz wcześniej zależne usługi.

Przed migracją z XG do XGS pomocne jest również porównanie XG i XGS.

W przypadku firewalls virtual i cloud zintegrowany proces Sophos backup-and-restore jest jedyną obsługiwaną ścieżką odzyskiwania SFOS. Sophos nie obsługuje w tym celu snapshots hypervisora, cloud images ani kopii innych producentów; mogą one powodować problemy z integralnością danych lub nieobsługiwane konfiguracje.

Walidacja po przywróceniu

Kontrola techniczna

Bezpośrednio po przywróceniu należy sprawdzić:

• adres IP WebAdmin, dozwolone sieci zarządzające i Device Access
• interfejsy, strefy, VLAN, bridges, LAG i alias interfaces
• WAN, PPPoE, default gateway, trasy statyczne i SD-WAN
• reguły firewalla, NAT i WAF wraz z kolejnością
• IPsec, SSL VPN, Sophos Connect, RED i Remote Access
• certyfikaty, TLS Inspection, DNS, DHCP, NTP i Authentication Server
• status HA, role i synchronizację
• status licencji, Pattern Updates, Hotfixes i synchronizację Central
• Log Viewer, Syslog, Central Reporting i reporting lokalny

W zależności od problemu pomocne są Log Viewer, Policy Test i Packet Capture, Packet Capture w WebAdmin oraz przegląd Services i Logs. Sophos nie wskazuje wiarygodnej uniwersalnej ścieżki logów SSH dla ogólnych błędów przywracania, dlatego nie podano tu polecenia shell.

Testy akceptacyjne

Dostępny WebAdmin nie dowodzi, że ruch produkcyjny działa. Dla każdej lokalizacji należy udokumentować konkretną source, target, oczekiwaną regułę i oczekiwany wpis logu dla następujących testów:

• Zarządzanie: dostęp z sieci zarządzającej i logowanie drugiego administratora.
• Internet: klient testowy osiąga określony zewnętrzny cel przez właściwą regułę, NAT i trasę WAN.
• DNS i DHCP: klient otrzymuje adres i rozwiązuje nazwy wewnętrzne oraz zewnętrzne.
• Site-to-Site VPN: określone hosts są osiągalne w obu kierunkach.
• Remote Access: użytkownik testowy sprawdza login, MFA, profil, DNS i cel wewnętrzny.
• WAF lub DNAT: test zewnętrzny potwierdza certyfikat, regułę, backend i logging.
• Uwierzytelnianie: AD, LDAP, RADIUS, STAS lub Entra SSO prawidłowo identyfikuje użytkownika testowego.
• Logging: ruch testowy jest widoczny w Log Viewer, Syslog, Central Reporting lub SIEM.
• HA: role, status klastra i synchronizacja są zgodne z planem.

Jeżeli WAN, DNS, Remote Access lub HA nie działa, nie należy zmieniać wielu obszarów jednocześnie. Trzeba zawęzić problem według czasu, źródła testowego, celu, reguły i fragmentu logu, a po każdej poprawce wykonać ponowny test.

Troubleshooting i eksploatacja

Typowe błędy

• Kopia istnieje tylko na firewallu: po awarii lub reimage jest niedostępna; należy przechowywać ją zewnętrznie i bezpiecznie.
• Brakuje SSMK: chronionych danych nie można przywrócić; należy udokumentować bieżące i wcześniejsze klucze.
• Plik bez odniesienia do urządzenia lub wersji: wybierana jest niewłaściwa kopia; należy zapisać nazwę firewalla, numer seryjny, wersję i datę.
• Brak kopii bieżącego stanu przed przywracaniem: nie ma drogi powrotu do poprzedniego stanu.
• Nieznany przywrócony adres IP zarządzania: firewall wydaje się offline; adres i dostęp lokalny należy udokumentować wcześniej.
• Nieprawidłowy czas lub NTP: VPN, certyfikaty, uwierzytelnianie i Central mogą przestać działać.
• Potwierdzona nieobsługiwana ścieżka przywracania: przywracanie nie powiedzie się albo cel uruchomi się z factory configuration.
• Niesprawdzone mapowanie interfejsów: WAN, VLAN, VPN lub HA link trafia na niewłaściwe porty.
• Zignorowane ograniczenia Wireless: kopia jest niezgodna albo konfiguracja bezprzewodowa nie działa zgodnie z oczekiwaniem.
• Zignorowany kontekst HA: konfiguracja klastra lub role zostają utracone albo uruchamiają się nieprawidłowo.
• Central jest jedyną kopią: usunięcie firewalla z Central kasuje te kopie.
• Sprawdzono tylko WebAdmin: awarie routingu, NAT, VPN, WAF, DNS lub logging pozostają niezauważone.

Rytm operacyjny

Regularnie:

• sprawdzać automatyczne kopie, dostarczanie, pobieranie i przechowywanie
• kontrolować miejsce przechowywania, uprawnienia oraz bieżące i wcześniejsze SSMK
• utrzymywać aktualny pakiet odzyskiwania i testy akceptacyjne
• okresowo sprawdzać plik, hasło, SSMK i zgodność celu

Przed większymi zmianami:

• utworzyć kopię ręczną, zapisać ją zewnętrznie i jednoznacznie oznaczyć
• określić dostęp administracyjny, ścieżkę przywracania i kryteria przerwania
• przy migracji sprawdzić zgodność, wersję SFOS i mapowanie interfejsów

Po przywróceniu:

• w pełni udokumentować kontrolę techniczną i testy akceptacyjne
• poprawić odchylenia i w razie potrzeby porównać z Config Studio
• utworzyć nową kopię zweryfikowanego stanu docelowego i zaktualizować pakiet odzyskiwania