Baza danych Subiekta GT gromadzi historię sprzedaży, kartoteki kontrahentów i stany magazynowe całej firmy — jej utrata bywa znacznie bardziej dotkliwa niż awaria samego komputera, na którym program działa.

Na czym polega ta usługa

Konfiguracja kopii zapasowej obejmuje ustawienie automatycznego, cyklicznego backupu bazy danych Subiekta GT, przechowywanego zarówno lokalnie, jak i poza komputerem, na którym program pracuje. Sprawdzana jest też integralność wykonanych kopii, żeby mieć pewność, że w razie potrzeby faktycznie da się z nich odtworzyć dane.

Dla kogo ma sens

Usługa jest niezbędna w każdej firmie korzystającej z Subiekta GT, niezależnie od wielkości — utrata bazy sprzedażowej oznacza nie tylko przestój, ale też realne ryzyko prawne przy braku dokumentacji sprzedaży.

Ile to trwa

Konfiguracja kopii zapasowej to zabieg realizowany zwykle do 24 godzin od przyjęcia zgłoszenia.

Warunki

Diagnoza wstępna i wycena są bezpłatne. Dojazd na terenie Warszawy i okolic jest bezpłatny, a usługa objęta jest gwarancją do 12 miesięcy.

Struktura bazy danych Subiekta GT i mechanizmy archiwizacji

Oprogramowanie Subiekt GT wchodzące w skład pakietu InsERT GT opiera swoje działanie na relacyjnym silniku bazodanowym Microsoft SQL Server (system zarządzania relacyjnymi bazami danych odpowiadający za spójność, indeksowanie i bezpieczne przechowywanie informacji). Każdy podmiot, czyli indywidualna baza danych konkretnej firmy, składa się z dwóch kluczowych plików fizycznych zapisanych na dysku serwera: pliku głównego z rozszerzeniem .mdf (Master Data File, przechowujący tabele, kartoteki towarowe, dane kontrahentów, rozrachunki oraz pełną historię dokumentów handlowych i magazynowych) oraz pliku dziennika transakcji z rozszerzeniem .ldf (Log Data File, rejestrujący wszystkie bieżące operacje wprowadzane do bazy danych przed ich trwałym zatwierdzeniem).

Do podstawowego zarządzania kopiami zapasowymi producent oprogramowania dostarcza narzędzie Archiwizator (wbudowany moduł administracyjny pakietu InsERT GT). Narzędzie to pozwala na tworzenie skompresowanych archiwów z rozszerzeniem .iar lub standardowych plików kopii bazodanowej z rozszerzeniem .bak (natywny format kopii zapasowej silnika Microsoft SQL Server) wraz z plikiem nagłówkowym w formacie .xml zawierającym metadane o wersji podmiotu i parametrach archiwizacji.

W środowiskach firmowych najczęściej wykorzystywana jest bezpłatna edycja silnika bazodanowego Microsoft SQL Server Express. Wersja ta charakteryzuje się ograniczeniami technicznymi, takimi jak limit pamięci operacyjnej przydzielanej dla pojedynczej instancji oraz maksymalny rozmiar pojedynczej bazy danych wynoszący 10 GB. Co istotne, edycja Express nie posiada wbudowanej usługi SQL Server Agent (modułu odpowiedzialnego za automatyczne planowanie i wykonywanie zadań w tle). Z tego powodu konfiguracja automatycznych, regularnych kopii zapasowych wymaga zastosowania dedykowanych skryptów systemowych lub zewnętrznych mechanizmów harmonogramowania.

Warianty zabezpieczania danych i schematy tworzenia kopii

Właściwe zabezpieczenie systemu Subiekt GT wymaga wdrożenia schematu archiwizacji dopasowanego do infrastruktury sprzętowej oraz trybu pracy przedsiębiorstwa. Wyróżnia się kilka głównych wariantów tworzenia kopii bezpieczeństwa:

Automatyzacja natywnych zrzutów bazodanowych za pomocą skryptów T-SQL i Harmonogramu zadań systemu Windows (Windows Task Scheduler, systemowe narzędzie służące do cyklicznego uruchamiania zdefiniowanych operacji o wyznaczonych godzinach). Wykorzystanie skryptów współpracujących z narzędziem SQLCMD (konsolowy interfejs do komunikacji z serwerem SQL) umożliwia wykonywanie pełnych kopii zapasowych w formacie .bak z kompresją danych, nadawaniem znaczników czasowych w nazwach plików oraz automatycznym usuwaniem najstarszych archiwów po upływie określonej liczby dni.

Cykliczna archiwizacja z poziomu narzędzia Archiwizator GT uruchamianego w trybie wsadowym z parametrami wiersza poleceń. Rozwiązanie to pozwala na wygenerowanie kompletnych paczek .iar zabezpieczonych hasłem szyfrującym, które mogą być następnie automatycznie przenoszone do katalogów docelowych przez skrypty powłoki systemowej.

Wdrożenie strategii kopii zapasowych opartej na regule 3-2-1 (standard bezpieczeństwa danych zalecający posiadanie trzech kopii informacji na dwóch różnych nośnikach danych, w tym jednej kopii przechowywanej poza główną siedzibą firmy). W ramach tego schematu pierwsza kopia powstaje na dedykowanym dysku serwera bazodanowego, druga jest przesyłana przez lokalną sieć na serwer dyskowy NAS (Network Attached Storage, samodzielne urządzenie pamięci masowej podłączone do sieci firmowej), natomiast trzecia kopia trafia w formie zaszyfrowanej do zewnętrznej, bezpiecznej chmury obliczeniowej lub na zdalny serwer zapasowy.

Kopie migawkowe na poziomie wirtualizatora (mechanizm tworzenia obrazu całej maszyny wirtualnej w określonym punkcie czasu) w środowiskach takich jak Microsoft Hyper-V lub Proxmox. Aby zrzut wirtualnego dysku z bazą SQL był spójny, konieczna jest poprawna konfiguracja usługi VSS (Volume Shadow Copy Service, systemowa usługa kopiowania woluminów w tle), która zapewnia zamrożenie zapisu na czas tworzenia migawki i zapobiega powstawaniu uszkodzeń w strukturze bazy.

Typowe błędy popełniane przy samodzielnym tworzeniu kopii Subiekta GT

Próby samodzielnego zabezpieczania danych bez odpowiedniego przygotowania technicznego często prowadzą do powstawania pozornego poczucia bezpieczeństwa. W praktyce serwisowej obserwuje się powtarzające się błędy:

Przechowywanie kopii zapasowych wyłącznie na tym samym dysku fizycznym lub partycji, na której działa aktywna baza danych. W przypadku awarii mechanicznej dysku HDD, uszkodzenia kontrolera pamięci SSD lub ataku złośliwego oprogramowania szyfrującego dane (programy typu ransomware blokujące dostęp do plików dla wymuszenia okupu), przedsiębiorstwo traci jednocześnie bieżący podmiot handlowy oraz całą historię kopii zapasowych.

Ręczne kopiowanie plików bazy .mdf oraz .ldf przy uruchomionej usłudze serwera SQL. W trakcie pracy silnika bazodanowego pliki te są stale otwarte w trybie wyłącznym przez proces serwera. Kopiowanie ich za pomocą standardowego eksploratora plików systemu Windows bez wcześniejszego prawidłowego zatrzymania usługi lub odłączenia bazy (operacja Detach) prowadzi do powstania niespójnej kopii, której nie da się poprawnie podłączyć na innym komputerze.

Brak regularnego testowania procedury odzyskiwania danych (ang. test restore). Sam fakt obecności pliku w katalogu kopii zapasowych nie gwarantuje, że proces archiwizacji przebiegł pomyślnie. Zdarzają się sytuacje, w których z powodu błędów uprawnień systemowych, braku wolnego miejsca lub uszkodzeń sektorów nośnika generowane pliki mają rozmiar 0 bajtów lub zawierają błędy sum kontrolnych CRC (algorytm wykrywania błędów w zapisie danych).

Pomijanie zasobów powiązanych z programem Subiekt GT znajdujących się poza bazą danych SQL. System przechowuje wiele elementów w dedykowanych folderach systemowych. Należą do nich pliki biblioteki dokumentów (załączniki PDF, skany umów, dokumentacja techniczna towarów), zmodyfikowane wzorce wydruków graficznych, szablony dokumentów eksportowych oraz pliki certyfikatów i kluczy uwierzytelniających wykorzystywanych do komunikacji z platformą Krajowego Systemu e-Faktur (KSeF) lub systemami bankowości elektronicznej.

Brak szyfrowania plików archiwów i stosowanie domyślnych haseł dostępowych. Baza danych Subiekta GT zawiera newralgiczne informacje handlowe, wykazy cen zakupu i marż oraz dane osobowe klientów i pracowników podlegające ochronie prawnej w ramach przepisów RODO (Ogólne Rozporządzenie o Ochronie Danych Osobowych). Przechowywanie niezaszyfrowanych kopii w ogólnodostępnych zasobach sieciowych stwarza ryzyko wycieku danych.

Kiedy problemem nie jest brak kopii, lecz stan bazy danych

Podczas diagnozowania problemów z działaniem programu Subiekt GT istotne jest odróżnienie awarii nośnika lub braku archiwum od usterek samej struktury bazy danych. Występują sytuacje, w których wykonywanie kopii zapasowej w standardowy sposób jedynie utrwala istniejący problem:

Uszkodzenie spójności logicznej lub fizycznej tabel i indeksów. Objawia się to komunikatami o błędach transakcji podczas wystawiania faktur, prób zamykania okresów rozliczeniowych lub sporządzania zestawień magazynowych. W takiej sytuacji wykonanie kopii zapasowej przenosi uszkodzenia do pliku archiwum. Weryfikację poprawności struktury przeprowadza się za pomocą poleceń diagnostycznych, takich jak DBCC CHECKDB (instrukcja weryfikująca integralność alokacji i spójność strukturalną wszystkich obiektów w bazie danych). Usunięcie usterek wymaga przeprowadzenia naprawy bazy w trybie jednoosobowym lub odbudowy uszkodzonych indeksów.

Wyczerpanie limitu pojemności w darmowej edycji Microsoft SQL Server Express. Wersja bezpłatna silnika posiada sztywno zdefiniowany limit rozmiaru pliku danych .mdf wynoszący 10 GB. Po osiągnięciu tej wartości program Subiekt GT zgłasza błędy zapisu i uniemożliwia dodawanie nowych dokumentów handlowych. Problem ten nie wynika z awarii bazy, lecz z osiągnięcia limitu licencyjnego. Rozwiązaniem jest przeprowadzenie archiwizacji i usunięcie zbędnych danych historycznych, wykonanie kompaktowania bazy lub migracja środowiska do komercyjnej wersji Microsoft SQL Server Standard.

Nadmierny rozrost pliku dziennika transakcji .ldf blokujący przestrzeń dyskową. Ustawienie pełnego modelu odzyskiwania bazy danych (Full Recovery Model) bez jednoczesnego wdrożenia regularnych kopii dziennika transakcji powoduje, że plik .ldf nieustannie rośnie, osiągając nierzadko rozmiary wielokrotnie przewyższające samą bazę danych. Doprowadza to do zapełnienia całego dysku twardego serwera i zablokowania pracy wszystkich stanowisk w firmie.

Procedura weryfikacji i awaryjnego odzyskiwania danych

W sytuacji awarii sprzętowej, uszkodzenia systemu operacyjnego lub ataku złośliwego oprogramowania kluczowe znaczenie ma bezpieczna i sprawdzona procedura przywracania danych:

Weryfikacja integralności pliku archiwum przed próbą jego wdrożenia. Za pomocą poleceń środowiska SQL Server, takich jak RESTORE HEADERONLY oraz RESTORE VERIFYONLY (funkcje odczytujące nagłówek kopii zapasowej i sprawdzające zgodność sum kontrolnych bez faktycznego zapisywania bazy na dysku), potwierdza się spójność pliku i brak uszkodzeń w strukturze zrzutu.

Odtworzenie bazy do środowiska pomocniczego z nową nazwą podmiotu. Procedura ta gwarantuje, że proces przywracania danych nie nadpisze istniejących plików roboczych i pozwoli na zweryfikowanie zawartości archiwum przed jego ostatecznym udostępnieniem użytkownikom.

Przeprowadzenie czynności konserwacyjnych z poziomu Programu Serwisowego InsERT GT. Po poprawnym odtworzeniu bazy wykonywane są procedury kontrolne, takie jak kompaktowanie podmiotu (porządkowanie przestrzeni dyskowej), reindeksacja tabel (odbudowa struktur wyszukiwania danych) oraz kontrola spójności stanów magazynowych i rozrachunków.

Konfiguracja parametrów połączenia na stanowiskach klienckich. Po przywróceniu sprawności bazy na serwerze głównym lub maszynie zapasowej weryfikowana jest poprawność konfiguracji sieciowej, ustawienia zapory sieciowej (odblokowanie portu TCP 1433 oraz usługi SQL Server Browser na porcie UDP 1434) oraz stabilność połączeń ze stanowisk sprzedażowych i magazynowych.

Dodatkowe pytania dotyczące zabezpieczania Subiekta GT

Czy wykonanie kopii zapasowej wymaga zamknięcia programu na wszystkich stanowiskach w firmie?

W przypadku korzystania z tradycyjnego narzędzia Archiwizator uruchamianego z poziomu interfejsu graficznego programu Subiekt GT wymagana jest wyłączność na bazie danych, co oznacza konieczność zakończenia pracy i wylogowania wszystkich użytkowników w sieci. Z kolei wdrożenie zautomatyzowanego schematu opartego na natywnych poleceniach silnika Microsoft SQL Server pozwala na wykonywanie kopii zapasowych w tle podczas normalnego funkcjonowania przedsiębiorstwa, bez zakłócania pracy sprzedawców, magazynierów i księgowości.

Gdzie powinny być bezpiecznie przechowywane pliki z kopiami zapasowymi bazy danych?

Prawidłowo zaprojektowany schemat archiwizacji zakłada przechowywanie danych w co najmniej dwóch niezależnych lokalizacjach poza dyskiem głównym serwera bazodanowego. Standardem jest przesyłanie kopii do lokalnego serwera plików NAS podłączonego do wydzielonego segmentu sieci firmowej oraz równoległa wysyłka zaszyfrowanego archiwum do bezpiecznego magazynu w chmurze lub na zewnętrzny serwer zapasowy. Pliki opuszczające sieć lokalną muszą być bezwzględnie zabezpieczone silnym algorytmem szyfrującym (np. AES-256), co uniemożliwia odczytanie poufnych informacji handlowych w razie przechwycenia nośnika.

Czym różni się archiwum z rozszerzeniem .iar od pliku .bak?

Plik z rozszerzeniem .iar to format tworzony przez dedykowane narzędzie Archiwizator wchodzące w skład pakietu InsERT GT. Zawiera on skompresowaną zawartość bazy oraz plik konfiguracyjny XML z metadanymi podmiotu. Plik z rozszerzeniem .bak jest natywnym formatem kopii zapasowej generowanym bezpośrednio przez silnik bazodanowy Microsoft SQL Server. Obydwa formaty umożliwiają pełne odzyskanie danych, jednak format .bak oferuje znacznie większe możliwości automatyzacji zadań administracyjnych, kompresji w locie oraz integracji z profesjonalnymi systemami backupu.

Jak często należy wykonywać archiwizację w firmie handlowej?

Częstotliwość wykonywania kopii zapasowej zależy od intensywności operacji handlowych i magazynowych w firmie. W przedsiębiorstwach o ciągłym ruchu sprzedażowym optymalnym rozwiązaniem jest tworzenie pełnej kopii bazy codziennie po zakończeniu dnia roboczego oraz dodatkowych kopii różnicowych lub kopii dziennika transakcji co kilka godzin w trakcie pracy. Pozwala to na ograniczenie potencjalnej straty danych do maksymalnie kilkudziesięciu minut w razie nagłej awarii sprzętowej serwera.

Co zrobić w sytuacji, gdy plik dziennika transakcji .ldf zajmuje zbyt dużo miejsca na dysku?

Nadmierny rozrost pliku .ldf jest skutkiem ustawienia pełnego modelu odzyskiwania bazy (Full Recovery Model) bez skonfigurowanego harmonogramu czyszczenia dziennika transakcji. W celu odzyskania wolnej przestrzeni dyskowej należy zmienić model odzyskiwania bazy na prosty (Simple Recovery Model) w programie SQL Server Management Studio, a następnie wykonać operację zmniejszania pliku dziennika (procedura Shrink File). Zabieg ten natychmiast zwalnia miejsce na dysku, zachowując pełną integralność wszystkich danych handlowych.

Zasady bezpiecznego przechowywania danych handlowych i ciągłości pracy

Prawidłowo wdrożony system automatycznej archiwizacji danych z programu Subiekt GT stanowi podstawowy warunek stabilnego i bezpiecznego funkcjonowania przedsiębiorstwa handlowo-usługowego. Chroni firmę przed kosztownymi przestojami, utratą kartotek towarowych i historii rozrachunków oraz gwarantuje zgodność z przepisami dotyczącymi przechowywania dokumentacji skarbowej. W przypadku konieczności przeprowadzenia audytu obecnych procedur backupu, wdrożenia automatycznych skryptów archiwizacyjnych lub awaryjnego odzyskania danych po awarii sprzętowej, technicy realizują kompleksowe prace wdrożeniowe bezpośrednio w siedzibie klienta. Dojazd realizowany jest na terenie całej Warszawy oraz w promieniu do 40 kilometrów w okolicznych powiatach (grodziski, legionowski, otwocki, piaseczyński, pruszkowski, warszawski zachodni, wołomiński), a punktem wyjazdu zespołu serwisowego jest biuro przy Alei Stanów Zjednoczonych 72.

22 378 48 09

Kopie zapasowe i archiwizacja danych z Subiekta GT