Backup ERP.
Dlaczego sama kopia bazy SQL nie wystarczy?

System ERP jest jednym z najważniejszych elementów infrastruktury firmy. To w nim znajdują się zamówienia, dokumenty magazynowe, rozrachunki, faktury, dane klientów, plany produkcji i informacje potrzebne do codziennej pracy wielu działów.

Mimo to w wielu organizacjach strategia backupu ERP sprowadza się do jednego zadania: codziennego wykonania pliku .bak z bazy Microsoft SQL Server.

Taka kopia jest bardzo ważna, ale nie wystarcza do odtworzenia całego środowiska.

Po poważnej awarii może się okazać, że baza danych jest dostępna, lecz brakuje plików aplikacji, certyfikatów, konfiguracji serwera, integracji, repozytoriów dokumentów albo informacji potrzebnych do uruchomienia systemu.

Skuteczny backup ERP musi obejmować nie tylko dane, ale również wszystkie elementy niezbędne do przywrócenia działania procesów biznesowych.

Dlaczego kopia bazy SQL to tylko część backupu ERP?

Baza danych przechowuje najważniejsze informacje biznesowe, ale system ERP zwykle składa się z wielu współpracujących elementów. W zależności od producenta i architektury mogą to być:

Jeżeli kopia obejmuje wyłącznie bazę, po awarii można odzyskać dane, ale nadal nie mieć kompletnego i działającego systemu.

Co może się wydarzyć przy backupie samej bazy?

Brak zgodnych plików aplikacji

Po odtworzeniu bazy może się okazać, że nie ma instalatora właściwej wersji programu, dodatków lub bibliotek. Nowsza wersja aplikacji nie zawsze będzie poprawnie współpracować ze starszą bazą. Własne modyfikacje mogą również wymagać konkretnych plików, których nie da się już pobrać od producenta.

Utrata załączników i dokumentów

Nie wszystkie dokumenty muszą znajdować się bezpośrednio w bazie. Skanowane faktury, pliki PDF, zdjęcia produktów, dokumentacja techniczna lub pliki wymiany mogą być przechowywane w zewnętrznych katalogach albo repozytoriach.

Po odtworzeniu samej bazy rekordy będą widoczne, ale powiązane pliki mogą być niedostępne.

Brak integracji

ERP rzadko działa samodzielnie. System może wymieniać dane z WMS, platformą B2B, sklepem internetowym, bankiem, systemami kurierskimi, EDI, automatyką magazynową, oprogramowaniem produkcyjnym oraz narzędziami Business Intelligence.

Do działania integracji potrzebne są skrypty, mapowania, kolejki, certyfikaty, dane uwierzytelniające oraz konfiguracje usług. Sama baza ERP nie odtworzy tych elementów.

Brak wiedzy potrzebnej do uruchomienia systemu

Nawet kompletne pliki są niewiele warte, jeżeli nikt nie wie:

• -w jakiej kolejności uruchomić usługi,
• -gdzie znajdują się klucze i certyfikaty,
• -jakie zależności ma aplikacja,
• -które konta serwisowe są wymagane,
• -jak skonfigurować połączenia z bazą,
• -jak zweryfikować poprawność działania po odtworzeniu.

Dlatego dokumentacja i procedura Disaster Recovery są częścią skutecznej strategii backupu.

Jakie elementy powinien obejmować pełny backup ERP?

Backup bazy danych

W przypadku Microsoft SQL Server strategia może obejmować pełne kopie bazy, kopie różnicowe, backupy logu transakcyjnego, kontrolę poprawności plików oraz przechowywanie kilku niezależnych punktów przywracania. Szczegółowo opisaliśmy to w artykule SQL Server dla ERP.

Częstotliwość backupu logu powinna wynikać z wymaganego RPO, czyli maksymalnej akceptowalnej utraty danych. Jeżeli firma może stracić najwyżej 15 minut pracy, kopia logu raz na kilka godzin nie spełni tego wymagania.

Backup maszyny wirtualnej

Kopia całej maszyny pozwala odtworzyć system operacyjny, zainstalowane aplikacje, konfigurację usług, lokalne pliki i część zależności środowiska.

Backup VM jest bardzo przydatny przy awarii serwera lub konieczności szybkiego odtworzenia całego systemu. Nie powinien jednak zastępować natywnych backupów bazy danych.

Backup plików i repozytoriów

Osobną ochroną należy objąć załączniki, dokumenty, katalogi wymiany, raporty, szablony, pliki eksportów i importów oraz repozytoria zewnętrzne. Zakres powinien wynikać z rzeczywistej architektury konkretnego systemu ERP.

Backup konfiguracji i integracji

Należy zabezpieczyć między innymi:

Warto również przechowywać kod integracji i konfigurację w repozytorium Git, jeżeli pozwala na to charakter rozwiązania.

Dokumentacja odtwarzania

Procedura powinna wskazywać:

• -kto podejmuje decyzję o odtworzeniu,
• -gdzie znajdują się backupy,
• -jakie są wymagane konta i klucze,
• -w jakiej kolejności uruchamia się komponenty,
• -jak sprawdzić spójność bazy,
• -jak zweryfikować integracje,
• -kiedy można dopuścić użytkowników do pracy.

Bez takiej instrukcji czas odtworzenia zależy od pamięci jednego administratora.

Backup VM a backup SQL Server

Te dwa rodzaje kopii rozwiązują inne problemy.

Najlepszą ochronę zapewnia połączenie obu mechanizmów. Backup całej VM nie eliminuje potrzeby wykonywania kopii SQL. Z kolei sam plik .bak nie odtworzy kompletnego środowiska aplikacyjnego.

Snapshot nie jest backupem

Snapshot maszyny wirtualnej lub storage może być przydatny przed aktualizacją, zmianą konfiguracji albo krótkotrwałym testem. Nie powinien jednak być traktowany jako podstawowa kopia zapasowa. Snapshot:

• -zwykle pozostaje na tym samym storage,
• -może zostać utracony razem z produkcją,
• -nie chroni przed awarią całej lokalizacji,
• -może zostać usunięty przez administratora lub atakującego,
• -nie zastępuje retencji i kopii off-site.

Snapshot jest narzędziem operacyjnym, a nie kompletną strategią Disaster Recovery.

Jak może wyglądać backup ERP na Proxmox?

Przykładowa architektura może obejmować kilka warstw.

Warstwa pierwsza: natywne backupy bazy

SQL Server wykonuje pełne kopie, backupy różnicowe oraz kopie logu transakcyjnego. Pliki trafiają na dedykowane repozytorium, a zadania są monitorowane.

Warstwa druga: Proxmox Backup Server

Cała maszyna wirtualna jest kopiowana do Proxmox Backup Server. PBS zapewnia między innymi:

• -backup przyrostowy,
• -deduplikację,
• -kompresję,
• -szyfrowanie po stronie klienta,
• -weryfikację integralności,
• -retencję wielu punktów przywracania.

Proxmox Backup Server powinien działać na osobnym repozytorium, a najlepiej na osobnym serwerze.

Warstwa trzecia: kopia poza główną lokalizacją

Backup jest synchronizowany do drugiego Proxmox Backup Server, Data Center, innego oddziału lub zabezpieczonego repozytorium zewnętrznego. Chroni to przed utratą całej serwerowni, kradzieżą lub poważną awarią budynku.

Warstwa czwarta: kopia chroniona przed zmianą

Przynajmniej jedna kopia powinna być niemodyfikowalna, offline, odseparowana od głównej domeny i dostępna przez osobne konta administracyjne. Jest to szczególnie ważne przy ochronie przed ransomware - piszemy o tym w artykule Czy Twoje backupy przetrwają ransomware?

Reguła 3-2-1-1-0 dla ERP

Skuteczna strategia może być oparta na zasadzie:

W praktyce może to oznaczać:

1. 1 dane produkcyjne,
2. 2 lokalny backup SQL i VM,
3. 3 kopię off-site,
4. 4 dodatkową kopię chronioną przed usunięciem,
5. 5 regularnie potwierdzony test restore.

Jak dobrać RPO i RTO?

RPO

Recovery Point Objective określa maksymalną ilość danych, którą firma może stracić. Przykładowo:

• -RPO 24 godziny oznacza możliwość utraty całego dnia pracy,
• -RPO 60 minut oznacza utratę maksymalnie jednej godziny,
• -RPO 15 minut wymaga odpowiednio częstych backupów logu lub replikacji.

RTO

Recovery Time Objective określa, jak szybko system musi wrócić do działania. RTO zależy między innymi od rozmiaru baz i maszyn, prędkości repozytorium backupowego, przepustowości sieci, dostępności sprzętu zastępczego, liczby integracji, jakości dokumentacji oraz częstotliwości testów.

Nie należy deklarować RTO poniżej dwóch godzin tylko dlatego, że backup jest wykonywany przez PBS lub Veeam. Taki wynik musi zostać potwierdzony praktycznym testem odtworzenia całego środowiska.

Retencja backupu ERP

Nie istnieje jeden harmonogram odpowiedni dla każdej firmy. Punktem wyjścia może być:

• -od 7 do 14 kopii dziennych,
• -od 4 do 8 kopii tygodniowych,
• -12 kopii miesięcznych,
• -kopie roczne zgodne z wymaganiami biznesowymi i prawnymi.

Retencja powinna uwzględniać możliwość późnego wykrycia błędu, ryzyko ransomware działającego przez wiele dni, wymagania księgowe, sezonowość firmy oraz czas potrzebny na wykrycie uszkodzenia danych.

Dłuższa retencja nie zastępuje jednak testów i ochrony przed modyfikacją.

Test odtwarzania jest ważniejszy niż raport „success"

Zielony status zadania potwierdza jedynie, że oprogramowanie wykonało określoną operację. Nie potwierdza, że:

• -baza jest spójna,
• -istnieją wszystkie zależności,
• -hasła są dostępne,
• -aplikacja uruchomi się na nowym serwerze,
• -integracje będą działać,
• -system uda się odtworzyć w wymaganym czasie.

Test restore powinien obejmować nie tylko techniczne uruchomienie serwera, ale również sprawdzenie najważniejszych procesów biznesowych. Przykładowa weryfikacja może obejmować:

Dla krytycznego systemu ERP pełny test raz na kwartał jest rozsądnym punktem wyjścia. Dodatkowe testy warto wykonywać po większych aktualizacjach i zmianach architektury.

Najczęstsze błędy w backupie ERP

Podczas audytów regularnie spotykamy:

Najgroźniejsze jest przekonanie, że samo istnienie kopii oznacza możliwość szybkiego powrotu do pracy.

Ile kosztuje skuteczny backup ERP?

Koszt zależy od wielkości środowiska, przyrostu danych, wymaganego RPO, oczekiwanego RTO, długości retencji, liczby lokalizacji, technologii backupowej i częstotliwości testów.

Dla jednego prostego serwera miesięczny koszt może być niewielki. Rozbudowane środowisko z kilkoma maszynami, bazą SQL, dużym repozytorium dokumentów, kopią off-site i regularnymi testami będzie kosztować więcej.

Nie warto jednak porównywać kosztu backupu wyłącznie z ceną przestrzeni dyskowej. Trzeba zestawić go z kosztem:

• -przestoju pracowników,
• -zatrzymania magazynu lub produkcji,
• -ręcznego odtwarzania danych,
• -ponownego wystawiania dokumentów,
• -utraty zaufania klientów,
• -potencjalnego naruszenia danych osobowych.

Backup ERP jest elementem zarządzania ciągłością działania, a nie wyłącznie usługą przechowywania plików.

Co powinien zawierać audyt backupu ERP?

Rzetelny audyt powinien sprawdzić wszystkie komponenty systemu, harmonogram backupów SQL, łańcuch logów transakcyjnych, zakres kopii maszyn wirtualnych, katalogi z załącznikami, integracje, retencję, kopię off-site, ochronę przed ransomware, monitoring zadań, dokumentację, wyniki ostatnich testów oraz realne RPO i RTO.

Efektem powinna być lista braków oraz plan ich usunięcia według priorytetów.

Podsumowanie

Sama kopia bazy SQL jest ważnym elementem ochrony systemu ERP, ale nie wystarcza do odtworzenia całego środowiska.

Pełny backup powinien obejmować bazę danych, pliki aplikacji, konfigurację, załączniki, integracje, certyfikaty, dokumentację oraz procedurę odtworzenia.

Najbezpieczniejsze podejście łączy natywne backupy bazy, kopię całej maszyny, repozytorium off-site oraz warstwę chronioną przed modyfikacją. Całość musi być monitorowana i regularnie testowana.

Jeżeli backup ERP sprowadza się do pliku .bak zapisywanego raz dziennie na NAS-ie, warto potraktować to jako początek strategii, a nie jej zakończenie. Dlaczego to za mało, piszemy też w artykule o backupie tylko na NAS-ie.

W PRO-Admin analizujemy całą architekturę systemu ERP, a nie tylko zadanie backupowe. Sprawdzamy bazę, maszyny wirtualne, pliki, integracje, retencję oraz realny czas odtworzenia. Na tej podstawie przygotowujemy plan backupu i Disaster Recovery dopasowany do rzeczywistych wymagań firmy.