SQL Server Agent Backup Job

Zadanie backupu SQL Server Agent automatyzuje cykliczne wykonywanie kopii zapasowych bez ingerencji administratora.

Rola zadania backupu w SQL Server Agent

SQL Server Agent Backup Job jest zadaniem wykonywanym przez usługę SQL Server Agent, które uruchamia określone kroki związane z tworzeniem kopii zapasowych baz danych Microsoft SQL Server. Zadanie może działać według harmonogramu, na przykład w określonych dniach i godzinach, bez ręcznego rozpoczynania operacji przez administratora. Definicja zadania jest przechowywana w bazie systemowej msdb, a jego wykonanie obejmuje między innymi informacje o krokach, harmonogramach, właścicielu zadania i historii uruchomień.

Najczęściej krok zadania wykonuje polecenie Transact-SQL BACKUP DATABASE albo BACKUP LOG. Kopia pełna obejmuje dane znajdujące się w bazie w momencie wykonania operacji. Kopia różnicowa zawiera zmiany od czasu ostatniej kopii pełnej, natomiast kopia dziennika transakcji zapisuje fragment dziennika potrzebny do odtworzenia kolejnych zmian. Zakres dostępnych kopii dziennika zależy od modelu odzyskiwania bazy danych. W modelu FULL i BULK_LOGGED dziennik może być regularnie kopiowany, podczas gdy model SIMPLE nie obsługuje standardowego łańcucha kopii dziennika transakcji.

Budowa kroków, harmonogramu i miejsca zapisu

Typowe zadanie backupu składa się z jednego lub wielu kroków. Krok może zawierać instrukcję T-SQL, wywołanie programu systemowego albo polecenie uruchamiające procedurę pomocniczą. W prostym wariancie instrukcja może wskazywać bazę, plik docelowy oraz opcje kopii, na przykład BACKUP DATABASE [NazwaBazy] TO DISK = N'ścieżka_do_pliku.bak' WITH INIT, CHECKSUM. Opcja CHECKSUM powoduje obliczanie sum kontrolnych podczas tworzenia kopii, ale sama w sobie nie dowodzi, że kopię można skutecznie odtworzyć.

Harmonogram powinien odpowiadać przyjętej strategii odzyskiwania. Kopia pełna może być wykonywana cyklicznie, kopie różnicowe pomiędzy kopiami pełnymi, a kopie dziennika w krótszych odstępach. SQL Server Agent rozróżnia między innymi harmonogramy jednorazowe, cykliczne i uruchamiane w reakcji na określone zdarzenie. Przy projektowaniu godzin uruchomienia trzeba uwzględnić czas trwania operacji, nakładanie się zadań oraz obciążenie wejścia-wyjścia. Równoczesne wykonywanie wielu kopii na tym samym woluminie może wydłużyć zarówno backup, jak i inne operacje bazy.

Plik kopii jest zapisywany z perspektywy serwera SQL Server, a nie komputera, z którego otwarto narzędzie administracyjne. Dlatego ścieżka lokalna wskazana w poleceniu musi być dostępna dla instancji SQL Server i dla konta używanego przez usługę SQL Server. W przypadku udziału sieciowego wymagane są odpowiednie uprawnienia systemowe do zapisu. Samo utworzenie pliku .bak nie oznacza jeszcze poprawnego procesu ochrony danych: należy uwzględnić retencję, dostępność miejsca oraz niezależność kopii od podstawowego nośnika.

Kontrola wykonania i weryfikacja odtwarzalności

SQL Server Agent zapisuje wynik uruchomienia zadania w historii dostępnej w SQL Server Management Studio oraz w tabelach bazy msdb. Historia pozwala sprawdzić, czy zadanie zakończyło się powodzeniem, jaki komunikat zwrócił poszczególny krok oraz ile trwała operacja. Warto rozróżniać awarię całego zadania od błędu pojedynczego kroku, ponieważ konfiguracja przejść między krokami może spowodować kontynuowanie pracy mimo niepowodzenia wcześniejszej czynności.

Do podstawowej kontroli można użyć polecenia RESTORE VERIFYONLY, które sprawdza, czy SQL Server rozpoznaje kopię jako poprawny zestaw backupu. Nie zastępuje to jednak próbnego odtworzenia. Rzeczywista weryfikacja powinna obejmować odtworzenie kopii pełnej, zastosowanie właściwej kopii różnicowej oraz, jeśli używany jest łańcuch dziennika, odtworzenie kolejnych kopii logu z opcją NORECOVERY i zakończenie procesu przez WITH RECOVERY. Dopiero taki test pozwala potwierdzić, że dostępne pliki, kolejność kopii i procedura odzyskiwania są ze sobą zgodne.

W zadaniu można skonfigurować reakcję na sukces lub błąd, a także powiadomienia i alerty SQL Server Agent. Alert może być związany z określonym komunikatem błędu, poziomem ważności albo zdarzeniem dotyczącym wydajności. Przydatne jest również sprawdzanie rozmiaru oraz daty modyfikacji plików kopii, lecz te informacje powinny być traktowane pomocniczo. Plik o aktualnej dacie może być niekompletny, zapisany w niewłaściwym miejscu albo utworzony przez zadanie, które nie obejmowało wymaganej bazy.

Uprawnienia, łańcuch kopii i diagnostyka problemów

Wykonanie zadania zależy od kilku niezależnych warstw uprawnień. Konto uruchamiające krok T-SQL musi mieć uprawnienia wymagane do wykonania operacji backupu, a konto usługi SQL Server musi móc zapisywać w wybranej lokalizacji. Dodatkowo SQL Server Agent musi mieć możliwość uruchomienia zadania, a jego właściciel powinien być prawidłowo skonfigurowany. Błąd logowania, brak dostępu do katalogu, brak wolnego miejsca lub niedostępność udziału sieciowego może przerwać operację mimo poprawnej składni polecenia.

Diagnostyka powinna rozpocząć się od historii zadania, komunikatu z konkretnego kroku oraz logów SQL Server Agent. Następnie należy sprawdzić nazwę instancji, bazę wskazaną w poleceniu, ścieżkę docelową, dostępne miejsce i uprawnienia systemowe. Przy kopiach dziennika trzeba dodatkowo zweryfikować, czy nie został przerwany łańcuch logów oraz czy kopie są odtwarzane w prawidłowej kolejności. Usunięcie lub nadpisanie plików bez kontroli retencji może uniemożliwić odtworzenie wymaganej chwili, nawet jeśli bieżące zadanie kończy się statusem sukcesu.

W przypadku problemów z laptopem lub komputerem PC związanych z działaniem narzędzi administracyjnych, usług systemowych, dysków albo dostępem do lokalizacji zapisu diagnostyka powinna rozdzielić usterkę sprzętową od problemu konfiguracji SQL Server. Analiza komunikatów, stanu systemu plików i poprawności urządzeń magazynujących może pomóc ustalić, czy przyczyną jest środowisko komputera, czy konfiguracja samego SQL Server Agent.