Kopia zapasowa danych z programów księgowo-magazynowych

Regularna kopia zapasowa danych z programów księgowo-magazynowych to jedno z najważniejszych zadań w obsłudze informatycznej firmy — utrata bazy księgowej oznacza nie tylko przestój w pracy, ale też potencjalne problemy prawne związane z obowiązkiem przechowywania dokumentacji finansowej.

W bazie programu księgowego lub magazynowego znajdują się między innymi dokumenty sprzedaży i zakupu, dane kontrahentów, kartoteki towarowe, stany magazynowe, rozrachunki, deklaracje, ustawienia użytkowników oraz historia operacji. Odtworzenie takich informacji ręcznie jest zwykle bardzo trudne, a czasem niemożliwe. Dlatego backup powinien być zaplanowany wcześniej i działać automatycznie, bez konieczności pamiętania o nim przez pracowników.

Sposób wykonywania kopii zapasowej zależy od typu bazy danych, na której pracuje program. Dla programów opartych na Microsoft SQL Server (Comarch ERP, enova365, Symfonia ERP, WF-Mag) konfigurujemy zadania backupu na poziomie samego silnika bazy — pełne kopie w cyklu dobowym, opcjonalnie kopie różnicowe częściej, wykonywane automatycznie przez harmonogram zadań systemu Windows lub SQL Server Agent w wersji Standard.

Backup powinien obejmować wszystkie bazy wykorzystywane przez program, a nie tylko główną bazę firmy. W praktyce mogą występować również bazy pomocnicze, testowe, konfiguracyjne albo bazy kilku oddziałów. Pominięcie jednej z nich może spowodować, że po awarii część danych zostanie odtworzona, ale program nie będzie działał poprawnie lub nie zachowa pełnej historii operacji.

Programy z bazą plikową

Dla programów przechowujących dane w plikach lokalnych (RAKS, starsza Symfonia Klasyka) kopię zapasową wykonujemy poprzez kopiowanie całego katalogu danych przy zatrzymanym silniku bazy lub za pomocą wbudowanego narzędzia archiwizacji programu, jeśli takie posiada. Ważne, by kopia obejmowała również pliki konfiguracyjne i licencyjne.

Nie należy kopiować aktywnych plików bazy w trakcie pracy programu bez sprawdzenia, czy producent dopuszcza takie rozwiązanie. Jeżeli użytkownik zapisuje dane w chwili wykonywania kopii, pliki mogą zostać skopiowane tylko częściowo albo w niespójnym stanie. Taki backup może wyglądać poprawnie w katalogu, ale nie pozwolić na uruchomienie programu lub odzyskanie dokumentów.

Przed rozpoczęciem kopiowania warto zamknąć program na wszystkich stanowiskach i sprawdzić, czy nie pozostały uruchomione procesy korzystające z bazy. Przy większej liczbie komputerów trzeba uwzględnić także stanowiska zdalne i połączenia przez pulpit zdalny. Kopia powinna być wykonywana dopiero wtedy, gdy dane nie są już modyfikowane.

Co powinno znaleźć się w kopii?

Zakres backupu zależy od używanego programu, ale zazwyczaj powinien obejmować katalogi danych, pliki konfiguracyjne, ustawienia połączenia z bazą, informacje o użytkownikach oraz elementy niezbędne do odtworzenia środowiska pracy. Warto również zachować dokumentację konfiguracji, na przykład nazwę serwera, ścieżki katalogów i sposób logowania do bazy.

W przypadku programów magazynowych znaczenie mogą mieć także dodatkowe pliki związane z wydrukami, etykietami, dokumentami elektronicznymi, integracjami z urządzeniami oraz eksportami danych. Sama baza może nie zawierać wszystkich plików wykorzystywanych przez aplikację. Dlatego przed ustaleniem procedury backupu trzeba sprawdzić, gdzie program zapisuje dokumenty i ustawienia.

Backup bazy SQL Server

W środowisku Microsoft SQL Server kopię wykonuje się z wykorzystaniem mechanizmów silnika bazy danych. Najczęściej podstawą jest pełny backup każdej bazy, uzupełniony w razie potrzeby o kopie różnicowe lub kopie dziennika transakcji. Dobór schematu zależy od tego, jak często zmieniają się dane i jak długą przerwę w pracy firma może zaakceptować po awarii.

Pełna kopia zawiera kompletny stan bazy w określonym momencie. Kopia różnicowa obejmuje zmiany od czasu ostatniego pełnego backupu, natomiast kopia dziennika transakcji może pozwolić na dokładniejsze odtworzenie kolejnych operacji. Im bardziej rozbudowany schemat, tym ważniejsze staje się monitorowanie kolejności plików i poprawności całego łańcucha kopii.

Nie wystarczy samo utworzenie zadania w SQL Server. Trzeba sprawdzić, czy konto wykonujące backup ma dostęp do katalogu docelowego, czy na dysku pozostaje odpowiednia ilość miejsca oraz czy zadanie kończy się bez błędów. Warto także ustalić sposób przechowywania starszych kopii, aby backup nie zapełnił dysku serwera i nie doprowadził do zatrzymania innych usług.

Zasada 3-2-1

Rekomendujemy klientom zasadę trzech kopii danych, na dwóch różnych nośnikach, z czego jedna przechowywana poza siedzibą firmy (np. w chmurze lub na dysku zewnętrznym zabieranym poza biuro). Taka strategia chroni zarówno przed awarią sprzętu, jak i zdarzeniami losowymi takimi jak pożar, zalanie czy kradzież.

Trzy kopie nie powinny oznaczać trzech folderów znajdujących się na tym samym dysku. Awaria dysku, infekcja ransomware albo przypadkowe usunięcie danych może objąć wszystkie katalogi jednocześnie. Dlatego kopie powinny być przechowywane w sposób zapewniający niezależność, a przynajmniej jedna z nich powinna być odłączona od komputera lub dostępna poza lokalną siecią.

Ważne jest również rozdzielenie uprawnień. Użytkownik pracujący na co dzień z programem księgowym nie powinien mieć możliwości usunięcia wszystkich kopii zapasowych. Jeżeli konto zostanie przejęte albo komputer zostanie zaszyfrowany, ograniczone uprawnienia mogą pomóc ochronić backup przed tym samym zdarzeniem.

Rotacja i przechowywanie kopii

W praktycznej procedurze backupu warto stosować rotację nośników lub wersji plików. Dzięki temu pozostaje dostęp nie tylko do ostatniej kopii, ale również do wcześniejszych stanów danych. Jest to istotne wtedy, gdy błąd zostanie zauważony dopiero po kilku dniach, na przykład po usunięciu dokumentu albo zapisaniu nieprawidłowych danych.

Okres przechowywania kopii trzeba dopasować do sposobu pracy firmy, wymagań dokumentacyjnych oraz pojemności używanych nośników. Należy też opisać kopie w czytelny sposób: podać datę wykonania, zakres danych i rodzaj backupu. Brak opisów może utrudnić wybór właściwej wersji podczas odtwarzania.

Testowanie kopii zapasowych

Samo wykonywanie kopii to nie wszystko — regularnie testujemy możliwość odtworzenia danych z backupu, ponieważ uszkodzona lub niekompletna kopia zapasowa daje fałszywe poczucie bezpieczeństwa. Dla klientów objętych stałą opieką serwisową prowadzimy harmonogram takich testów oraz monitorujemy, czy zaplanowane zadania backupu faktycznie wykonują się bez błędów.

Test odtworzeniowy powinien sprawdzać więcej niż obecność pliku na dysku. Należy zweryfikować, czy archiwum można odczytać, czy baza poprawnie przywraca się na serwerze oraz czy program widzi dokumenty, kontrahentów, towary i historię operacji. W przypadku bazy plikowej trzeba dodatkowo sprawdzić, czy aplikacja uruchamia się z przywróconego katalogu.

Najbezpieczniej wykonywać próby odtworzenia w środowisku testowym, bez nadpisywania aktualnej bazy produkcyjnej. Pozwala to sprawdzić procedurę bez ryzyka utraty bieżących danych. W trakcie testu można również zmierzyć czas potrzebny na przywrócenie pracy i ustalić, jakie czynności musi wykonać administrator lub serwis.

Monitoring zadań backupu

Automatyczne zadanie może przestać działać z powodu braku miejsca, zmiany hasła konta, odłączenia dysku, błędu usługi SQL Server albo problemu z połączeniem sieciowym. Dlatego warto monitorować nie tylko sam harmonogram, ale również rozmiar tworzonych plików i datę ostatniej poprawnej kopii.

Nagły spadek rozmiaru backupu może oznaczać, że kopia obejmuje niewłaściwy katalog albo pustą bazę. Z kolei brak nowych plików przez kilka dni powinien być traktowany jako zdarzenie wymagające sprawdzenia, a nie jako zwykłe ostrzeżenie.

Kopie w chmurze

Coraz częściej konfigurujemy dodatkowo automatyczne przesyłanie kopii zapasowych do chmury (np. poprzez usługi backupu online), co eliminuje ryzyko związane z fizycznym uszkodzeniem lub kradzieżą nośników znajdujących się w biurze firmy.

Backup online powinien działać według ustalonego harmonogramu i przesyłać dane w sposób szyfrowany. Trzeba też sprawdzić, kto ma dostęp do konta, czy jest stosowane dodatkowe uwierzytelnianie oraz czy dostawca umożliwia odzyskanie starszych wersji plików. Sama synchronizacja folderu nie zawsze jest pełnoprawnym backupem, ponieważ usunięcie pliku lokalnie może zostać przeniesione również do chmury.

Przy dużych bazach ważna jest także pierwsza kopia i czas przesyłania kolejnych zmian. Jeżeli firma korzysta z wolnego łącza, backup powinien być zaplanowany tak, aby nie zakłócał pracy użytkowników. Można również ustalić, które dane są przesyłane w pierwszej kolejności i jak długo mają być przechowywane.

Ochrona przed ransomware i błędami użytkowników

Utrata danych nie zawsze wynika z awarii dysku. Częstą przyczyną problemów jest złośliwe oprogramowanie szyfrujące pliki albo pomyłka pracownika. Dlatego kopia zapasowa powinna być chroniona przed modyfikacją i usunięciem z komputera, na którym pracują użytkownicy.

Warto ograniczyć prawa dostępu, zabezpieczyć konto administracyjne i stosować aktualne oprogramowanie ochronne. Należy również uświadomić pracowników, że backup nie zastępuje ostrożności przy otwieraniu załączników, korzystaniu z nośników USB i instalowaniu nieznanych programów.

Plan odtworzenia danych

Procedura awaryjna powinna opisywać kolejność działań po uszkodzeniu komputera lub serwera. Najpierw trzeba zabezpieczyć nośnik z kopią i ustalić przyczynę awarii, aby nie nadpisać danych podczas pochopnej naprawy. Następnie należy przygotować sprawny sprzęt, zainstalować wymagane składniki programu i przywrócić bazę zgodnie z dokumentacją.

Po odtworzeniu należy sprawdzić numerację dokumentów, stany magazynowe, rozrachunki, użytkowników oraz poprawność wydruków i eksportów. Dopiero po takiej kontroli można przekazać system do normalnej pracy. Dobrze przygotowany plan skraca przestój i ogranicza ryzyko pominięcia ważnych danych.

Najczęstsze błędy przy wykonywaniu kopii

zapisywanie wszystkich kopii na tym samym dysku co działająca baza,
brak kopii przechowywanej poza siedzibą firmy,
kopiowanie aktywnych plików bez zatrzymania programu lub silnika bazy,
nieuwzględnienie plików konfiguracyjnych, licencyjnych i dokumentów dodatkowych,
brak testów odtworzeniowych,
brak powiadomień o nieudanym backupie,
przechowywanie wyłącznie jednej, stale nadpisywanej wersji kopii.

Dobrze skonfigurowana kopia zapasowa powinna być automatyczna, monitorowana i możliwa do odtworzenia w praktyce. Dotyczy to zarówno nowoczesnych systemów opartych na Microsoft SQL Server, jak i starszych programów przechowujących dane w plikach lokalnych. Regularna kontrola konfiguracji, uprawnień, nośników oraz procedury przywracania pozwala ograniczyć skutki awarii i bezpiecznie kontynuować pracę firmy.

Zgłoszenie naprawy: 22 390 56 49 — telefon czynny całą dobę, siedem dni w tygodniu. Sprzęt odbieramy spod wskazanego adresu w Grodzisku Mazowieckim i okolicy.