Wdrażając backup, sprawdzamy konfigurację SQL Server i planujemy zadania tak, aby działały w tle, nie nakładały się niepotrzebnie na siebie ani nie zakłócały pracy użytkowników. Ustalamy, czy wystarczy kopia pełna, czy potrzebne są również kopie różnicowe i dziennika transakcji. Konfigurujemy raportowanie wykonania oraz alerty o niepowodzeniach, a kopię lokalną uzupełniamy egzemplarzem przechowywanym w innej lokalizacji. Kontrola ma potwierdzić nie tylko uruchomienie zadania, lecz także sensowność jego wyniku.
Po co planować kopie bazy Altum
Baza systemu ERP przechowuje dane wykorzystywane przez pracowników w bieżącej pracy. Jeśli pojawi się problem z serwerem, bazą albo plikami, możliwość odtworzenia danych zależy od tego, jakie kopie są dostępne i z kiedy pochodzą. Ręczne pamiętanie o wykonywaniu backupu łatwo zawodzi, dlatego zadania automatyczne pomagają utrzymać powtarzalny harmonogram. Warunkiem jest ich prawidłowa konfiguracja i sprawdzanie, czy rzeczywiście kończą się powodzeniem.
Plan kopii powinien uwzględniać oczekiwania firmy co do odtwarzania danych. Jednym organizacjom wystarcza powrót do stanu z ostatniej kopii nocnej, a inne potrzebują możliwości odtworzenia do wybranego momentu. To rozróżnienie wpływa na wybór modelu odzyskiwania i zakres zadań. Zanim ustawimy harmonogram, ustalamy, jaki scenariusz jest potrzebny oraz jakie elementy bazy i środowiska mają być chronione.
- ustalenie oczekiwanego punktu odtworzenia;
- sprawdzenie obecnej konfiguracji SQL Server;
- dobór rodzajów kopii do modelu odzyskiwania;
- zaplanowanie kontroli wykonania oraz przechowywania kopii.
Wybór modelu odzyskiwania
Model prosty i pełny wiążą się z innym sposobem planowania backupu. Wybór zależy od tego, czy firmie wystarcza odtworzenie stanu z ostatniej kopii nocnej, czy potrzebny jest powrót do dowolnego momentu w ramach dostępnego łańcucha kopii. Nie ma jednego ustawienia właściwego dla wszystkich instalacji. Przed zmianą modelu wyjaśniamy, jakie możliwości odtwarzania są potrzebne oraz jakie dodatkowe zadania będą wymagane w wybranym wariancie.
Model pełny wymaga uwzględnienia kopii dziennika transakcji, jeśli firma chce korzystać z odtwarzania do określonego momentu. Wariant prosty może odpowiadać potrzebie odtworzenia stanu z ostatniej kopii nocnej. W praktyce trzeba rozumieć skutki wyboru i dostosować do niego cały harmonogram. Sama zmiana modelu, bez skonfigurowania pozostałych elementów, nie tworzy kompletnego planu odzyskiwania.
Jak układamy harmonogram zadań
W SQL Server konfigurujemy zadania automatyczne odpowiednie dla wybranego modelu. Zależnie od potrzeb plan obejmuje kopię pełną, kopie różnicowe wykonywane w ciągu dnia oraz kopie dziennika transakcji w modelu pełnym. Ustalamy kolejność i terminy, uwzględniając kiedy użytkownicy pracują z systemem. Harmonogram ma być zrozumiały i możliwy do kontrolowania, dlatego sprawdzamy także, czy zadania nie kolidują z innymi zaplanowanymi operacjami.
W ramach utrzymania środowiska możemy skonfigurować również plan konserwacji obejmujący przebudowę indeksów i sprawdzanie spójności bazy. Te czynności należy wpasować w harmonogram kopii i codzienną pracę użytkowników. Nie uruchamiamy ich w przypadkowej kolejności ani w tym samym czasie bez sprawdzenia wpływu na środowisko. Po ustaleniu planu weryfikujemy, czy zadania są widoczne i czy ich terminy odpowiadają przyjętym założeniom.
Kontrola powodzenia i alerty
Automatyczne zadanie powinno zostawiać informację o swoim wyniku. Konfigurujemy raport z wykonanych operacji oraz alert informujący o niepowodzeniu, aby problem z harmonogramem nie pozostał niezauważony. Sprawdzamy, czy raport da się odczytać i czy sygnał o błędzie trafia do osoby odpowiedzialnej za środowisko. Dzięki temu zespół może szybciej zareagować, gdy kopia nie powstanie albo zadanie zatrzyma się na błędzie.
Kontrola nie kończy się na potwierdzeniu, że proces się uruchomił. Obserwujemy także rozmiary plików kopii, ponieważ nagła zmiana może oznaczać, że zakres kopiowanych danych uległ zmianie lub część procesu przestała działać zgodnie z założeniami. Porównujemy wyniki w czasie i analizujemy odchylenia. Taka obserwacja nie zastępuje weryfikacji możliwości odtworzenia, ale pomaga wychwycić nietypowe zachowanie, zanim stanie się ono trudne do zauważenia.
- sprawdzenie historii zadań i ich wyniku;
- ustawienie alertu w razie niepowodzenia;
- obserwacja zmian rozmiaru plików kopii;
- weryfikacja, czy raport jest dostępny dla odpowiedzialnej osoby.
Przechowywanie kopii poza siedzibą
Lokalna kopia chroni dane w części scenariuszy, ale może nie wystarczyć, gdy problem obejmuje miejsce, w którym znajduje się serwer. Pożar, zalanie lub kradzież mogą jednocześnie wpłynąć na komputer i kopie przechowywane obok niego. Dlatego uzupełniamy backup lokalny o egzemplarz przechowywany w innej lokalizacji. Plan powinien określać, jak kopia jest tam przekazywana i jak potwierdzamy, że dostępny egzemplarz odpowiada przyjętemu harmonogramowi.
Ważne jest, by kopia poza siedzibą stanowiła element przemyślanego procesu, a nie jednorazowe przeniesienie pliku. Sprawdzamy miejsce docelowe i sposób przekazania danych w kontekście istniejącej konfiguracji. Trzeba również wiedzieć, kto może potwierdzić dostępność kopii i gdzie znaleźć informację o jej aktualności. Łączymy zatem lokalne zadania backupu z kontrolą egzemplarza zewnętrznego, tak aby firma miała jasny obraz tego, co może wykorzystać w razie problemu.
Wpływ backupu na wydajność
Kopia bazy i operacje konserwacyjne angażują zasoby serwera. Jeżeli uruchomią się w czasie intensywnej pracy lub nałożą na siebie, użytkownicy mogą odczuć spowolnienie systemu. Dlatego planujemy zadania tak, aby nie konkurowały niepotrzebnie z czynnościami wykonywanymi przez pracowników. Analizujemy istniejący harmonogram i sprawdzamy, kiedy odbywają się inne zaplanowane operacje, w tym przebudowa indeksów.
Szczególną uwagę zwracamy na sytuację, w której kopia rozpoczyna się równolegle z przebudową indeksów. Takie nałożenie może spowolnić system bardziej niż każde z tych zadań uruchomione osobno. Po uporządkowaniu terminów obserwujemy, czy operacje wykonują się zgodnie z planem i czy nie kolidują z pracą użytkowników. Celem jest harmonogram, który uwzględnia zarówno potrzebę tworzenia kopii, jak i przewidywalne działanie systemu w czasie pracy.
Jak sprawdzić, czy backup odpowiada potrzebom
Przegląd konfiguracji zaczynamy od zestawienia założeń z tym, co rzeczywiście jest wykonywane. Sprawdzamy model odzyskiwania, obecność zadań kopii pełnej i różnicowej oraz kopii dziennika transakcji, jeśli są przewidziane. Następnie analizujemy historię wykonania i raporty. Jeśli firma oczekuje odtworzenia do określonego momentu, sprawdzamy, czy plan obejmuje potrzebne elementy, zamiast zakładać, że każda kopia pełna sama zapewni taką możliwość.
Istotne jest także ustalenie, gdzie znajdują się pliki i kto może ocenić ich aktualność. Sprawdzamy, czy kopia poza siedzibą jest uwzględniona w procesie, oraz czy zmiany rozmiarów plików są monitorowane. Podczas przeglądu zwracamy uwagę na zadania, które nie raportują wyniku lub których harmonogram koliduje z konserwacją. W ten sposób można wskazać luki w konfiguracji i uporządkować działania odpowiednio do przyjętego scenariusza odtwarzania.
Przykładowe sytuacje z pracy serwisu
Jeżeli firma zgłasza, że kopie miały wykonywać się automatycznie, a nie ma pewności, czy zadania nadal działają, zaczynamy od sprawdzenia ich historii i raportów. Weryfikujemy, czy harmonogram odpowiada konfiguracji bazy i czy pojawiają się informacje o błędach. Sprawdzamy też zmiany rozmiaru plików kopii. Nietypowa zmiana jest wskazówką do dalszej kontroli, a nie samodzielnym potwierdzeniem konkretnej przyczyny. Dopiero zestawienie tych informacji pozwala ocenić, co wymaga poprawy.
Inny przykład to plan, w którym zadanie kopii i przebudowa indeksów przypadają na ten sam czas. Wtedy analizujemy kolejność operacji i dopasowujemy terminy do pracy użytkowników. Przy modelu pełnym sprawdzamy, czy harmonogram obejmuje również kopie dziennika transakcji, zgodnie z oczekiwanym sposobem odzyskiwania. W przypadku kopii trzymanych wyłącznie obok serwera omawiamy uzupełnienie procesu o egzemplarz poza siedzibą. Każde z tych działań wynika z konkretnej konfiguracji, a nie z założenia, że wszystkie firmy potrzebują identycznego planu.
Pytania o automatyczne kopie Altum
Czy sama kopia nocna wystarczy?
To zależy od tego, do jakiego stanu firma chce móc odtworzyć dane. Jeśli wystarcza stan z ostatniej kopii nocnej, taki scenariusz może być odpowiedni. Potrzeba odtworzenia do wybranego momentu wymaga innego planu.
Po co kopie dziennika transakcji?
W modelu pełnym mogą być elementem harmonogramu potrzebnego do odtworzenia bazy zgodnie z przyjętym scenariuszem. Sprawdzamy ich rolę w kontekście pozostałych kopii i wybranego modelu odzyskiwania.
Jak wiadomo, że zadania się wykonały?
Konfigurujemy raportowanie wykonanych zadań i alerty o niepowodzeniu. Dodatkowo można obserwować rozmiar plików kopii, aby zauważyć nagłe zmiany wymagające sprawdzenia.
Dlaczego przechowywać kopię poza siedzibą?
Egzemplarz w innej lokalizacji może być potrzebny, gdy zdarzenie obejmie serwer i kopie przechowywane obok niego. Uzupełnia on backup lokalny w scenariuszach takich jak pożar, zalanie lub kradzież.
Czy kopie mogą spowolnić Altum?
Mogą wpływać na zasoby serwera, szczególnie jeśli ich terminy nakładają się na konserwację lub intensywną pracę użytkowników. Dlatego planujemy harmonogram z uwzględnieniem przebudowy indeksów i pozostałych zadań.
Jak pracujemy
Dojeżdżamy do klienta i sprawdzamy konfigurację SQL Server, harmonogram zadań oraz sposób przechowywania kopii. Po diagnostyce wdrażamy uzgodnione ustawienia i kontrolę wykonania, a na naprawę udzielamy gwarancji.
