Spowolnienie ERP podczas backupu nie przesądza o przyczynie. W tym samym czasie mogą działać raporty, importy, integracje i zadania administracyjne. Każde z nich może wtedy konkurować o zasoby prywatnej infrastruktury G2E. Diagnoza wymaga zestawienia przebiegu operacji biznesowych z aktywnością SQL oraz serwera. Taki obraz prowadzi do wyboru właściwego rodzaju kopii i miejsca w harmonogramie. Standardowy backup VM chroni warstwę serwera wirtualnego i nie zastępuje kopii bazy zaprojektowanych zgodnie z potrzebami ERP.
Najpierw pomiar, potem zmiana
Początek diagnozy to wspólny zapis czasu kopii SQL, importów, raportów oraz najważniejszych czynności w ERP. Trzeba wiedzieć, kiedy wydłuża się zapis faktury, rezerwacja towaru, generowanie dokumentu lub odpowiedź integracji. Obok trafia wolumen transakcji. Sam procent użycia procesora nie wyjaśnia problemu, ponieważ baza może czekać na zapis, operację dyskową, rozrost logu albo zasób zajęty przez inne zadanie.
Porównanie powinno obejmować okres o podobnym natężeniu pracy bez ciężkiej kopii. Jeśli opóźnienie występuje również wtedy, źródłem może być raport, import lub zmiana w aplikacji. Jeżeli wraca wraz z kopią pełną przy zbliżonej liczbie dokumentów i podobnych zadaniach, administrator ma mocniejszą podstawę do zmiany harmonogramu albo rodzaju operacji. Jednego zgłoszenia użytkownika nie należy traktować jak dowodu.
Co obciąża bazę podczas kopii?
Dla każdej operacji zapisuje się jej rodzaj, czas trwania, wielkość pliku, przyrost logu i liczbę oczekujących zadań. Metryki techniczne trzeba powiązać z konkretną czynnością użytkownika. Kopia, która trwa tyle samo co wcześniej, może stać się uciążliwa po wzroście liczby zamówień lub po dodaniu raportu uruchamianego równolegle.
Kopia pełna intensywnie czyta bazę, podczas gdy ERP nadal zapisuje dokumenty w tym samym środowisku. Administrator obserwuje czas transakcji, oczekiwania na zapis i zachowanie logu. Zmienia jeden element naraz. Samo przesunięcie raportu przy niezmienionej kopii daje inną informację niż równoczesna korekta importu, raportu oraz planu backupu.
Pomiar powinien objąć zwykły dzień, okres większego napływu dokumentów i zamknięcie miesiąca, jeżeli w firmie wyraźnie zmienia ono obciążenie. Administrator SQL opisuje zachowanie bazy, a sprzedaż, magazyn i księgowość wskazują skutki dla swoich procesów. Tak powstaje obraz, który odróżnia chwilowy skok od powtarzalnej kolizji.
Kopia pełna, różnicowa i log transakcyjny
Kopia pełna tworzy podstawę łańcucha odzyskiwania. Kopia różnicowa obejmuje zmiany od ostatniej kopii pełnej i może ograniczyć obciążenie przy częściej wykonywanych zadaniach. Przy odpowiednim modelu odzyskiwania i kompletnym łańcuchu logów można wybrać punkt w czasie objęty dostępnymi logami. Cykl kopii wpływa na ryzyko utraty najnowszej pracy, zwłaszcza bez możliwości wykonania kopii końca logu. Te trzy rodzaje nie są zamienne.
Układ zależy od znaczenia danych. Baza dokumentów sprzedażowych lub księgowych może wymagać innej częstotliwości niż archiwum albo moduł pomocniczy. Organizacja określa dopuszczalną utratę danych i czas uruchomienia procesu po awarii. Administrator przekłada te cele na częstotliwość kopii pełnych, różnicowych i logu transakcyjnego. RTO oraz RPO nie wynikają automatycznie z parametrów serwera.
Przesunięcie kopii pełnej wpływa na kolejne kopie różnicowe. Cykl kopii logu wpływa na najnowszy zabezpieczony stan i RPO. W obrębie dostępnego łańcucha nie ogranicza wyboru konkretnego punktu w czasie. Dlatego lżejsze obciążenie w godzinach pracy nie może zostać osiągnięte przez przypadkowe rozcięcie łańcucha. Nowy układ musi zachować kolejność kopii i możliwość użycia ich zgodnie z planem odtwarzania bazy.
Backup VM chroni inną warstwę
W G2E warstwa VM jest kopiowana raz na 24 godziny, a kopie są przechowywane przez 3 dni. Ochrona obejmuje serwer wirtualny zgodnie z zakresem usługi. Tej kopii nie należy utożsamiać z planem SQL, który uwzględnia log transakcyjny, zależności aplikacji i moment odzyskania danych potrzebny dla ERP.
Trzydniowa retencja dotyczy standardowego backupu VM. Błąd importu lub kartoteki bywa zauważony po kilku cyklach biznesowych, więc firma może potrzebować dłuższej historii bazy. Zapewnia ją odpowiednio ułożony łańcuch kopii SQL i wybrane dla niego miejsce przechowywania. Z drugiej strony sama kopia bazy nie obejmuje konfiguracji aplikacji, integracji i całej drogi uruchomienia ERP po awarii.
Środowisko ERP z bazą SQL może działać na serwerach wirtualnych G2E. Metryki systemu operacyjnego i serwera pomagają ocenić presję na zasoby. Szczegóły zadań SQL, spójność kopii bazy oraz ich cykl pozostają elementem administracji systemem klienta. Wymagania producenta ERP trzeba uwzględnić, jeśli jego mechanizmy wpływają na sposób zabezpieczenia danych.
Harmonogram zgodny z rytmem ERP
Najcięższa kopia powinna omijać okres, w którym jej opóźnienie tworzy zaległość w kolejnych działach. Sprzedaż potrzebuje szybkiego zapisu przy napływie zamówień, magazyn stabilnych rezerwacji przed wysyłką, a księgowość przewidywalnego obiegu dokumentów. Te okresy trafiają na jeden plan razem z importami, raportami, integracjami i zadaniami SQL.
Późna pora nie gwarantuje wolnych zasobów. Nocny wsad potrafi obciążyć bazę mocniej niż dzienna praca użytkowników. Między ciężkimi zadaniami potrzebny jest margines wynikający z obserwowanej zmienności czasu wykonania. Gdy okno nie mieści kopii pełnej, rozwiązaniem może być inny rozkład kopii pełnych, różnicowych oraz logu, a nie upychanie wszystkich prac w coraz krótszym przedziale.
Retencję kopii SQL wyznacza między innymi czas, po którym firma zwykle zauważa błędny import, nieprawidłową kartotekę albo brak dokumentów. Najnowsza kopia może już zawierać problem. Dobry harmonogram łączy więc mierzalny wpływ na ERP, spójny łańcuch odzyskiwania i historię wystarczającą do naprawy realnego błędu. Dopiero taki układ chroni wydajność użytkowników bez osłabienia planu ochrony danych.