Kopie zapasowe bazy danych Subiekta GT

Utrata bazy jest gorsza niż awaria sprzętu

Komputer da się kupić w jeden dzień. Historii sprzedaży, stanów magazynowych i rozrachunków całej firmy nie da się odtworzyć w żaden sposób, jeśli nie ma kopii. To jedyny element środowiska, którego utrata bywa nieodwracalna.

Najczęstsza luka

Kopia obejmująca „folder z dokumentami" i pomijająca bazę. Program trzyma dane w miejscu, o którym użytkownik zwykle nie wie — po awarii okazuje się, że kopiowano wszystko poza tym, co było najważniejsze. Sprawdzamy to jako pierwszą rzecz przy każdym przeglądzie.

Jak układamy kopie

• Kopia bazy wykonywana codziennie, po zakończeniu pracy.
• Kopia okresowa przechowywana poza siedzibą firmy.
• Przynajmniej jedna wersja odłączona od sieci — inaczej oprogramowanie szyfrujące obejmie także kopie.
• Powiadomienie, gdy kopia się nie wykona.
• Kontrola rozmiaru — nagły spadek oznacza zwykle, że kopia zawiera mniej, niż powinna.

Próba odtworzenia

Kopia, z której nikt nigdy niczego nie odtworzył, jest wyłącznie założeniem. Wykonujemy próbne odtworzenie okresowo, na osobnym środowisku — to jedyny sposób, żeby wiedzieć, że rozwiązanie działa, zanim będzie potrzebne.

Ile pracy można stracić

Tyle, ile dzieli jedną kopię od następnej. Przy kopii codziennej to jeden dzień wystawiania dokumentów — do odtworzenia z papieru, ale wykonalne. Przy kopii miesięcznej rozmowa wygląda zupełnie inaczej.

Po awarii

Sprawdzamy zasilanie awaryjne serwera. Najczęstszą przyczyną uszkodzenia bazy jest nagłe wyłączenie w trakcie zapisu.

Co rzeczywiście trzeba zabezpieczyć

Subiekt GT korzysta z bazy danych obsługiwanej przez Microsoft SQL Server, czyli system odpowiedzialny za przechowywanie i udostępnianie danych programu. Zwykłe skopiowanie skrótu do aplikacji, jej katalogu instalacyjnego albo plików widocznych w folderze użytkownika nie zabezpiecza podmiotu. Podmiot to firmowa baza zawierająca między innymi dokumenty, kartoteki, rozrachunki i informacje magazynowe.

Zakres zabezpieczenia powinien wynikać z faktycznej konfiguracji. W jednej firmie działa tylko jeden podmiot, a w innej kilka oddzielnych baz, na przykład dla różnych spółek. Każda używana baza musi zostać ujęta w harmonogramie. Trzeba również sprawdzić, czy kopia obejmuje dodatkowe dane potrzebne do pracy, takie jak pliki wymiany, wzorce dokumentów, raporty własne lub materiały przechowywane poza bazą.

Nie należy przy tym zakładać, że kopia całego dysku automatycznie rozwiązuje problem. Obraz dysku, czyli zapis jego zawartości przeznaczony do odtworzenia komputera, może być ważną częścią ochrony. Nadal wymaga jednak kontroli spójności i próby odzyskania danych. Oddzielna kopia bazy ułatwia przywrócenie samego środowiska Subiekta GT bez odtwarzania całego komputera.

Warianty kopii i ich różne zadania

Kopia wykonywana po zakończeniu pracy chroni przed skutkami awarii, która wydarzy się następnego dnia. Nie zastępuje jednak archiwum przechowywanego przez dłuższy czas. Jeśli błąd w danych zostanie zauważony dopiero po kilku dniach, wszystkie najnowsze kopie mogą już zawierać ten sam problem. Dlatego potrzebne są wersje z różnych okresów, a nie jeden plik stale zastępowany nowym.

Inne zadanie ma kopia lokalna, a inne kopia znajdująca się poza miejscem pracy. Lokalna wersja pozwala szybko rozpocząć odzyskiwanie po awarii komputera lub serwera. Kopia zewnętrzna chroni także wtedy, gdy niedostępne staje się całe miejsce pracy albo uszkodzeniu ulega kilka urządzeń jednocześnie. Nie powinna pozostawać stale podłączona do tego samego komputera i dostępna na tych samych prawach użytkownika.

Osobną kategorią jest kopia niezmienna lub odłączona. Niezmienność oznacza, że zapisanej wersji nie można od razu nadpisać lub usunąć ze zwykłego konta. Odłączenie oznacza fizyczne albo logiczne odseparowanie nośnika od działającej sieci. Takie rozwiązanie ogranicza ryzyko, że awaria, pomyłka użytkownika albo złośliwe oprogramowanie uszkodzi jednocześnie dane robocze i wszystkie ich kopie.

Automatyzacja nie zwalnia z kontroli

Automatyczny harmonogram ogranicza zależność od pamięci pracownika, ale sam wpis w harmonogramie nie potwierdza wykonania kopii. Zadanie może się uruchomić i zakończyć błędem z powodu braku miejsca, utraty dostępu do folderu docelowego, problemu z kontem usługi albo niedostępnego nośnika. Dlatego wynik operacji musi być rejestrowany i sprawdzany.

Powiadomienie o błędzie powinno trafić do osoby, która potrafi ocenić przyczynę i doprowadzić do ponownego wykonania zadania. Brak wiadomości także nie zawsze oznacza sukces. Niesprawny mechanizm wysyłania powiadomień może ukrywać awarie. Kontrola powinna więc obejmować zarówno komunikat końcowy, jak i obecność nowego pliku, datę jego utworzenia oraz rozsądny rozmiar w porównaniu z wcześniejszymi wersjami.

Sam wzrost pliku nie dowodzi jeszcze, że baza nadaje się do użycia. Jest jednak użytecznym sygnałem kontrolnym. Plik wyraźnie mniejszy niż zwykle, zerowy rozmiar albo brak kolejnej wersji wymagają sprawdzenia. Nie warto czekać z tym do momentu, w którym kopia będzie potrzebna po rzeczywistej awarii.

Błędy przy samodzielnym zabezpieczaniu danych

Częstym błędem jest kopiowanie plików bazy bez zatrzymania odpowiednich usług lub bez użycia mechanizmu przygotowanego do tworzenia kopii. Baza może być wtedy aktywnie używana, a część danych pozostawać w trakcie zapisu. Powstały zestaw plików może wyglądać prawidłowo, lecz nie zapewniać spójnego punktu odtworzenia. Bezpieczniej korzystać z procedury kopii obsługiwanej przez silnik bazy lub funkcję archiwizacji przewidzianą dla programu.

Drugim błędem jest przechowywanie wszystkich wersji na tym samym dysku co dane robocze. Awaria tego nośnika usuwa wtedy zarówno bazę, jak i jej zabezpieczenie. Podobnie działa zapis na drugim folderze tej samej partycji. Partycja to wydzielony logicznie obszar nośnika, a nie niezależne urządzenie chroniące przed jego fizycznym uszkodzeniem.

Ryzykowne jest także pozostawienie zewnętrznego dysku podłączonego bez przerwy. Ułatwia to codzienny zapis, ale wystawia kopie na skutki przepięcia, błędnego usunięcia plików i szyfrowania przez złośliwe oprogramowanie. Rozwiązaniem nie jest rezygnacja z automatyzacji, lecz uzupełnienie jej o co najmniej jedną okresową wersję niedostępną dla zwykłego konta i odłączoną od bieżącego środowiska.

Kolejny problem to ręczne nadawanie wszystkim plikom tej samej nazwy i zastępowanie poprzedniej kopii. Jedna pomyłka może wtedy usunąć ostatnią działającą wersję. Nazwa zawierająca datę ułatwia zachowanie historii oraz ustalenie, z jakiego momentu pochodzą dane. Zasady przechowywania powinny też określać, które starsze wersje pozostają dostępne.

Jak wygląda wiarygodna próba odtworzenia

Test nie powinien nadpisywać działającej bazy. Kopię odtwarza się w odseparowanym środowisku, czyli na przygotowanym stanowisku lub instancji testowej, która nie zakłóca codziennej pracy. Instancja to oddzielnie działające środowisko silnika bazy danych. Po odtworzeniu sprawdza się, czy baza jest dostępna oraz czy można otworzyć podmiot i odczytać podstawowe informacje.

Weryfikacja obejmuje więcej niż pojawienie się komunikatu o zakończeniu operacji. Trzeba sprawdzić przykładowe dokumenty z ostatniego okresu objętego kopią, kartoteki, stany magazynowe i rozrachunki istotne dla danej firmy. Chodzi o potwierdzenie, że odzyskana zawartość odpowiada oczekiwanemu momentowi, a nie tylko o techniczne dołączenie pustej albo nieaktualnej bazy.

Próba pozwala również wykryć brakujące informacje organizacyjne. Może się okazać, że plik istnieje, ale nikt nie zna miejsca jego przechowywania, sposobu odszyfrowania albo konta potrzebnego do odtworzenia. Procedura powinna opisywać lokalizację kopii, osoby odpowiedzialne i kolejność czynności. Dane dostępowe muszą być chronione, lecz nie mogą zależeć wyłącznie od pamięci jednej osoby.

Kiedy problem nie dotyczy samej kopii bazy

Brak możliwości uruchomienia Subiekta GT nie zawsze oznacza utratę danych. Przyczyną może być niedostępność serwera, problem z siecią, zatrzymana usługa SQL Server albo nieprawidłowa konfiguracja połączenia. W takiej sytuacji baza może nadal istnieć i być sprawna. Nie należy od razu tworzyć nowego podmiotu ani instalować wszystkiego od początku, ponieważ utrudnia to rozpoznanie pierwotnej konfiguracji.

Komunikaty pojawiające się podczas pracy mogą też wynikać z braku miejsca na dysku, uszkodzenia systemu plików lub problemów z samym komputerem. System plików to sposób organizowania danych na nośniku. Najpierw trzeba ustalić, czy problem dotyczy programu, połączenia, silnika bazy czy urządzenia przechowującego dane. Dopiero potem wybiera się właściwą metodę naprawy albo odtworzenia.

Nie każda niezgodność w kartotece jest awarią techniczną. Błędny stan magazynowy może wynikać z dokumentu wprowadzonego z nieprawidłową datą, niewłaściwego magazynu albo pomyłki podczas ewidencji. Przywrócenie starszej kopii bez analizy mogłoby usunąć późniejsze, prawidłowe dokumenty. W takim przypadku najpierw ustala się źródło różnicy i zakres zmian.

Dodatkowe pytania o kopie Subiekta GT

Czy synchronizacja folderu z chmurą wystarczy?

Synchronizacja może być jednym z elementów zabezpieczenia, ale nie zastępuje poprawnie wykonanej kopii bazy. Jeżeli do synchronizowanego folderu trafi plik niepełny, uszkodzony albo zaszyfrowany, taka sama wersja może zostać przesłana dalej. Trzeba również sprawdzić historię wersji, uprawnienia dostępu i możliwość odzyskania pliku po przypadkowym usunięciu.

Czy kopię należy wykonywać, gdy wszyscy zakończą pracę?

Wykonanie zadania po zakończeniu pracy upraszcza organizację i ogranicza liczbę zmian zachodzących w czasie operacji. Właściwy mechanizm kopii silnika bazy jest jednak przygotowany do zachowania spójności danych. Harmonogram trzeba dopasować do sposobu działania firmy, zwłaszcza gdy program jest używany przez wiele stanowisk albo przez większą część doby.

Czy wystarczy zachować tylko najnowszą wersję?

Nie. Najnowsza kopia może już zawierać błąd, który został zauważony z opóźnieniem. Może też zostać uszkodzona podczas zapisu. Kilka wersji z różnych dni i okresów daje możliwość wyboru punktu sprzed wystąpienia problemu. Dokładny sposób rotacji, czyli zastępowania starszych kopii nowszymi, powinien odpowiadać rytmowi pracy i znaczeniu danych.

Czy kopia chroni przed błędnym dokumentem wystawionym przez użytkownika?

Kopia umożliwia powrót do wcześniejszego stanu całej bazy, ale nie zawsze jest najlepszym sposobem poprawienia pojedynczego dokumentu. Odtworzenie starszej wersji usuwa także wszystkie prawidłowe operacje wykonane później. Najpierw trzeba ocenić, czy błąd można skorygować w programie bez cofania całej bazy.

Co przygotować przed zmianą komputera lub serwera?

Potrzebna jest aktualna, sprawdzona kopia wszystkich używanych podmiotów oraz informacje o konfiguracji środowiska. Kopię należy przechować niezależnie od wymienianego urządzenia. Po migracji, czyli przeniesieniu programu i danych do nowego środowiska, trzeba potwierdzić dostęp do podmiotów oraz poprawność podstawowych danych przed wycofaniem starego sprzętu.

Kopia ma wartość dopiero po udanym odtworzeniu

Skuteczne zabezpieczenie bazy Subiekta GT składa się z poprawnego mechanizmu kopii, kilku wersji, oddzielnego miejsca przechowywania, kontroli wykonania i regularnej próby odtworzenia. Każdy z tych elementów usuwa inne ryzyko. Sam plik widoczny na dysku nie daje jeszcze pewności, że po awarii firma odzyska dokumenty, kartoteki, rozrachunki i ciągłość pracy. Pewność daje dopiero sprawdzona procedura, którą można wykonać również wtedy, gdy podstawowy komputer lub serwer przestanie działać.