Kopie zapasowe systemów handlowych

Problem nie polega na braku kopii

W większości firm kopie istnieją. Rzecz w tym, że nikt nigdy nie sprawdził, czy da się z nich cokolwiek odtworzyć — a awaria jest wtedy pierwszym testem i bywa zarazem ostatnim.

Co sprawdzamy w istniejącym rozwiązaniu

• Czy kopie faktycznie powstają, czy zatrzymały się kilka miesięcy temu.
• Czy obejmują bazy programów, a nie tylko folder z dokumentami.
• Czy istnieje wersja odłączona od sieci.
• Ile pracy dzieli jedną kopię od następnej.
• Ile czasu zajęłoby odtworzenie pracy po awarii.
• Czy ktokolwiek dostaje powiadomienie, gdy kopia się nie wykona.

Najczęstsza luka

Kopia pomijająca bazę danych. Programy handlowe trzymają dane w miejscu, o którym użytkownik zwykle nie wie — po awarii okazuje się, że zabezpieczano wszystko poza tym, co najważniejsze. Znajdujemy to przy większości pierwszych przeglądów.

Cisza jako sygnał

Kopia, która przestała się wykonywać, nie zgłasza błędu — po prostu milknie. To najczęstszy sposób, w jaki firmy tracą zabezpieczenie, nie wiedząc o tym. Dlatego konfigurujemy powiadomienie także wtedy, gdy nic się nie stało.

Próba odtworzenia

Wykonujemy ją okresowo na osobnym środowisku. To jedyny dowód, że rozwiązanie działa — reszta jest założeniem.

Oprogramowanie szyfrujące

Kopia podłączona na stałe zostanie zaszyfrowana razem z danymi. Przynajmniej jedna wersja musi być odłączona od sieci — to zabezpieczenie ważniejsze dziś niż ochrona przed awarią dysku.

Co naprawdę trzeba zabezpieczyć w systemie handlowym

Program handlowy rzadko składa się wyłącznie z plików widocznych w jednym katalogu. Najważniejsze informacje mogą znajdować się w bazie danych, czyli uporządkowanym zbiorze obsługiwanym przez osobny mechanizm. Oprócz niej potrzebne bywają ustawienia programu, szablony wydruków, pliki wymiany z księgowością, dokumenty dołączone przez użytkowników oraz konfiguracja połączeń z innymi usługami. Samo skopiowanie skrótu z pulpitu albo katalogu instalacyjnego nie zabezpiecza danych przedsiębiorstwa.

Zakres kopii ustala się na podstawie sposobu działania konkretnego środowiska. Inaczej wygląda instalacja używana na jednym komputerze, a inaczej system, w którym kilka stanowisk łączy się z bazą na serwerze. Znaczenie mają również integracje, czyli automatyczne połączenia programu handlowego z magazynem, księgowością, sklepem internetowym, Allegro lub BaseLinkerem. Po odtworzeniu bazy może się okazać, że dane są dostępne, lecz bez dodatkowych ustawień nie działa wymiana zamówień, dokumentów albo stanów magazynowych.

Różne rodzaje kopii i ich zastosowanie

Kopia pełna zawiera cały wskazany zakres danych. Jest czytelna i wygodna podczas odtwarzania, ale zajmuje więcej miejsca. Kopia przyrostowa zapisuje wyłącznie zmiany powstałe od poprzedniej kopii. Pozwala ograniczyć ilość przechowywanych danych, jednak podczas odzyskiwania może wymagać prawidłowego połączenia kilku kolejnych zestawów. Kopia różnicowa obejmuje zmiany od ostatniej kopii pełnej. Każdy z tych wariantów może być poprawny, jeżeli harmonogram, przechowywanie oraz procedura odtworzenia tworzą spójną całość.

Osobnym zagadnieniem jest kopia obrazu systemu. Obraz to zapis całego środowiska komputera lub serwera, obejmujący system, zainstalowane programy i konfigurację. Ułatwia powrót do pracy po uszkodzeniu nośnika, ale nie zawsze zastępuje kopię wykonaną bezpośrednio przez program handlowy albo silnik bazy danych. Najbezpieczniejsze rozwiązanie uwzględnia zarówno możliwość odzyskania pojedynczych danych, jak i odbudowania całego stanowiska.

Spójność bazy ma znaczenie

Zwykłe skopiowanie plików aktywnej bazy podczas pracy użytkowników może utworzyć niespójny zapis. Spójność oznacza, że wszystkie powiązane informacje pochodzą z tego samego, prawidłowo zakończonego momentu pracy. Jeżeli część danych została już zapisana, a część nadal znajduje się w pamięci programu, kopia plikowa może wyglądać poprawnie, lecz nie nadawać się do uruchomienia.

Dlatego sposób wykonywania kopii powinien być dostosowany do używanego systemu i bazy. Czasem właściwe jest narzędzie udostępnione przez producenta programu, czasem mechanizm silnika bazy, a czasem kontrolowane zatrzymanie odpowiednich usług. Usługa to proces działający w tle, który obsługuje program lub bazę bez otwierania osobnego okna. Nie należy jej wyłączać przypadkowo, ponieważ może to przerwać pracę stanowisk albo uszkodzić rozpoczęte operacje.

Jak rozpoznać pozornie poprawną kopię

Obecność nowych plików w katalogu docelowym nie wystarcza do potwierdzenia, że dane są zabezpieczone. Plik może mieć prawidłową nazwę i datę, a jednocześnie być pusty, niekompletny albo zawierać błąd. Może też zabezpieczać niewłaściwą firmę w programie, starą bazę pozostawioną po migracji lub testową instalację, której nikt już nie używa.

Weryfikacja obejmuje porównanie źródła z zakresem kopii, sprawdzenie raportów zadania oraz kontrolę miejsca dostępnego na nośniku. Raport zadania to zapis informujący, czy operacja została rozpoczęta, zakończona i czy wystąpiły problemy. Warto też ustalić, czy pliki nie są automatycznie usuwane zbyt wcześnie oraz czy starsze wersje pozostają dostępne. Nadpisywanie jednego pliku każdego dnia powoduje, że błąd lub uszkodzenie może zastąpić ostatnią sprawną wersję.

Retencja, czyli przechowywanie starszych wersji

Retencja określa, jak długo i ile wcześniejszych kopii pozostaje dostępnych. Nie służy wyłącznie ochronie przed awarią dysku. Błąd w danych może zostać zauważony dopiero po pewnym czasie. Jeżeli wszystkie starsze wersje zostały już usunięte, dostępna pozostaje jedynie kopia zawierająca ten sam problem co środowisko produkcyjne, czyli system używany na co dzień.

Plan przechowywania powinien odpowiadać rytmowi pracy firmy i znaczeniu danych. Trzeba rozważyć, jak często wystawiane są dokumenty, aktualizowane ceny, przyjmowane płatności oraz synchronizowane zamówienia. Ważne jest także rozróżnienie między archiwum a kopią zapasową. Archiwum przechowuje materiały przeznaczone do długiego zachowania, natomiast kopia zapasowa służy do odtworzenia danych lub działania systemu po awarii. Jeden mechanizm nie zawsze realizuje oba cele.

Najczęstsze błędy przy samodzielnym zabezpieczaniu danych

• Kopiowanie wyłącznie katalogu programu bez ustalenia, gdzie znajduje się używana baza danych.
• Trzymanie kopii na drugim folderze tego samego dysku, który może ulec awarii razem z oryginałem.
• Pozostawianie dysku zewnętrznego stale podłączonego do komputera i dostępnego dla oprogramowania szyfrującego.
• Zakładanie, że synchronizacja plików jest pełną kopią zapasową. Synchronizacja, czyli automatyczne wyrównywanie zawartości, może przenieść również omyłkowe usunięcie lub uszkodzenie.
• Ręczne wykonywanie kopii bez harmonogramu i bez kontroli, czy zadanie rzeczywiście zostało zakończone.
• Przechowywanie tylko jednej wersji, stale zastępowanej nowym plikiem.
• Testowanie odzyskiwania bez odseparowania środowiska próbnego od działającego systemu.

Szczególnie ryzykowne jest eksperymentowanie bezpośrednio na jedynej bazie. Próba otwarcia uszkodzonego pliku, aktualizacja programu albo przywrócenie starszej wersji w tym samym miejscu może utrudnić późniejsze odzyskanie danych. Najpierw zabezpiecza się stan zastany, a dopiero potem prowadzi diagnostykę na kopii roboczej.

Kiedy problem nie dotyczy samej kopii

Brak możliwości uruchomienia programu po odtworzeniu nie zawsze oznacza uszkodzenie backupu, czyli kopii zapasowej. Przyczyną może być inna wersja programu, brak wymaganej usługi bazy, zmieniona nazwa serwera, niedostępny folder sieciowy albo niewłaściwe uprawnienia. Uprawnienia określają, które konto może odczytywać, zmieniać lub usuwać dane. Poprawna kopia nie naprawi automatycznie błędnej konfiguracji nowego środowiska.

Podobnie wygląda sytuacja z integracjami. Baza może zostać odtworzona prawidłowo, ale połączenie ze sklepem, usługą księgową lub magazynem nadal wymaga ponownej konfiguracji. Niekiedy potrzebne są klucze dostępowe, czyli dane pozwalające systemom rozpoznać i autoryzować połączenie. Takich informacji nie powinno się zapisywać w przypadkowych plikach ani przesyłać bez zabezpieczenia.

Jak wygląda bezpieczna próba odtworzenia

Test przeprowadza się poza środowiskiem używanym przez pracowników. Przygotowuje się oddzielne stanowisko lub odizolowane środowisko wirtualne, czyli programowo utworzony komputer działający wewnątrz innego systemu. Następnie przywraca się bazę i sprawdza, czy program ją otwiera, czy widoczne są właściwe dane oraz czy można wykonać podstawowe operacje kontrolne bez wpływu na bieżącą pracę.

Nie wystarczy zobaczyć ekran logowania. Kontroli wymagają między innymi kartoteki, dokumenty, rozrachunki, ustawienia firmy i powiązania pomiędzy danymi. Jeżeli zabezpieczane są również załączniki lub własne szablony, trzeba sprawdzić ich dostępność. Wynik testu powinien zostać opisany: z jakiej kopii skorzystano, co odtworzono, jakie kroki były potrzebne i które elementy wymagają poprawy. Taka dokumentacja skraca drogę od awarii do świadomego działania.

Dodatkowe pytania o kopie systemów handlowych

Czy kopia w chmurze wystarczy?

Chmura, czyli zasoby przechowywane na serwerach dostępnych przez internet, może być ważnym elementem zabezpieczenia, ale sama lokalizacja nie przesądza o jakości kopii. Trzeba sprawdzić wersjonowanie, możliwość odzyskania usuniętych danych, sposób szyfrowania oraz procedurę pobrania większego zbioru po awarii. Wersjonowanie pozwala wrócić do wcześniejszej postaci pliku zamiast zachowywać wyłącznie jego najnowszą wersję.

Czy kopię można przechowywać na serwerze używanym przez program?

Taka kopia może przyspieszyć odtworzenie pojedynczego pliku, lecz nie chroni przed awarią całego serwera, kradzieżą ani zaszyfrowaniem wszystkich dostępnych zasobów. Potrzebna jest również wersja znajdująca się poza tym urządzeniem i przynajmniej okresowo odłączona od sieci.

Czy zaszyfrowanie kopii utrudni jej odzyskanie?

Szyfrowanie, czyli przekształcenie danych do postaci nieczytelnej bez właściwego klucza, chroni kopię przed dostępem osób nieuprawnionych. Nie powinno utrudniać odtworzenia, jeżeli klucz lub hasło są bezpiecznie przechowywane, a procedura została przetestowana. Utrata jedynego klucza może jednak uniemożliwić dostęp nawet do poprawnie wykonanych plików.

Czy wystarczy sprawdzać komunikat o powodzeniu zadania?

Komunikat potwierdza wykonanie określonej operacji, ale nie zastępuje próby odtworzenia. Zadanie może poprawnie skopiować niewłaściwy katalog albo bazę, której system już nie używa. Dopiero kontrolowane uruchomienie odzyskanych danych potwierdza, że cały proces ma praktyczną wartość.

Czy podczas konfiguracji kopii potrzebne jest hasło użytkownika?

Nie zakłada się z góry potrzeby przekazywania hasła. Dostęp powinien być ograniczony do zakresu rzeczywiście niezbędnego do konfiguracji lub testu. Jeżeli bez danych uwierzytelniających nie można wykonać konkretnej czynności, najpierw wyjaśnia się ich przeznaczenie i wybiera bezpieczny sposób postępowania.

Kopia jest gotowa dopiero wtedy, gdy można z niej wrócić do pracy

Skuteczne zabezpieczenie systemu handlowego łączy właściwy zakres danych, regularne wykonanie, starsze wersje, odłączoną kopię i sprawdzoną procedurę odtworzenia. Każdy z tych elementów odpowiada na inny rodzaj problemu. Sam plik z aktualną datą nie jest jeszcze dowodem bezpieczeństwa. Dopiero udana próba na oddzielnym środowisku pokazuje, że po awarii dostępne będą nie tylko dane, lecz także realna droga do ponownego uruchomienia sprzedaży, magazynu i rozliczeń.