Baza systemu sprzedażowego jest zwykle najważniejszym plikiem w firmie. Jednocześnie bywa objęta kopią zrobioną raz, przy wdrożeniu.
Kopia spójna
Skopiowanie pliku bazy w trakcie pracy daje kopię uszkodzoną. Potrzebny jest mechanizm własny silnika bazy, wykonujący kopię w stanie spójnym — inaczej odtworzenie się nie powiedzie.
To najczęstszy błąd przy przenoszeniu kopii baz do ogólnego narzędzia archiwizującego. Narzędzie kopiuje plik, raport pokazuje powodzenie, a plik jest bezużyteczny. Właściwa kolejność jest odwrotna: silnik bazy tworzy kopię do pliku, a dopiero ten plik trafia do ogólnego systemu kopii zapasowych i na nośnik poza siedzibą.
Częstotliwość a dziennik transakcji
Pełna kopia raz na dobę oznacza możliwą utratę dnia pracy. Kopie dziennika transakcji wykonywane co kilkadziesiąt minut ograniczają to do minut.
Warunkiem jest odpowiedni tryb pracy bazy — w trybie uproszczonym dziennik nie jest zachowywany i takie kopie po prostu nie powstaną. Trzeba to sprawdzić, bo domyślne ustawienia bywają różne. Drugi warunek to pilnowanie rozmiaru dziennika: przy braku kopii rośnie, aż zabraknie miejsca i baza przestanie przyjmować zapisy.
Weryfikacja
Sprawdzenie, czy kopia daje się odczytać, powinno następować od razu po jej wykonaniu. Plik o właściwym rozmiarze nie jest dowodem poprawności.
Silniki baz mają do tego własne polecenia sprawdzające sumy kontrolne. Warto je uruchamiać jako kolejny krok tego samego zadania cyklicznego, a wynik traktować tak samo poważnie jak samo wykonanie kopii. Osobno, rzadziej, robi się pełne odtworzenie na środowisko zapasowe.
Czas odtworzenia
Przy dużych bazach liczy się w godzinach. Warto go zmierzyć, zanim będzie potrzebny — bo od tej liczby zależy, ile firma nie będzie działać.
Na czas składa się nie tylko wgranie pliku. Dochodzi pobranie kopii z miejsca, gdzie leży, odtworzenie dziennika transakcji, sprawdzenie spójności, a potem uruchomienie samej aplikacji i sprawdzenie integracji. Zmierzony powinien być cały ten łańcuch, nie jego najszybszy fragment.
Kopia przed zmianą
Przed aktualizacją systemu, przed importem masowym i przed operacją na danych. To krok, którego pominięcie zamienia odwracalny błąd w nieodwracalny.
Dotyczy to również aktualizacji systemu operacyjnego serwera, nie tylko samego programu sprzedażowego. Kopię przed zmianą warto oznaczyć i zachować dłużej niż zwykłe kopie dobowe — skutki nieudanej migracji bywają zauważane po tygodniach, gdy rutynowe egzemplarze zostały już nadpisane.
Dostęp do kopii
Kopia dostępna z tego samego konta, które obsługuje bazę, zostanie zaszyfrowana razem z nią przy ataku. Oddzielenie uprawnień jest tu istotniejsze niż sama częstotliwość.
Rozwiązaniem jest osobne konto z prawem zapisu, ale bez prawa kasowania i nadpisywania, albo miejsce docelowe, do którego serwer bazy w ogóle nie sięga. Warto też sprawdzić, kto ma dostęp do odczytu — plik kopii zawiera wszystkie dane z bazy, łącznie z danymi osobowymi klientów, i wymaga takiej samej ochrony jak sama baza.
