Strategie backupu SQL Server: Full, Differential i Log — kompletny przewodnik (2026)

Backup bazy danych SQL Server to nie pojedyncza czynność — to strategia łącząca trzy typy kopii zapasowych: pełną (Full), różnicową (Differential) oraz dziennika transakcji (Transaction Log). Prawidłowe połączenie tych trzech elementów pozwala odzyskać dane do konkretnego punktu w czasie (co do minuty) przy minimalnym obciążeniu serwera i wykorzystaniu przestrzeni dyskowej.

W skrócie

• Full backup — pełna kopia całej bazy; punkt wyjścia dla każdej strategii
• Differential backup — tylko zmiany od ostatniego Full; szybszy, mniejszy, zależny od bazy różnicowej
• Transaction Log backup — rejestr każdej operacji; umożliwia odzyskiwanie typu point-in-time i obcina dziennik transakcji
• Strategię Full + Differential + Log stosuje się w modelu odzyskiwania Pełnym (Full) — model prosty nie obsługuje backupów Log
• Optymalny harmonogram: Full co tydzień, Differential co 24h, Log co 15–30 minut
• SQL Server 2022 i 2025 wspierają natywnie backup do Azure Blob Storage z szyfrowaniem AES-256 oraz kompresją

Modele odzyskiwania — podstawa wyboru strategii

Zanim zaplanujesz harmonogram backupów, musisz znać model odzyskiwania (recovery model) ustawiony dla bazy. SQL Server oferuje trzy modele:

💡 Kluczowa zasada: jeśli potrzebujesz odzyskać dane do konkretnej minuty (np. przed przypadkowym DROP TABLE o 14:37), musisz używać modelu Full lub Bulk-logged. Model Simple chroni Cię tylko do momentu ostatniego backupu Full lub Differential — wszystkie zmiany po nim są bezpowrotnie tracone.

Aby sprawdzić aktualny model:

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

Aby zmienić na Full:

ALTER DATABASE TwojaBaza SET RECOVERY FULL;

Trzy filary strategii backupu

1. Full backup — fundament

Pełna kopia zapasowa zawiera wszystkie dane bazy oraz wystarczającą ilość dziennika transakcji, aby po przywróceniu baza była spójna transakcyjnie. To punkt startowy — bez niego nie istnieje żaden Differential ani łańcuch Log.

• Tworzony poleceniem: BACKUP DATABASE TwojaBaza TO DISK = 'ścieżka\full.bak';
• Czas trwania zależy od rozmiaru bazy — dla baz produkcyjnych >100 GB może trwać godziny
• Zalecana częstotliwość: co tydzień (lub co noc dla krytycznych systemów)

2. Differential backup — tylko zmiany

Backup różnicowy przechwytuje wyłącznie ekstenty (8-stronicowe bloki) zmienione od ostatniego Full backupu (tzw. differential base). Nie zawiera ponownie całej bazy — tylko to, co się zmieniło.

• Tworzony poleceniem: BACKUP DATABASE TwojaBaza TO DISK = 'ścieżka\diff.bak' WITH DIFFERENTIAL;
• Znacznie szybszy od Full — często trwa minuty zamiast godzin
• Rośnie z czasem — im starszy base Full, tym większy Differential (aż zbliży się rozmiarem do Full)
• Zalecana częstotliwość: codziennie między Full backupami

3. Transaction Log backup — ochrona minuta po minucie

Backup dziennika transakcji zapisuje wszystkie operacje (INSERT, UPDATE, DELETE, DDL) od ostatniego backupu Log. Umożliwia point-in-time recovery — odtworzenie stanu bazy na dowolny moment między backupami.

• Tworzony poleceniem: BACKUP LOG TwojaBaza TO DISK = 'ścieżka\log.trn';
• Po wykonaniu obcina dziennik transakcji (zwalnia miejsce w pliku .ldf)
• Zalecana częstotliwość: co 15–30 minut (systemy krytyczne: co 5–10 minut)
• Tail-log backup — ostatni backup Log przed restore, wykonywany także przy uszkodzonej bazie (opcja WITH NO_TRUNCATE), chroni dane wprowadzone po ostatnim zaplanowanym backupie

Przykładowy harmonogram produkcyjny

Poniższy harmonogram jest standardem w środowiskach produkcyjnych SQL Server w 2026 roku:

Dlaczego Differential w południe, a nie w nocy? Backup różnicowy o 13:00 skraca okno odzyskiwania — w przypadku awarii o 16:00 przywracasz Full z niedzieli + Differential z tego samego dnia + zaledwie kilka Logów, zamiast odtwarzać Logi od wczoraj.

Proces odzyskiwania krok po kroku

Scenariusz: awaria bazy w czwartek o 14:45. Odtwarzasz:

1. Tail-log backup (jeśli baza jest dostępna online):

   BACKUP LOG TwojaBaza TO DISK = 'ścieżka\tail.trn' WITH NORECOVERY;
   

2. Restore Full z niedzieli (z opcją NORECOVERY):

   RESTORE DATABASE TwojaBaza FROM DISK = 'ścieżka\full.bak' WITH NORECOVERY;
   

3. Restore najnowszego Differential z czwartku o 13:00:

   RESTORE DATABASE TwojaBaza FROM DISK = 'ścieżka\diff.bak' WITH NORECOVERY;
   

4. Restore wszystkich Logów od 13:00 do 14:45 (w kolejności chronologicznej, z NORECOVERY), a ostatni — tail log — z RECOVERY:

   RESTORE LOG TwojaBaza FROM DISK = 'ścieżka\log_1330.trn' WITH NORECOVERY;
   RESTORE LOG TwojaBaza FROM DISK = 'ścieżka\log_1400.trn' WITH NORECOVERY;
   RESTORE LOG TwojaBaza FROM DISK = 'ścieżka\log_1430.trn' WITH NORECOVERY;
   RESTORE LOG TwojaBaza FROM DISK = 'ścieżka\tail.trn' WITH RECOVERY;
   

5. Baza wraca online ze stanem sprzed awarii. Maksymalna utrata danych: 0 minut (dzięki tail-log).

Porównanie strategii backupu

Częste pytania

Czym różni się Differential od Log backupu?

Differential przechwytuje zmienione strony danych od ostatniego Full — przywracasz go jako jeden plik i już zawiera wszystkie zmiany od Full. Log backup zawiera sekwencję każdej operacji (INSERT, UPDATE, DELETE) i umożliwia odtwarzanie bazy transakcja po transakcji do konkretnego znacznika czasowego. Differential skraca czas restore, Log daje precyzję.

Czy mogę pominąć Differential i robić tylko Full + Log?

Tak — to również poprawna strategia. Przy odzyskiwaniu przywracasz wtedy Full, a następnie odtwarzasz wszystkie Logi jeden po drugim. Wadą jest dłuższy czas restore — przy 100 Logach może to zająć znacznie więcej czasu niż jeden Differential. Differential to optymalizacja, nie wymóg.

Co się stanie, jeśli zabraknie miejsca na dysku z logami (.ldf)?

Dziennik transakcji w modelu Full rośnie bez ograniczeń, dopóki nie wykonasz backupu Log. Jeśli miejsce się wyczerpie, SQL Server zgłosi błąd 9002 i baza przejdzie w tryb tylko do odczytu. Rozwiązanie: natychmiast wykonaj backup Log (BACKUP LOG ...), a następnie rozważ zwiększenie częstotliwości backupów Log lub przeniesienie pliku .ldf na większy wolumin.

Jak często robić Full backup — czy co tydzień wystarczy?

Dla większości systemów produkcyjnych tygodniowy Full jest optymalny. Przy bardzo dużych bazach (>500 GB) lub wysokim RPO (Recovery Point Objective) rozważa się Full co 2 tygodnie, ale wtedy Differential rośnie szybciej i restore trwa dłużej. Dla systemów krytycznych finansowo (banki, e-commerce) Full co noc to standard.

Czy backup w SQL Server blokuje bazę?

Nie. SQL Server od wersji 7.0 (1998) stosuje online backup — użytkownicy mogą normalnie wykonywać INSERT, UPDATE i DELETE podczas tworzenia kopii. Backup nie blokuje transakcji, ale może nieznacznie zwiększyć obciążenie I/O dysku. Jedyne operacje niedostępne podczas backupu to: dodawanie/usuwanie plików bazy (ALTER DATABASE ADD/REMOVE FILE) oraz operacje zmniejszania bazy (shrink).

Czy Differential rośnie w nieskończoność?

Nie w nieskończoność, ale do rozmiaru Full backupu. Im więcej zmian w bazie od ostatniego Full, tym Differential jest większy. Gdy zbliży się rozmiarem do Full, traci sens — wtedy lepiej wykonać nowy Full, aby ustanowić nową bazę różnicową. Dlatego standardowy interwał to tydzień Full + codzienny Differential.

Czy strategia Full + Differential + Log działa z Always On Availability Groups?

Tak, ale z zastrzeżeniami. W grupach dostępności backup wykonuje się na replice dodatkowej (secondary), aby odciążyć replikę główną. Backup Log działa na dowolnej replice (primary lub secondary, w zależności od konfiguracji), natomiast Differential i Full na secondary wymagają, aby replika była w trybie synchronizacji synchronicznej. Kopie tylko do odczytu (read-only replicas) nie obsługują backupów.

Twój SQL Server działa na Windows Server?

Strategia backupu to jedno — drugie to solidny system operacyjny pod bazą danych. Jeśli modernizujesz infrastrukturę lub potrzebujesz nowej licencji na Windows Server do hostowania SQL Server, sprawdź ofertę KluczeSoft — legalne, aktywowane klucze licencyjne zgodne z prawem UE:

→ Licencje Windows Server — od Windows Server 2019 do 2025