Awaria serwera Comarch ERP XL – awaria dysku, uszkodzenie bazy danych, złośliwe oprogramowanie – wymaga szybkiego i pewnego odtworzenia danych. Wcześniej przetestowana procedura odtwarzania to różnica między kilkugodzinną przerwą a wielodniowym chaosem.
Pierwsze minuty po awarii
Natychmiast po stwierdzeniu awarii: odizoluj uszkodzony serwer od sieci (zapobiega dalszemu uszkodzeniu danych lub rozprzestrzenieniu złośliwego oprogramowania), wykonaj diagnostykę sprzętu (S.M.A.R.T. dysków, logi sprzętowe serwera), oceń skalę uszkodzenia (czy baza SQL jest dostępna, czy system operacyjny startuje). Na podstawie diagnozy zdecyduj, czy próbować naprawy in-place (uszkodzenie partialne) czy odtwarzanie z backupu (awaria totalna).
Odtwarzanie z pełnego backupu
Przy awarii totalnej (uszkodzony dysk, zniszczony system) odtwarzanie przebiega: 1) instalacja systemu operacyjnego i SQL Server na nowym lub naprawionym sprzęcie, 2) przywrócenie backupu FULL (RESTORE DATABASE ... WITH NORECOVERY), 3) przywrócenie najnowszego backupu DIFF (WITH NORECOVERY), 4) przywrócenie kolejnych backupów LOG (WITH NORECOVERY) aż do ostatniego przed awarią, 5) finalizacja (RESTORE DATABASE ... WITH RECOVERY). Każdy krok musi być wykonany w prawidłowej kolejności chronologicznej.
Odtwarzanie z replikacji lub Always On
W środowiskach z SQL Server Always On Availability Groups lub replikacją SQL Server odtwarzanie po awarii może odbywać się przez przełączenie na replikę (failover). Replika przejmuje rolę serwera głównego w ciągu sekund (automatic failover) lub minut (manual failover). Dla środowisk produkcyjnych XL wymagających wysokiej dostępności Always On jest rekomendowaną architekturą, eliminującą downtime przy awarii węzła głównego.
Odtwarzanie danych bez backupu bazy
Jeśli brak jest backupu lub backup jest uszkodzony, istnieje możliwość odtworzenia części danych z uszkodzonej bazy przez narzędzia do odtwarzania danych SQL Server (ApexSQL Recover, SysTools SQL Recovery). Narzędzia te działają na poziomie stron bazy danych i mogą odczytać dane ze stron, które SQL Server uznał za uszkodzone. Skuteczność zależy od stopnia uszkodzenia – nie jest to metoda niezawodna i nie zastępuje backupu, ale jest opcją ostatniej szansy.
Plan ciągłości działania (BCP)
Każda instalacja Comarch ERP XL w środowisku produkcyjnym powinna mieć dokumentowany Plan Ciągłości Działania (BCP – Business Continuity Plan). BCP definiuje: RTO (Recovery Time Objective – maksymalny dopuszczalny czas naprawy), RPO (Recovery Point Objective – maksymalna dopuszczalna utrata danych w czasie), procedury odtwarzania, kontakty serwisowe (administrator wewnętrzny, partner Comarch, wsparcie Comarch) i procedury komunikacji z użytkownikami podczas awarii.
