Konfiguracja Log Shipping w SQL Server — praktyczny przewodnik

Czym jest Log Shipping i kiedy go stosować

Log Shipping to mechanizm wysokiej dostępności oparty na prostej, ale skutecznej koncepcji: automatyczne kopiowanie i odtwarzanie backupów logów transakcyjnych z serwera primary na jeden lub więcej serwerów secondary. To rozwiązanie znane od lat, które sprawdza się szczególnie w środowiskach, gdzie:

• Potrzebujesz kopii bazy do celów raportowych z akceptowalnym opóźnieniem
• Wymagasz prostego disaster recovery bez skomplikowanej infrastruktury
• Masz ograniczony budżet i nie możesz pozwolić sobie na Always On AG
• Serwery znajdują się w różnych domenach lub bez domeny

W przeciwieństwie do Always On Availability Groups, Log Shipping nie wymaga Windows Server Failover Clustering ani Enterprise Edition (z wyjątkiem kompresji backupów). Działa na każdej edycji SQL Server, włącznie ze Standard.

Z mojego doświadczenia wynika, że Log Shipping to często niedoceniane rozwiązanie. Widziałem firmy, które płaciły za drogie licencje Enterprise tylko po to, żeby skonfigurować Always On do celów DR, podczas gdy Log Shipping załatwiłby sprawę za ułamek kosztów.

Wymagania wstępne przed konfiguracją

Zanim przystąpisz do konfiguracji, musisz spełnić kilka warunków. Pominięcie któregokolwiek z nich skutkuje frustracją i błędami, które nie zawsze są oczywiste.

Model odzyskiwania bazy danych

Baza primary musi działać w trybie Full lub Bulk-Logged Recovery. Tryb Simple wyklucza użycie Log Shipping, ponieważ nie generuje backupów logów transakcyjnych. Sprawdź aktualny tryb:

SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'TwojaBaza'

Jeśli musisz zmienić model odzyskiwania, pamiętaj o wykonaniu pełnego backupu zaraz po zmianie.

Udział sieciowy dla backupów

To najczęstsze źródło problemów. Musisz utworzyć udział sieciowy dostępny zarówno dla serwera primary, jak i secondary. Przykładowo, jeśli backupy lądują w katalogu C:\data\tlogs\ na serwerze primary, utwórz udział \\primaryserver\tlogs.

Krytyczne kwestie dotyczące uprawnień:

• Konto serwisowe SQL Server na serwerze primary musi mieć uprawnienia zapisu do udziału
• Konto serwisowe SQL Server na serwerze secondary musi mieć uprawnienia odczytu
• Jeśli SQL Server działa jako Local System, backup folder musi znajdować się na serwerze primary z lokalną ścieżką

Uprawnienia użytkownika

Konfiguracja wymaga członkostwa w roli sysadmin na wszystkich zaangażowanych serwerach. Nie ma skrótów — procedury składowane Log Shipping wymagają tych uprawnień.

Konfiguracja przez SQL Server Management Studio

SSMS oferuje intuicyjny kreator, który przeprowadzi Cię przez cały proces. Oto szczegółowa instrukcja:

Krok 1: Włączenie bazy jako primary

Kliknij prawym przyciskiem na bazę danych, wybierz Properties, następnie przejdź do zakładki Transaction Log Shipping. Zaznacz opcję Enable this as a primary database in a log shipping configuration.

Krok 2: Konfiguracja backupów

Kliknij Backup Settings i skonfiguruj:

• Network path to the backup folder — ścieżka UNC do udziału sieciowego
• If the backup folder is located on the primary server — lokalna ścieżka (opcjonalnie)
• Delete files older than — retencja starych backupów (zalecam minimum 48-72 godziny)
• Alert if no backup occurs within — próg alertów

SQL Server od wersji 2008 Enterprise wspiera kompresję backupów. Masz trzy opcje: użyj ustawień serwera, kompresuj lub nie kompresuj. Kompresja znacząco przyspiesza transfer i redukuje wymagania dyskowe.

Krok 3: Dodanie serwera secondary

W sekcji Secondary server instances and databases kliknij Add. Połącz się z serwerem secondary i skonfiguruj:

Zakładka Initialize Secondary database:

• Generate a full backup and restore — SSMS wykona wszystko automatycznie
• Use an existing backup — wskaż istniejący backup
• The secondary database is initialized — baza już istnieje i jest w stanie restoring

Zakładka Copy Files:

• Destination folder for copied files — lokalny katalog na serwerze secondary
• Harmonogram kopiowania — powinien być zbliżony do harmonogramu backupów

Zakładka Restore:

• No recovery mode — baza niedostępna, ale szybszy failover
• Standby mode — baza dostępna tylko do odczytu między restore'ami
• Delay restoring backups — opóźnienie restore'ów (przydatne jako ochrona przed błędami użytkowników)

Tryb Standby działa tylko gdy wersje SQL Server na primary i secondary są identyczne. Jeśli secondary ma wyższą wersję major, zostaje Ci tylko No Recovery. To częsta pułapka przy migracjach.

Konfiguracja Monitor Server

Monitor Server to opcjonalny, ale bardzo przydatny komponent. Zbiera informacje o stanie Log Shipping ze wszystkich serwerów i generuje alerty. Może to być trzeci serwer, ale równie dobrze sprawdzi się primary lub secondary.

W sekcji Monitor server instance zaznacz Use a monitor server instance i kliknij Settings. Skonfiguruj:

• Instancję monitora
• Sposób łączenia się zadań z monitorem (konto Windows lub SQL Login)
• Czas retencji historii

Monitor przechowuje dane w bazie msdb i udostępnia raporty przez SSMS. Bez niego musisz ręcznie sprawdzać stan na każdym serwerze.

Uwaga dla SQL Server 2025

SQL Server 2025 używa OLEDB w wersji 19 z domyślnym szyfrowaniem Mandatory. Jeśli dodajesz instancję 2025 jako monitor do topologii z wcześniejszymi wersjami, możesz napotkać problemy z połączeniem. Sprawdź konfigurację linked serverów.

Konfiguracja przez T-SQL

Dla zautomatyzowanych wdrożeń lub gdy preferujesz pełną kontrolę, możesz skonfigurować Log Shipping za pomocą procedur składowanych. Główne procedury to:

• sp_add_log_shipping_primary_database — rejestruje bazę primary
• sp_add_log_shipping_secondary_primary — rejestruje primary na serwerze secondary
• sp_add_log_shipping_secondary_database — konfiguruje bazę secondary
• sp_add_log_shipping_alert_job — dodaje zadanie alertów

Procedury tworzą odpowiednie zadania SQL Server Agent: backup, copy i restore. Każde zadanie ma własny harmonogram, który możesz dostosować.

Typowy harmonogram

Dla większości środowisk sprawdza się:

• Backup co 15 minut
• Copy co 15 minut (przesunięte o 5 minut względem backupu)
• Restore co 15 minut (przesunięte o 5 minut względem copy)

Daje to maksymalne opóźnienie około 30-45 minut przy normalnej pracy. Dla krytycznych systemów możesz zejść do 5-minutowych interwałów.

Monitorowanie i rozwiązywanie problemów

Po skonfigurowaniu Log Shipping, regularne monitorowanie jest kluczowe. Sprawdzaj:

• Historię zadań SQL Server Agent na wszystkich serwerach
• Raport Transaction Log Shipping Status w SSMS
• Tabelę log_shipping_monitor_history_detail w bazie msdb

Najczęstsze problemy i ich rozwiązania:

Backup job fails — sprawdź uprawnienia konta serwisowego do folderu backup i dostępność miejsca na dysku.

Copy job fails — zweryfikuj łączność sieciową i uprawnienia do udziału. Użyj net use z poziomu konta serwisowego.

Restore job fails — często spowodowane brakującymi plikami backup lub próbą restore'u w złej kolejności. Sprawdź czy wszystkie pliki zostały skopiowane.

Zawsze ustawiaj sensowne alerty. Domyślne wartości są często zbyt liberalne. Jeśli backup ma działać co 15 minut, alert po 30 minutach bez backupu jest rozsądny. Po godzinie to już za późno.