Backup logu do pliku z rozszerzeniem .trn to standardowa forma zapisu kopii zapasowej dziennika transakcji.
Plik .trn jako zapis kopii dziennika transakcji SQL Server
Rozszerzenie .trn jest powszechnie używane dla plików zawierających kopię zapasową dziennika transakcji Microsoft SQL Server. Samo rozszerzenie nie jest jednak wymagane przez silnik i nie decyduje o typie kopii. O tym, że powstaje kopia logu, przesądza użycie instrukcji BACKUP LOG, a nie nazwa pliku. Przykładowo administrator może zapisać kopię dziennika w pliku sprzedaz_2026_08_24_1200.trn, ale SQL Server rozpozna jej zawartość na podstawie wewnętrznych metadanych kopii, nie na podstawie końcówki nazwy.
Kopia logu obejmuje rekordy dziennika potrzebne do odtworzenia zmian wykonanych od poprzedniej kopii dziennika. Dziennik transakcji rejestruje między innymi rozpoczęcie i zatwierdzenie transakcji, modyfikacje stron danych oraz operacje wymagane do cofania lub ponawiania zmian. Plik .trn nie jest więc kopią wszystkich plików bazy i nie zastępuje pełnej kopii zapasowej. Jest elementem określonego łańcucha kopii, który pozwala odtwarzać bazę w kolejnych punktach czasu.
Warunki wykonania BACKUP LOG
SQL Server wykonuje kopie dziennika dla baz pracujących w modelu odzyskiwania FULL albo BULK_LOGGED. W modelu SIMPLE kopie dziennika transakcji nie są obsługiwane, ponieważ silnik samodzielnie odzyskuje przestrzeń dziennika po punktach kontrolnych i nie utrzymuje łańcucha kopii logu przeznaczonego do odtwarzania kolejnych fragmentów. Jeśli baza ma być odtwarzana do konkretnego momentu, trzeba zastosować model FULL lub w określonych scenariuszach BULK_LOGGED oraz wykonać pełną kopię zapasową, od której rozpocznie się łańcuch.
Typowe polecenie ma postać BACKUP LOG [BazaDanych] TO DISK = N'D:\Backup\BazaDanych_1200.trn' WITH CHECKSUM, INIT. Opcja CHECKSUM powoduje wykonanie dodatkowych kontroli sum kontrolnych podczas tworzenia kopii, o ile środowisko i konfiguracja kopii na to pozwalają. INIT nadpisuje zestaw kopii w wskazanym urządzeniu backupu, dlatego nie należy używać jej bez sprawdzenia, czy plik nie zawiera potrzebnych wcześniejszych kopii. Bezpieczniejszą praktyką jest stosowanie unikalnych nazw plików albo świadome zarządzanie zestawami kopii.
Częstotliwość wykonywania kopii logu zależy od wymaganego maksymalnego okresu utraty danych oraz od tempa przyrostu dziennika. Kopia logu nie zmniejsza automatycznie fizycznego rozmiaru pliku dziennika, ale w modelach FULL i BULK_LOGGED umożliwia oznaczenie ponownie używalnych części logu, gdy nie są już potrzebne do odzyskiwania. Jeżeli kopie logu nie są wykonywane, dziennik może rosnąć mimo regularnych kopii pełnych. Przyczyną wzrostu mogą być także długo trwające lub niezatwierdzone transakcje, aktywne operacje odczytu oraz opóźnienia wymagane przez replikację lub inne mechanizmy utrzymujące rekordy logu.
Łańcuch LSN i odtwarzanie z plików .trn
Każda kopia logu zawiera zakres rekordów identyfikowanych przez numery LSN, czyli Log Sequence Numbers. Kolejna kopia musi logicznie kontynuować poprzednią kopię w tym samym łańcuchu. Z tego powodu pojedynczy plik .trn zazwyczaj nie wystarcza do odtworzenia bazy. Najpierw potrzebna jest odpowiednia pełna kopia zapasowa, opcjonalnie także kopia różnicowa, a następnie wszystkie wymagane kopie logu w kolejności ich wykonania.
Przywracanie kopii wykonuje się z użyciem RESTORE DATABASE dla kopii pełnej lub różnicowej, a dla kolejnych fragmentów dziennika — RESTORE LOG. Wszystkie kopie przywracane przed ostatnim krokiem muszą pozostawać w stanie umożliwiającym dalsze odtwarzanie, co zwykle oznacza użycie opcji NORECOVERY. Ostatni etap można zakończyć opcją RECOVERY, która udostępnia bazę użytkownikom, ale zamyka bieżącą sekwencję przywracania. Jeśli pominięto wymagany plik albo kolejność LSN jest nieciągła, SQL Server zgłosi błąd i nie pozwoli poprawnie kontynuować operacji.
Do sprawdzania zawartości i kolejności kopii można używać między innymi poleceń RESTORE HEADERONLY, RESTORE FILELISTONLY oraz RESTORE VERIFYONLY. Pierwsze z nich pokazuje nagłówkowe informacje o zestawie kopii, drugie opisuje pliki zawarte w kopii, a trzecie sprawdza, czy kopia jest kompletna i możliwa do odczytania przez SQL Server. Sama pomyślna kontrola VERIFYONLY nie dowodzi jednak, że cała strategia odzyskiwania działa. Okresowe testowe odtworzenie pełnego łańcucha jest potrzebne do sprawdzenia, czy dostępne są wszystkie pliki, hasła, certyfikaty oraz właściwe procedury.
Integralność kopii i praktyka obsługi plików .trn
Plik .trn powinien być traktowany jako część procedury odzyskiwania, a nie zwykły eksport danych. Należy kontrolować, czy kopia kończy się bez błędu, czy jej czas wykonania odpowiada harmonogramowi oraz czy plik można odczytać z miejsca przechowywania. Warto rejestrować nazwę bazy, czas rozpoczęcia i zakończenia, numer kopii, zakres LSN oraz lokalizację pliku. Ułatwia to wykrycie przerwanego łańcucha, pomyłki w nazwie albo usunięcia pliku potrzebnego podczas przywracania.
Nie należy ręcznie zmieniać zawartości pliku ani traktować zmiany rozszerzenia jako konwersji formatu. Kopię można przechowywać pod inną nazwą, ale jej wewnętrzna struktura pozostaje formatem kopii zapasowej SQL Server. Po awarii szczególne znaczenie może mieć tak zwana tail-log backup, czyli kopia końcowej części dziennika wykonana przed rozpoczęciem odtwarzania, jeżeli pliki bazy są dostępne i wymagania dotyczące odzyskania ostatnich transakcji na to pozwalają. Taka kopia nie jest automatycznie tym samym co zwykły zaplanowany plik .trn; jej zastosowanie zależy od stanu bazy i kolejności operacji ratunkowych.
Podczas diagnostyki problemu z kopiami logu trzeba rozróżnić błąd samego backupu od problemu z miejscem na dysku, uprawnieniami konta usługi SQL Server, brakiem ciągłości LSN, uszkodzeniem nośnika albo nieprawidłowym modelem odzyskiwania. W przypadku serwerowych baz danych analiza powinna obejmować historię kopii w bazie msdb, komunikaty SQL Server, rozmiar i stan pliku dziennika oraz rzeczywisty test odtworzenia. Dopiero te dane pozwalają ustalić, czy plik .trn jest prawidłową częścią łańcucha, czy jedynie istniejącym plikiem o odpowiednio nazwanym rozszerzeniu.
