Automatyczna kopia bazy MSSQL to jedno z zadań wykonywanych cyklicznie przez usługę SSJob, konfigurowane po prostu jako pojedynczy wiersz w tabeli _jobs. Obsługuje trzy rodzaje kopii - pełną, przyrostową i plik LOG - z ustawianą częstotliwością wykonania i powiadomieniem e-mail o ostatecznym rezultacie.
Czym jest automatyczna kopia bazy MSSQL
Baza danych StudioSystem, opisana szerzej w materiale o bazie danych i widokach SQL, przechowuje wszystkie dane operacyjne platformy - dokumenty, kartoteki, konfigurację. Utrata tych danych bez aktualnej, sprawdzonej kopii zapasowej oznaczałaby w praktyce niemal całkowite zatrzymanie bieżącej pracy firmy, dlatego mechanizm automatycznego wykonywania kopii jest jednym z pierwszych elementów konfigurowanych po instalacji usługi SSJob.
Zadanie kopii bazy MSSQL nie różni się mechanicznie od pozostałych zadań obsługiwanych przez SSJob, opisanych ogólnie w materiale o usłudze SSJob - to również wiersz w tabeli _jobs, z własnym zestawem parametrów. Różnica leży w konkretnych polach istotnych dla tego typu zadania - przede wszystkim w rodzaju wykonywanej kopii i folderze docelowym.
Taki wspólny mechanizm konfiguracji ma wymierną zaletę organizacyjną. Administrator, który raz nauczył się obsługiwać jedno zadanie SSJob, potrafi bez dodatkowego szkolenia skonfigurować każde kolejne - zmieniają się wyłącznie wartości pól właściwe dla danego typu zadania, a nie sam sposób pracy z tabelą _jobs. To samo dotyczy diagnozowania problemów: znajomość struktury jednego zadania przekłada się wprost na umiejętność sprawdzenia dowolnego innego.
Konfiguracja w tabeli _jobs
Każde zadanie automatyczne, niezależnie od typu, opisywane jest w tabeli _jobs zestawem wspólnych pól. Dla kopii bazy MSSQL najważniejsze z nich to:
| Pole | Znaczenie |
|---|---|
| OSTATNIOWYKONANO | Data ostatniego poprawnego wykonania zadania |
| CYKLICZNOSC | Liczbowy interwał, co jaki zadanie jest uruchamiane |
| CYKLICZNOSCTYPE | Jednostka interwału - np. godziny, dni |
| MAILPOWIADOMIENIE | Adresy e-mail, na które trafią powiadomienia o wykonaniu |
| CONECTIONSTRINGNAME | Łańcuch połączeniowy do bazy danych objętej kopią |
| RODZAJKOPII | Typ wykonywanej kopii - pełna, przyrostowa lub plik LOG |
| FOLDERKOPII | Folder, w którym zapisywana jest wykonana kopia |
Konfiguracja tego zadania sprowadza się więc do wypełnienia jednego wiersza w tabeli - bez pisania kodu ani instalowania dodatkowego oprogramowania do backupu. Usługa SSJob, działająca w tle jako usługa Windows, sama odczytuje ten wiersz i podejmuje decyzję, czy nadszedł czas na kolejne wykonanie.
Trzy rodzaje kopii
Pole RODZAJKOPII pozwala wybrać jeden z trzech standardowych w SQL Server rodzajów kopii zapasowej, każdy o innym zastosowaniu:
- Pełna - kompletna kopia całej bazy danych na moment wykonania. Najbardziej czasochłonna i zajmująca najwięcej miejsca, ale wystarczająca sama w sobie do pełnego odtworzenia bazy.
- Przyrostowa - obejmuje wyłącznie zmiany wprowadzone od czasu ostatniej kopii pełnej lub przyrostowej. Szybsza i mniejsza, ale do odtworzenia bazy potrzebna jest cała sekwencja kopii aż do ostatniej pełnej.
- Plik LOG - kopia dziennika transakcji, pozwalająca odtworzyć stan bazy z dokładnością większą niż jeden dzień, aż do konkretnej minuty sprzed awarii.
W praktyce te trzy rodzaje zwykle łączy się w jednym harmonogramie - rzadka kopia pełna jako podstawa, częstsze kopie przyrostowe pomiędzy nimi, a najczęstsze kopie pliku LOG minimalizujące potencjalną utratę danych w razie awarii tuż przed najbliższą kopią pełną.
Wybór proporcji między tymi trzema rodzajami zależy od tego, ile danych firma może sobie pozwolić stracić w razie awarii, oraz jak dużym obciążeniem serwera są gotowa zaakceptować w zamian za częstsze kopie. Kopia pełna wykonywana raz na dobę w połączeniu z kopiami pliku LOG co kilkanaście minut ogranicza potencjalną stratę danych do niewielkiego okna czasowego, kosztem dodatkowego obciążenia dysku i sieci w ciągu dnia.
Jeden panel, cała konfiguracja
Parametry techniczne platformy - w tym te wykorzystywane przez zadania automatyczne - konfiguruje się z tego samego miejsca co pozostałe ustawienia administracyjne.
Harmonogram cykliczny
Częstotliwość wykonywania zadania ustala się dwoma powiązanymi polami: CYKLICZNOSC, określającym liczbę, oraz CYKLICZNOSCTYPE, określającym jednostkę tego interwału - na przykład godziny albo dni. Kombinacja tych dwóch pól pozwala zbudować praktycznie dowolny harmonogram, od kopii wykonywanej co kilka godzin po kopię wykonywaną raz w tygodniu.
Pole OSTATNIOWYKONANO pełni tu podwójną rolę - jest zarówno logiem ostatniego wykonania, jak i punktem odniesienia, od którego usługa liczy kolejny termin uruchomienia zadania zgodnie z ustawioną cyklicznością. Dzięki temu nawet po restarcie serwera albo dłuższej przerwie w działaniu usługi, harmonogram nie gubi się - kolejne wykonanie liczone jest od ostatniego zarejestrowanego sukcesu, a nie od stałej godziny w zegarze systemowym.
Powiadomienia i diagnostyka
Pole MAILPOWIADOMIENIE pozwala wskazać jeden lub więcej adresów e-mail, na które trafi informacja o wykonaniu zadania. W praktyce jest to jedyny sygnał, na podstawie którego administrator dowiaduje się, że kopia bazy została faktycznie wykonana, bez potrzeby żmudnego, ręcznego sprawdzania zawartości folderu docelowego każdego kolejnego dnia.
Dodatkowym źródłem diagnostyki jest sam Dziennik zdarzeń Windows, do którego usługa SSJob zapisuje informacje o swoim działaniu. Połączenie obu źródeł - powiadomienia e-mail dla rutynowego potwierdzenia i dziennika zdarzeń dla szczegółowej diagnostyki w razie problemu - daje pełny obraz stanu zadania bez konieczności logowania się bezpośrednio na serwer bazy danych przy każdej kontroli.
Folder docelowy i połączenie
Pole FOLDERKOPII wskazuje lokalizację, w której zapisywana jest wykonana kopia, a CONECTIONSTRINGNAME - łańcuch połączeniowy do bazy danych, która ma zostać skopiowana. Rozdzielenie tych dwóch niezależnych parametrów pozwala na przykład zapisywać kopie różnych baz w zupełnie osobnych folderach, przy jednoczesnym korzystaniu z tej samej instalacji usługi SSJob.
Warto, aby folder docelowy znajdował się na innym dysku fizycznym niż baza źródłowa, a najlepiej - na zasobie sieciowym albo w innej lokalizacji fizycznej. Kopia zapasowa przechowywana na tym samym dysku co baza produkcyjna nie chroni przed awarią samego dysku, która jest jednym z najczęstszych powodów, dla których kopia w ogóle bywa realnie potrzebna. Ten sam argument przemawia za regularnym kopiowaniem plików backupu poza serwer produkcyjny, na przykład do chmury albo na dysk sieciowy w innej lokalizacji fizycznej firmy.
Dobre praktyki
Kilka zasad sprawdza się niezależnie od wielkości i specyfiki wdrożenia:
- Testowanie odtwarzania - kopia, której nigdy nie próbowano odtworzyć, jest tylko teoretycznym zabezpieczeniem. Warto okresowo sprawdzać, czy z zapisanych plików rzeczywiście da się odtworzyć bazę.
- Rozdzielenie w czasie od innych zadań - kopia bazy nie powinna nakładać się w harmonogramie na inne zadania obciążające serwer, na przykład odbudowę indeksów czy ich reorganizację.
- Retencja plików - stare kopie warto usuwać automatycznie po określonym czasie, żeby folder docelowy nie zapełnił się bezpowrotnie w kilka miesięcy.
- Monitorowanie powiadomień - brak oczekiwanego e-maila z potwierdzeniem wykonania jest sygnałem ostrzegawczym samym w sobie, nawet bez błędu w dzienniku zdarzeń.
Warto też pamiętać, że sama kopia pliku nie jest jeszcze pełnym planem odzyskiwania po awarii. Plan taki powinien odpowiadać nie tylko na pytanie „gdzie jest kopia”, ale też „kto i w jakim czasie potrafi ją odtworzyć” oraz „jak dokładnie wygląda procedura przełączenia na zapasowy serwer, jeśli awarii ulegnie sam sprzęt, a nie tylko dane”. Sama automatyzacja tworzenia kopii, opisana w tym materiale, jest niezbędnym, ale nie jedynym elementem takiego planu.
Podsumowanie
Automatyczna kopia bazy MSSQL to zadanie usługi SSJob konfigurowane jednym wierszem w tabeli _jobs, obsługujące trzy rodzaje kopii - pełną, przyrostową i plik LOG - z ustawianą cyklicznością i powiadomieniem e-mail o rezultacie każdego wykonania.
To pierwszy z serii materiałów opisujących zadania automatyczne SSJob wykorzystujące ten sam mechanizm konfiguracji - kolejne dotyczą kopii aplikacji oraz utrzymania wydajności bazy przez odbudowę i reorganizację indeksów. Znajomość mechanizmu opisanego tutaj wystarczy, żeby bez trudu skonfigurować każde z pozostałych zadań tej rodziny.