Jak zrobić kopię zapasową systemu ERP i jak często wykonywać backup?

Awaria serwera ERP o godzinie 14:00 może oznaczać utratę kilkuset zamówień, dokumentów magazynowych i zapisów księgowych. Jeżeli ostatnia kopia zapasowa powstała poprzedniego wieczoru, firma może stracić dane z całego dnia pracy. Jeszcze gorzej, gdy backup istnieje, ale nie da się go odtworzyć. Kopia zapasowa systemu ERP musi więc obejmować nie tylko bazę danych, lecz także pliki, konfigurację i elementy niezbędne do ponownego uruchomienia aplikacji. Równie istotne jest ustalenie częstotliwości wykonywania kopii na podstawie rzeczywistego tempa pracy przedsiębiorstwa.

Jak prawidłowo wykonać kopię zapasową systemu ERP?

Pierwszym krokiem jest ustalenie, gdzie ERP przechowuje dane i jakie komponenty są potrzebne do jego działania. W systemach takich jak Comarch ERP Optima, enova365 czy Microsoft Dynamics 365 Business Central sposób tworzenia i odzyskiwania kopii zależy od wersji produktu, wykorzystywanej bazy danych oraz modelu wdrożenia. Inaczej zabezpiecza się instalację na własnym serwerze, a inaczej środowisko udostępniane w chmurze.

W przypadku lokalnej instalacji ERP trzeba zwykle uwzględnić:

• Bazę danych – informacje o kontrahentach, dokumentach sprzedaży, księgowości, stanach magazynowych i operacjach użytkowników.
• Pliki i załączniki – skany faktur, dokumenty PDF, pliki wymiany danych oraz inne zasoby przechowywane poza bazą.
• Konfigurację aplikacji – ustawienia modułów, integracji, harmonogramów zadań, połączeń i usług.
• Środowisko uruchomieniowe – wersje oprogramowania, zależności, certyfikaty oraz informacje potrzebne do odtworzenia licencji i uprawnień.

Samo skopiowanie folderu z programem nie wystarczy. W działającym systemie baza danych jest stale modyfikowana. Zwykłe kopiowanie otwartych plików bazy może dać niespójny rezultat, nawet jeżeli operacja zakończy się bez komunikatu o błędzie.

Przykładowo, jeżeli ERP wykorzystuje Microsoft SQL Server, administrator może wykonać kopię bazy przez SQL Server Management Studio, wybierając bazę i polecenie *Tasks → Back Up*. Następnie określa typ kopii, miejsce jej zapisania i uruchamia operację. W środowisku produkcyjnym lepiej zautomatyzować ten proces za pomocą SQL Server Agent lub odpowiedniego narzędzia backupowego, uwzględniając ograniczenia używanej edycji serwera.

Praktyczna procedura wygląda następująco:

1. Sprawdź dokumentację ERP i ustal, które bazy, katalogi oraz ustawienia muszą zostać zabezpieczone.
2. Wykonaj kopię mechanizmem obsługującym dany silnik bazy danych, tak aby zachować spójność transakcyjną.
3. Zabezpiecz pliki zewnętrzne i konfigurację z tego samego logicznego punktu odtworzenia.
4. Prześlij kopię do oddzielnej lokalizacji, korzystając z szyfrowania i konta z ograniczonymi uprawnieniami.
5. Zweryfikuj wynik operacji – sprawdź dzienniki, integralność kopii i możliwość jej odtworzenia na środowisku testowym.

W systemie opartym na PostgreSQL można wykorzystać `pg_basebackup` wraz z archiwizacją dzienników WAL. Takie połączenie pozwala odtwarzać bazę do określonego momentu, pod warunkiem zachowania kompletnego, nieprzerwanego łańcucha wymaganych dzienników. Sam eksport wykonany przez `pg_dump` nie zapewnia takiej możliwości.

Dobór metody zależy też od wielkości bazy. Dla niewielkiej instalacji z bazą o rozmiarze 20 GB codzienna pełna kopia może być wystarczająco szybka. Przy bazie zajmującej 800 GB częste wykonywanie pełnych kopii będzie mocniej obciążało zasoby i przestrzeń dyskową. W takim przypadku sens mają kopie różnicowe, przyrostowe lub archiwizacja logów, zależnie od technologii.

Nie należy traktować migawki maszyny wirtualnej jako automatycznego zamiennika backupu bazy. Migawka bez obsługi spójności aplikacyjnej może nie zapewnić poprawnego punktu odtworzenia. Dodatkowo przechowywanie jej wyłącznie na tej samej macierzy nie chroni przed awarią całego urządzenia.

Jak często wykonywać backup ERP i ile kopii przechowywać?

Częstotliwości backupu nie ustala się na podstawie liczby pracowników ani samej wielkości bazy danych. Decydujące jest to, ile danych firma może zaakceptować jako utracone po awarii.

Służy do tego parametr RPO (Recovery Point Objective), czyli maksymalny akceptowalny okres utraty danych. Jeżeli RPO wynosi 15 minut, system zabezpieczeń powinien umożliwiać przywrócenie informacji ze stratą nieprzekraczającą tego przedziału w ramach przyjętych scenariuszy awarii.

Drugim parametrem jest RTO (Recovery Time Objective) – maksymalny zakładany czas przywrócenia działania ERP. RPO i RTO odpowiadają na dwa różne pytania: ile danych można stracić oraz jak długo przedsiębiorstwo może pracować bez systemu.

Przykładowe harmonogramy dla różnych warunków pracy przedstawiają się następująco:

| Rodzaj działalności | Przykładowe RPO | Proponowany harmonogram | |—|—|—| | Mała firma usługowa, kilkanaście dokumentów dziennie | 24 godziny | Pełna kopia raz dziennie | | Hurtownia obsługująca kilkaset zamówień dziennie | 1 godzina | Pełna kopia codziennie, logi transakcyjne co godzinę | | Firma produkcyjna pracująca na trzy zmiany | 15 minut | Pełna kopia codziennie, logi co 15 minut | | Duży magazyn z intensywną sprzedażą internetową | 5–15 minut | Pełne kopie według harmonogramu, częsta archiwizacja logów lub mechanizm ciągłej ochrony danych |

Są to przykładowe założenia projektowe, a nie gwarantowane parametry każdego ERP. Backup logów transakcyjnych wymaga odpowiedniej konfiguracji silnika bazy. W SQL Server konieczne jest między innymi zastosowanie właściwego modelu odzyskiwania, np. FULL, oraz prawidłowe rozpoczęcie łańcucha kopii logów.

Wyobraźmy sobie hurtownię, która między 8:00 a 16:00 przyjmuje 400 zamówień. Przy równomiernym rozkładzie oznacza to średnio 50 zamówień na godzinę. Jeżeli backup powstaje tylko o północy, awaria o 15:00 może wymusić ponowne wprowadzenie znacznej części dziennych transakcji. Przy RPO równym 15 minut potencjalna utrata odpowiada średnio około 12–13 zamówieniom. W rzeczywistości wynik zależy od pory awarii, obciążenia systemu oraz poprawności ostatnich kopii.

Częstszy backup ma jednak swoją cenę. Więcej punktów odtworzenia oznacza dodatkowe operacje wejścia i wyjścia, zajętość przestrzeni dyskowej oraz konieczność pilnowania kompletności łańcucha kopii. Jeśli firma przyjmuje trzy faktury dziennie i jest w stanie odtworzyć je z dokumentów źródłowych, wykonywanie backupu co pięć minut zwykle nie ma uzasadnienia.

Osobną decyzją jest czas przechowywania kopii. Przykładowa polityka retencji może zakładać:

• Kopie dzienne – przechowywane przez 14 dni.
• Kopie tygodniowe – przechowywane przez 8 tygodni.
• Kopie miesięczne – przechowywane przez 12 miesięcy.
• Kopie przed aktualizacją ERP – zachowywane do zakończenia testów i zaakceptowania nowej wersji.

Nie oznacza to, że wszystkie dane muszą być przechowywane tylko przez taki okres. Retencja backupów i obowiązki archiwizowania dokumentacji księgowej to różne kwestie. Przykładowo ustawa o rachunkowości przewiduje dla wielu kategorii dokumentacji okres przechowywania wynoszący co najmniej pięć lat, z określonymi zasadami liczenia terminów. Nie wymaga to jednak zachowywania przez pięć lat każdej dziennej kopii całego ERP.

W praktyce dobrze sprawdza się zasada 3-2-1: trzy kopie danych, dwa rodzaje nośników i jedna kopia poza główną lokalizacją. Nie jest to jednak magiczna ochrona przed ransomware. Jeżeli wszystkie repozytoria są dostępne z jednego konta administratora, atakujący może usunąć również backupy.

Dlatego przynajmniej jedną kopię warto zabezpieczyć przed modyfikacją, na przykład przez niezmienialne repozytorium (immutable backup) lub fizyczne odłączenie nośnika. Dla firm przetwarzających dane osobowe znaczenie ma również art. 32 RODO, wymagający między innymi odpowiedniej zdolności przywrócenia dostępności danych oraz regularnego testowania skuteczności zabezpieczeń.

Gdzie przechowywać kopie ERP i jak sprawdzić, czy da się je odtworzyć?

Najpoważniejszy błąd to przechowywanie jedynego backupu na tym samym serwerze, na którym działa ERP. Uszkodzenie macierzy, awaria zasilania prowadząca do utraty danych albo atak ransomware mogą jednocześnie unieruchomić system i zniszczyć jego kopię.

Rozsądny wariant dla przedsiębiorstwa z własną infrastrukturą obejmuje lokalne repozytorium backupowe oraz dodatkową kopię poza siedzibą firmy. Lokalna kopia umożliwia zazwyczaj szybkie odtworzenie dużej bazy, natomiast zewnętrzna chroni przed zdarzeniami obejmującymi całą lokalizację.

Przykład: firma produkcyjna ma bazę ERP o rozmiarze 300 GB. Przechowuje backup na wydzielonym serwerze w swojej sieci oraz przesyła zaszyfrowaną kopię do zewnętrznego centrum danych. Jeśli potrzebuje odtworzyć 300 GB przez łącze o przepustowości 100 Mb/s, samo pobranie danych zajmie teoretycznie około 6 godzin i 40 minut przy pełnym wykorzystaniu łącza. W praktyce potrwa dłużej ze względu na narzut transmisji, ograniczenia usług i zmienną przepustowość.

To ważny szczegół: backup w chmurze nie gwarantuje szybkiego powrotu ERP do pracy. Przy ograniczonym łączu internetowym korzystniejsze może być przechowywanie lokalnej kopii do szybkiego odzyskiwania, uzupełnionej o zabezpieczoną kopię zewnętrzną.

W modelu SaaS sytuacja wygląda inaczej. Dostawca może wykonywać backup infrastruktury, ale klient nie zawsze ma możliwość samodzielnego pobrania pełnej bazy lub odtworzenia systemu do dowolnej minuty. Przed podpisaniem umowy należy sprawdzić:

• czy można odtworzyć pojedynczą firmę, bazę lub dokument;
• ile wynosi gwarantowany czas odzyskania działania systemu;
• jak długo dostawca przechowuje punkty odtworzenia;
• czy przywrócenie danych wymaga zgłoszenia serwisowego i dodatkowej opłaty;
• jak realizowany jest eksport danych po zakończeniu umowy.

Przy wyborze dostawcy i planowaniu zabezpieczeń ERP można również zapoznać się z informacjami dostępnymi na stronie https://acomit.pl. Zakres odpowiedzialności za backup powinien jednak zawsze wynikać z dokumentacji wdrożenia i warunków konkretnej usługi.

Sama obecność pliku backupowego to za mało. Jedynym wiarygodnym potwierdzeniem możliwości odzyskania ERP jest udany test odtworzeniowy, obejmujący nie tylko bazę, ale również działanie aplikacji.

W przedsiębiorstwie korzystającym z SQL Server test można przeprowadzić na oddzielnej instancji. Administrator odtwarza pełną kopię, stosuje wymagane kopie różnicowe i logi transakcyjne, a następnie sprawdza, czy ERP uruchamia się prawidłowo. Kontrola powinna obejmować logowanie, otwieranie dokumentów, zgodność stanów magazynowych oraz dostępność załączników.

Dobrą praktyką jest wykonywanie testu odtworzenia co najmniej raz na kwartał dla ważnych środowisk, a dodatkowo po istotnych zmianach infrastruktury, mechanizmu backupu lub wersji ERP. Dla systemów o wymaganym RTO liczonym w minutach testy powinny być częstsze i obejmować kompletny scenariusz awaryjny.

Wynik należy zapisać: datę testu, wykorzystany zestaw kopii, czas odtwarzania, liczbę wykrytych błędów oraz uzyskany punkt przywrócenia. Jeżeli firma zakłada RTO wynoszące dwie godziny, ale uruchomienie ERP na zapasowej maszynie zajęło pięć, procedura nie spełnia założenia, nawet gdy dane są kompletne.

Nie należy też pomijać bezpieczeństwa samego środowiska testowego. Odtworzenie produkcyjnej bazy zawierającej dane klientów na serwerze dostępnym dla wszystkich pracowników może stworzyć nowy problem z ochroną informacji. Środowisko testowe powinno mieć ograniczony dostęp, a tam, gdzie jest to uzasadnione, dane należy pseudonimizować lub anonimizować.

Pierwszą czynnością powinno być sprawdzenie daty ostatniego poprawnego backupu i wykonanie próbnego odtworzenia na osobnym środowisku. Dopiero po potwierdzeniu, że baza, załączniki i konfiguracja działają prawidłowo, należy ustalić docelowe RPO, RTO oraz harmonogram. Jeśli ostatni udany test miał miejsce kilka lat temu albo nigdy go nie przeprowadzono, właśnie ten błąd trzeba usunąć przed zakupem kolejnego narzędzia.

FAQ – najczęstsze pytania o backup systemu ERP

Czy kopię zapasową ERP trzeba wykonywać codziennie?
Codzienny backup to rozsądne minimum dla wielu firm, ale przy intensywnej sprzedaży lub produkcji może być niewystarczający. Jeśli przedsiębiorstwo nie może utracić więcej niż 15 minut pracy, potrzebuje mechanizmu zapewniającego odpowiednie RPO, np. częstych kopii logów transakcyjnych.

Czy można wykonywać backup ERP podczas pracy użytkowników?
Tak, jeśli silnik bazy danych i wybrana metoda obsługują spójne kopie wykonywane online. Nie należy natomiast kopiować otwartych plików bazy zwykłym poleceniem systemowym bez mechanizmu zapewniającego spójność danych.

Czym różni się backup pełny od przyrostowego?
Pełny backup zawiera kompletny zestaw danych objętych kopią. Backup przyrostowy zapisuje zmiany względem określonej wcześniejszej kopii. Zmniejsza to ilość kopiowanych danych, ale odtworzenie może wymagać kilku zależnych zestawów. Dokładny mechanizm zależy od narzędzia i silnika bazy.

Czy ERP działający w chmurze wymaga dodatkowego backupu?
Zależy to od zakresu usługi. Dostawca może odpowiadać za odzyskiwanie całego środowiska, ale niekoniecznie za przywracanie przypadkowo usuniętych dokumentów. Trzeba sprawdzić warunki SLA, retencję i dostępne opcje eksportu.

Jak często testować przywracanie ERP z kopii?
Dla istotnego systemu dobrym punktem wyjścia jest test kwartalny oraz dodatkowe próby po większych zmianach. Częstotliwość należy zwiększyć, gdy ERP obsługuje procesy krytyczne, a dopuszczalny czas przestoju jest krótki.

Czy backup chroni przed ransomware?
Ogranicza ryzyko trwałej utraty danych, ale nie zapobiega samemu atakowi. Kopie powinny być izolowane od środowiska produkcyjnego, zabezpieczone przed nieautoryzowanym usunięciem i regularnie testowane. Backup nie cofa również ewentualnego wycieku danych.