Plik logu kopii zapasowej (.trn)

Plik .trn to kopia dziennika transakcji, niezbędna do odtworzenia bazy do wybranego momentu w czasie.

Czym jest plik kopii dziennika transakcji .trn

Rozszerzenie .trn jest powszechnie używane dla pliku kopii zapasowej dziennika transakcji w Microsoft SQL Server. Taki plik zawiera zapis zmian utrwalonych w dzienniku transakcji od momentu wykonania poprzedniej kopii dziennika. Nie jest to samodzielna kopia całej bazy danych i nie można traktować go jako zamiennika kopii pełnej. Jego zadaniem jest umożliwienie odtworzenia kolejnych operacji wykonanych w bazie oraz ograniczenie utraty danych do niewielkiego przedziału czasu.

Kopie dziennika są dostępne wtedy, gdy baza działa w modelu odzyskiwania FULL albo BULK_LOGGED. W modelu SIMPLE SQL Server automatycznie ponownie wykorzystuje nieaktywne fragmenty dziennika i nie obsługuje kopii zapasowych logu. Plik .trn zachowuje między innymi informacje potrzebne do zachowania ciągłości łańcucha kopii dziennika, dlatego jego użyteczność zależy od poprawności wcześniejszych elementów zestawu oraz od zgodności numerów sekwencyjnych zapisanych w nagłówkach kopii.

Rola pliku .trn w odzyskiwaniu bazy

Odtwarzanie bazy SQL Server zwykle rozpoczyna się od przywrócenia kopii pełnej, a następnie — zależnie od przyjętej strategii — kopii różnicowej i kolejnych kopii dziennika transakcji. Każdą kopię dziennika trzeba zastosować w odpowiedniej kolejności, bez pominięcia wymaganych fragmentów łańcucha. Przywracanie kolejnych plików wykonuje się z użyciem polecenia RESTORE LOG. Ostatni etap może zakończyć się przywróceniem bazy do normalnej pracy za pomocą opcji WITH RECOVERY; wcześniejsze etapy pozostawia się zwykle w stanie oczekiwania na kolejne kopie, używając WITH NORECOVERY.

Jeżeli dziennik jest dostępny do odczytu, SQL Server może również obsłużyć tak zwaną kopię końca dziennika, wykonywaną po awarii, ale przed rozpoczęciem właściwego odtwarzania. Pozwala ona zachować transakcje, które nie zostały jeszcze objęte wcześniejszą kopią .trn. W scenariuszach wymagających odtworzenia do konkretnej chwili używa się punktu w czasie, na przykład przez opcję STOPAT. Skuteczne zastosowanie tej opcji wymaga kompletnego, nieprzerwanego łańcucha kopii dziennika oraz znajomości czasu zapisanych operacji.

Wykonywanie i kontrola kopii dziennika

Kopię dziennika tworzy się poleceniem BACKUP LOG, wskazując bazę oraz miejsce zapisu pliku. Przykładowa składnia może wyglądać następująco: BACKUP LOG [NazwaBazy] TO DISK = N'D:\Backup\NazwaBazy_2026-08-24_1200.trn'. Sama nazwa pliku nie decyduje o jego zawartości, ale stosowanie jednoznacznych nazw z nazwą bazy, datą i godziną ułatwia późniejszą identyfikację. Harmonogram wykonywania kopii powinien odpowiadać dopuszczalnemu oknu utraty danych, ponieważ awaria pomiędzy kolejnymi kopiami może objąć transakcje jeszcze niezapisane w pliku .trn.

Przed usunięciem lub przeniesieniem kopii należy sprawdzić, czy nie jest ona potrzebna do odtworzenia późniejszych punktów. Do kontroli metadanych kopii służą między innymi polecenia RESTORE HEADERONLY i RESTORE FILELISTONLY, natomiast historia operacji może być przechowywana w bazie msdb. Istotne są między innymi identyfikatory bazy, zakresy czasu, numery sekwencyjne kopii dziennika oraz informacja o tym, z jakiej kopii należy kontynuować odtwarzanie. W środowisku produkcyjnym nie wystarcza sprawdzenie, że plik istnieje: kopie trzeba okresowo testowo odtwarzać na odseparowanym systemie.

Typowe problemy z plikiem .trn i diagnostyka

Najczęstszym problemem jest przerwany łańcuch kopii dziennika. Może do niego doprowadzić utrata pliku, usunięcie kopii przed wykonaniem nowej kopii pełnej, zmiana modelu odzyskiwania na SIMPLE, a następnie powrót do FULL, albo rozpoczęcie nowego łańcucha po określonych operacjach administracyjnych. W takiej sytuacji późniejszy plik .trn może być poprawny technicznie, ale nie będzie możliwy do zastosowania bez brakującego poprzednika. Błąd może pojawić się również wtedy, gdy kopia dotyczy innej bazy lub pochodzi z innego środowiska.

Przy awarii dysku, ransomware albo uszkodzeniu systemu należy najpierw ustalić, jakie kopie rzeczywiście są dostępne, a następnie zbudować kolejność odtwarzania od ostatniej użytecznej kopii pełnej. Pliki .trn powinny być przechowywane na nośniku niezależnym od serwera SQL Server i chronione przed przypadkowym nadpisaniem. Należy także kontrolować wolne miejsce, uprawnienia konta usługi SQL Server do katalogu docelowego oraz wyniki zadań agenta SQL Server. W przypadku uszkodzenia laptopa lub komputera używanego do przechowywania kopii diagnostyka nośnika powinna poprzedzać próby kopiowania i otwierania plików, aby nie pogłębić problemu z odczytem danych.