Backup bazy Subiekta GT i nexo - jak często wykonywać kopię i jak ją sprawdzić?

Backup bazy Subiekta GT lub Subiekta nexo powinien być wykonywany regularnie, automatycznie i w taki sposób, aby można było go odtworzyć po awarii. Sama informacja, że „kopie się robią”, nie wystarcza. Najważniejsze pytanie brzmi: czy firma potrafi przywrócić dane, gdy komputer, serwer albo baza przestanie działać?

Dane w Subiekcie są dla wielu firm krytyczne. Znajdują się tam dokumenty sprzedaży, kontrahenci, magazyn, faktury, towary, historia operacji i informacje potrzebne do codziennej pracy. Utrata bazy może oznaczać przestój, ręczne odtwarzanie dokumentów i poważne problemy organizacyjne.

Warto rozróżnić dwie rzeczy: archiwizację wykonaną z poziomu programu i backup całego serwera. Archiwizacja Subiekta dotyczy przede wszystkim bazy programu. Jest bardzo ważna, ale nie zawsze obejmuje całe środowisko pracy, ustawienia systemowe, dodatkowe pliki, integracje, certyfikaty, skrypty, eksporty czy konfigurację urządzeń.

Backup całego serwera obejmuje szerszy zakres. Może pozwolić odtworzyć nie tylko samą bazę, ale też środowisko, w którym program działał. W praktyce najlepsze podejście często łączy oba poziomy: regularną archiwizację bazy oraz backup serwera lub środowiska, na którym działa program.

Częstotliwość kopii zależy od tego, ile danych firma jest gotowa stracić w razie awarii. Jeżeli firma wystawia kilka dokumentów miesięcznie, inna częstotliwość będzie akceptowalna niż w sklepie lub hurtowni, gdzie dokumenty powstają przez cały dzień.

Dla większości firm codzienny backup powinien być minimum. W środowiskach intensywnie pracujących warto rozważyć częstsze kopie lub dodatkowe mechanizmy zabezpieczenia. Najważniejsze jest to, aby częstotliwość kopii odpowiadała realnej wartości danych tworzonych w ciągu dnia.

Retencja oznacza czas przechowywania kopii zapasowych. Błędem jest trzymanie wyłącznie jednej najnowszej kopii. Jeżeli baza zostanie uszkodzona, a system nadpisze jedyną dobrą kopię nową, uszkodzoną wersją, firma może stracić możliwość powrotu do sprawnego stanu.

Lepszym rozwiązaniem jest przechowywanie kilku wersji kopii: na przykład z ostatnich dni, tygodni i wybranych okresów miesięcznych. Dzięki temu można wrócić nie tylko do kopii z wczoraj, ale też do starszego punktu, jeżeli problem został zauważony z opóźnieniem.

Backup przechowywany wyłącznie na tym samym komputerze lub serwerze nie wystarcza. Jeżeli uszkodzi się dysk, dojdzie do kradzieży sprzętu, awarii systemu albo zaszyfrowania danych przez złośliwe oprogramowanie, lokalna kopia może zniknąć razem z oryginałem.

Dlatego kopie powinny być przechowywane również poza głównym środowiskiem. Może to być inny serwer, zasób backupowy, zewnętrzna lokalizacja albo rozwiązanie chmurowe. Ważne, aby kopia nie była stale dostępna w taki sam sposób jak dane produkcyjne, bo wtedy może zostać uszkodzona razem z nimi.

Najbardziej niedoceniany element backupu to test odtwarzania. Kopia, której nikt nigdy nie próbował przywrócić, jest tylko założeniem. Może okazać się uszkodzona, niepełna, zaszyfrowana, zapisana w złym miejscu albo wykonana z niewłaściwej bazy.

Test odtwarzania nie musi oznaczać wielkiej operacji. Wystarczy okresowo sprawdzić, czy z kopii można odtworzyć bazę w środowisku testowym i czy program widzi dane poprawnie. Taki test daje dużo większą pewność niż samo sprawdzenie, że plik backupu istnieje.

RPO oznacza, ile danych firma może stracić. Jeżeli backup jest wykonywany raz dziennie wieczorem, a awaria nastąpi pod koniec dnia, można stracić dane z całego dnia pracy. Jeżeli firma nie może sobie na to pozwolić, kopie muszą być częstsze.

RTO oznacza, jak szybko firma musi wrócić do pracy po awarii. Inaczej planuje się backup, jeżeli dopuszczalny przestój to jeden dzień, a inaczej, jeżeli firma musi działać po godzinie. Te dwa pojęcia pomagają spojrzeć na backup biznesowo, a nie tylko technicznie.

Najczęstszy błąd to poleganie na ręcznym backupie wykonywanym wtedy, gdy ktoś sobie przypomni. Drugi problem to zapisywanie kopii na tym samym dysku, na którym działa baza. Trzeci to brak kontroli, czy kopia faktycznie się wykonała. Czwarty to brak testów odtwarzania.

Często zdarza się też, że firma ma kilka baz, ale kopiuje tylko jedną. Albo wykonuje archiwizację starej bazy testowej, a aktualna baza produkcyjna pozostaje bez zabezpieczenia. Przy migracjach i zmianach serwera warto szczególnie uważać, aby backup obejmował właściwe dane.

Praca w chmurze może uprościć temat backupu, jeżeli usługa obejmuje automatyczne kopie, retencję, monitoring i możliwość odtworzenia danych. Nie zwalnia to jednak firmy z pytania, co dokładnie jest kopiowane, jak często, jak długo przechowywane i jak wygląda procedura przywracania.

Dobrze przygotowany backup bazy Subiekta GT lub nexo powinien być niewidoczny na co dzień, ale bardzo konkretny w razie awarii. Firma nie powinna wtedy dopiero szukać pliku kopii i zastanawiać się, czy jest aktualny. Backup ma dawać spokój, a nie fałszywe poczucie bezpieczeństwa.