SQL Server Agent, Backup i Restore: dwa praktyczne przewodniki dla DBA

W pracy administratora SQL Server bardzo łatwo uznać, że proces działa poprawnie, ponieważ jego status jest zielony.

Job się uruchomił.

Backup został wykonany.

SQL Server Agent nie zgłosił błędu.

Na pierwszy rzut oka wszystko wygląda dobrze.

Problem polega na tym, że zielony status odpowiada tylko na jedno pytanie:

Czy SQL Server Agent uznał wykonanie danego zadania za zakończone sukcesem?

Nie odpowiada natomiast na pytania:

• czy proces wykonał wszystkie oczekiwane działania,
• czy job uruchomił się we właściwym kontekście bezpieczeństwa,
• czy powiadomienie o błędzie rzeczywiście dotrze do zespołu DBA,
• czy job będzie działał po failoverze lub migracji,
• czy wykonany backup można odtworzyć,
• czy restore zmieści się w wymaganym RTO,
• czy możliwa utrata danych jest zgodna z RPO.

Z tych właśnie pytań powstały dwa praktyczne przewodniki dla administratorów SQL Server.

Dwa obszary, jedna odpowiedzialność DBA

Pierwszy materiał dotyczy automatyzacji:

SQL Server Agent — Praktyczny Pakiet DBA

Drugi dotyczy bezpieczeństwa danych i gotowości do awarii:

SQL Server Backup i Restore — Praktyczny Przewodnik DBA

Oba materiały łączy wspólna zasada:

Sam fakt skonfigurowania procesu nie oznacza jeszcze, że proces jest bezpieczny.

Automatyzacja musi być monitorowana, udokumentowana i możliwa do zdiagnozowania.

Backup musi być możliwy do odtworzenia, przetestowany i powiązany z wymaganiami RPO oraz RTO.

SQL Server Agent to nie tylko harmonogram

SQL Server Agent często jest traktowany jak prosty harmonogram zadań.

Tworzymy job.

Dodajemy kroki.

Ustawiamy godzinę uruchomienia.

Sprawdzamy historię wykonania.

W środowisku produkcyjnym SQL Server Agent jest jednak czymś znacznie ważniejszym.

To warstwa automatyzacji, która może uruchamiać:

• backupy,
• kontrole integralności baz,
• procesy ETL,
• pakiety SSIS,
• skrypty PowerShell,
• importy i eksporty danych,
• raporty,
• zadania utrzymaniowe,
• procesy zależne od kalendarza biznesowego,
• procedury monitorujące środowisko.

Awaria albo błędna konfiguracja SQL Server Agent może więc wpłynąć jednocześnie na wiele systemów.

Zielony job nie zawsze oznacza sukces procesu

Wyobraźmy sobie job wielokrokowy:

1
2
3
4

Krok 1: przygotowanie danych
Krok 2: eksport pliku
Krok 3: wysłanie pliku do systemu zewnętrznego
Krok 4: zapis informacji o zakończeniu procesu

Jeżeli drugi krok zakończy się błędem, ale konfiguracja przejść pozwoli jobowi dojść do ostatniego kroku i zakończyć się sukcesem, historia może pokazać zielony status.

Technicznie job się zakończył.

Biznesowo proces się nie wykonał.

Dlatego przy projektowaniu jobów trzeba kontrolować:

• akcje po sukcesie i po błędzie,
• kod zwracany przez skrypty,
• obsługę wyjątków,
• retry attempts i retry interval,
• timeouty,
• logowanie wyniku,
• powiadomienia,
• zależności między krokami.

Przykład jawnego zgłoszenia błędu w kroku T-SQL:

1
2
3
4
5
6
7
8

BEGIN TRY
    EXEC dbo.usp_ProcessDailyData;
END TRY
BEGIN CATCH
    DECLARE @ErrorMessage nvarchar(2048) = ERROR_MESSAGE();

    THROW 51000, @ErrorMessage, 1;
END CATCH;

Jeżeli proces nie wykonał oczekiwanej pracy, krok powinien zakończyć się błędem, który SQL Server Agent potrafi prawidłowo zarejestrować.

Co znajduje się w przewodniku SQL Server Agent

Publikacja SQL Server Agent — Praktyczny Pakiet DBA prowadzi przez cały cykl życia joba.

Obejmuje między innymi:

• projektowanie jobów i kroków,
• kroki T-SQL, PowerShell, CmdExec i SSIS,
• harmonogramy,
• retry, timeouty i obsługę błędów,
• Database Mail, operatorów i alerty,
• bezpieczeństwo i role w bazie msdb,
• Credential i Proxy,
• joby backupowe,
• monitoring wykonań,
• audyt zmian,
• kalendarz dni roboczych,
• przygotowanie do patchingu,
• SQL Server Agent w klastrze FCI,
• diagnostykę SSISDB,
• troubleshooting,
• runbooki awaryjne,
• dokumentację jobów,
• migrację między środowiskami,
• raporty DBA,
• produkcyjny baseline SQL Server Agent.

Materiał zawiera również checklisty, skrypty kontrolne, szablony dokumentacji oraz procedury, które można dostosować do własnego środowiska.

Bezpłatny fragment — SQL Server Agent

Nie chcę, aby ktokolwiek kupował kota w worku.

Dlatego udostępniam bezpłatny fragment zawierający:

• okładkę publikacji,
• pełny spis treści,
• przykładowy rozdział,
• fragmenty skryptów i checklist,
• informacje o pełnej wersji.

Bezpłatny fragment — SQL Server Agent

Backup nie jest strategią

W drugim przewodniku wychodzę od bardzo prostego założenia:

Backup nie jest celem samym w sobie.

Backup jest tylko środkiem prowadzącym do celu, którym jest skuteczne odtworzenie danych i działania systemu po:

• awarii,
• błędzie użytkownika,
• uszkodzeniu bazy,
• utracie serwera,
• awarii pamięci masowej,
• incydencie bezpieczeństwa.

Dlatego pytanie:

1

Czy backup się wykonał?

jest dopiero początkiem.

Właściwe pytanie brzmi:

1
2

Czy potrafię odtworzyć bazę do właściwego punktu w czasie
i w czasie akceptowalnym dla organizacji?

RPO i RTO są punktem startowym

Strategia backupu powinna wynikać z wymagań biznesowych.

Dwie podstawowe wartości to:

• RPO — maksymalna akceptowalna utrata danych,
• RTO — maksymalny akceptowalny czas przywrócenia działania systemu.

Jeżeli RPO wynosi 15 minut, backup LOG wykonywany raz na godzinę nie spełnia tego wymagania.

Jeżeli RTO wynosi dwie godziny, a odtworzenie bazy trwa sześć godzin, obecność poprawnego pliku backupu nie oznacza, że strategia jest właściwa.

DBA powinien więc mierzyć nie tylko czas wykonania backupu.

Powinien mierzyć także:

• czas kopiowania plików,
• czas restore,
• czas recovery,
• czas wykonania testów integralności,
• czas przywrócenia loginów i zależności,
• czas uruchomienia aplikacji po odtworzeniu.

FULL, DIFF i LOG tworzą plan odtwarzania

Najczęściej stosowany w produkcji schemat wygląda następująco:

1

FULL + DIFF + LOG

Przykład osi czasu:

1
2
3
4
5
6

20:00 FULL backup
22:00 DIFF backup
22:15 LOG backup
22:30 LOG backup
22:45 LOG backup
23:00 LOG backup

Jeżeli awaria nastąpiła o 22:40, odtworzenie może wymagać:

1. ostatniego właściwego backupu FULL,
2. właściwego backupu DIFF,
3. kolejnych backupów LOG,
4. ostatniego restore z opcją STOPAT.

Przykład:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

RESTORE DATABASE [ERP_Restore]
FROM DISK = N'X:\Backup\ERP\ERP_FULL.bak'
WITH
    NORECOVERY,
    CHECKSUM,
    STATS = 10;
GO

RESTORE DATABASE [ERP_Restore]
FROM DISK = N'X:\Backup\ERP\ERP_DIFF.bak'
WITH
    NORECOVERY,
    CHECKSUM,
    STATS = 10;
GO

RESTORE LOG [ERP_Restore]
FROM DISK = N'X:\Backup\ERP\ERP_LOG_001.trn'
WITH
    NORECOVERY,
    CHECKSUM,
    STATS = 10;
GO

RESTORE LOG [ERP_Restore]
FROM DISK = N'X:\Backup\ERP\ERP_LOG_LAST.trn'
WITH
    STOPAT = '2026-07-28T22:39:59',
    RECOVERY,
    CHECKSUM,
    STATS = 10;
GO

Sama obecność plików nie wystarczy.

Trzeba jeszcze wiedzieć:

• które pliki są właściwe,
• jaka jest ich kolejność,
• czy łańcuch LOG jest kompletny,
• czy wszystkie pliki są dostępne,
• czy backup nie jest zaszyfrowany certyfikatem, którego nie posiadamy.

TDE i certyfikaty

Jeżeli baza korzysta z Transparent Data Encryption, backup bazy wymaga również właściwego zabezpieczenia certyfikatu TDE.

Potrzebne mogą być:

• certyfikat,
• klucz prywatny,
• hasło chroniące eksport klucza,
• kopia certyfikatu przechowywana poza serwerem SQL,
• udokumentowana procedura importu certyfikatu na inną instancję.

Backup może istnieć i być poprawny, ale bez właściwego certyfikatu jego odtworzenie na innym serwerze nie będzie możliwe.

Dlatego certyfikaty powinny być częścią planu Disaster Recovery, a nie prywatnym plikiem pozostawionym na starym serwerze.

RESTORE VERIFYONLY to nie pełny test

Polecenie:

1
2
3

RESTORE VERIFYONLY
FROM DISK = N'X:\Backup\ERP\ERP_FULL.bak'
WITH CHECKSUM;

jest przydatne.

Nie zastępuje jednak prawdziwego testu restore.

Nie potwierdza między innymi:

• że cała sekwencja FULL, DIFF i LOG zostanie odtworzona,
• że mamy wszystkie pliki striped backupu,
• że dostępny jest certyfikat TDE,
• że ścieżki plików są poprawne,
• że po restore baza przejdzie DBCC CHECKDB,
• że aplikacja będzie działała,
• że procedura zmieści się w RTO.

Prawdziwy test backupu polega na odtworzeniu bazy.

Co znajduje się w przewodniku Backup i Restore

Publikacja SQL Server Backup i Restore — Praktyczny Przewodnik DBA obejmuje między innymi:

• RPO i RTO,
• FULL, DIFF, LOG, COPY_ONLY oraz filegroup backup,
• modele recovery,
• LSN i łańcuch logów transakcyjnych,
• point-in-time restore,
• strategie dla różnych środowisk,
• duże bazy i VLDB,
• COMPRESSION i CHECKSUM,
• MAXTRANSFERSIZE i BUFFERCOUNT,
• backup do wielu plików,
• capacity planning,
• retencję backupów,
• TDE i Backup Encryption,
• certyfikaty oraz klucze,
• least privilege,
• gMSA, SPN i Kerberos,
• monitoring backupów,
• alerty operacyjne,
• automatyczne testy restore,
• DBCC CHECKDB po odtworzeniu,
• tail-log backup,
• procedury awaryjne,
• scenariusze ransomware,
• runbook restore,
• dokumentację po incydencie.

Materiał nie koncentruje się wyłącznie na składni poleceń.

Pokazuje, jak zbudować kompletny i możliwy do przetestowania standard operacyjny.

Bezpłatny fragment — Backup i Restore

Bezpłatny fragment zawiera:

• okładkę,
• pełny spis treści,
• wstęp,
• rozdział „Backup to nie strategia”,
• omówienie RPO i RTO,
• podstawowe rodzaje backupów SQL Server.

Bezpłatny fragment — SQL Server Backup i Restore

Dla kogo są te materiały

Obie publikacje przygotowałem przede wszystkim dla:

• administratorów SQL Server,
• administratorów Windows utrzymujących środowiska bazodanowe,
• osób odpowiedzialnych za backupy i procesy ETL,
• developerów wspierających systemy produkcyjne,
• osób przygotowujących standardy operacyjne,
• trenerów prowadzących warsztaty,
• początkujących DBA, którzy chcą nauczyć się właściwego sposobu myślenia o produkcji.

Nie są to materiały do bezrefleksyjnego kopiowania skryptów na serwer produkcyjny.

Każdy skrypt należy najpierw przetestować w środowisku laboratoryjnym, a następnie dostosować do:

• używanej wersji SQL Server,
• modelu bezpieczeństwa,
• kont usługowych,
• struktury pamięci masowej,
• harmonogramów,
• standardów organizacji,
• rzeczywistych wymagań RPO i RTO.

Dwa przewodniki, jeden standard pracy DBA

SQL Server Agent — Praktyczny Pakiet DBA odpowiada na pytanie:

Jak zaprojektować, monitorować i kontrolować automatyzację SQL Server?

SQL Server Backup i Restore — Praktyczny Przewodnik DBA odpowiada na pytanie:

Jak przygotować środowisko na prawdziwą awarię i skutecznie odtworzyć dane?

Razem tworzą podstawę uporządkowanego podejścia do codziennej pracy administratora.

Bo spokojny DBA nie zakłada, że proces zadziała.

Spokojny DBA:

• sprawdza,
• monitoruje,
• dokumentuje,
• testuje,
• przygotowuje procedurę na moment, w którym coś pójdzie nie tak.

Pełne wersje publikacji

Jeżeli masz dziś w środowisku zielone joby, zadaj sobie dwa pytania:

Czy wiesz, co stanie się po pierwszym błędzie procesu?

oraz:

Kiedy ostatni raz naprawdę odtworzyłeś bazę z backupu?