Restore z logu transakcji kontynuuje odtwarzanie do konkretnego momentu po przywróceniu kopii pełnej.
Na czym polega odtwarzanie z logu transakcji
Restore z logu transakcji to etap odtwarzania bazy danych Microsoft SQL Server po przywróceniu kopii pełnej. Kopia pełna dostarcza początkowego obrazu bazy, natomiast kopie dziennika transakcji zawierają zapis zmian wykonanych później. SQL Server odtwarza te zmiany w kolejności ich zapisania, dzięki czemu można doprowadzić bazę do stanu zbliżonego do chwili awarii albo do wskazanego momentu przed wystąpieniem błędu.
Odtwarzanie dziennika wymaga zachowania ciągłości łańcucha logów. Każda kolejna kopia logu musi obejmować następny zakres numerów sekwencyjnych logu, określanych jako LSN (Log Sequence Number). Nie można dowolnie pominąć kopii dziennika znajdującej się pomiędzy kopią pełną a ostatnim wymaganym plikiem. Jeżeli brakuje fragmentu łańcucha albo plik jest uszkodzony, SQL Server może przerwać operację, ponieważ nie ma kompletnego zestawu informacji potrzebnych do odtworzenia zmian.
Warunki poprawnej kolejności operacji
Typowa procedura rozpoczyna się od przywrócenia kopii pełnej z opcją NORECOVERY. Baza pozostaje wtedy w stanie odtwarzania i przyjmuje następne kopie różnicowe lub logu. Następnie można użyć polecenia RESTORE LOG dla kolejnych plików dziennika, również z NORECOVERY, dopóki nie zostanie zastosowana ostatnia kopia. Dopiero końcowe polecenie z opcją RECOVERY otwiera bazę do normalnej pracy i kończy sekwencję odtwarzania.
Przykładowy schemat dla SQL Server może wyglądać następująco: RESTORE DATABASE Baza FROM DISK = 'pelna.bak' WITH NORECOVERY;, a potem RESTORE LOG Baza FROM DISK = 'log_001.trn' WITH NORECOVERY; oraz kolejne polecenia dla następnych kopii logu. Po zastosowaniu ostatniego pliku używa się RESTORE LOG Baza FROM DISK = 'log_003.trn' WITH RECOVERY;. Przed wykonaniem operacji trzeba dopasować nazwę bazy, ścieżki plików oraz układ plików logicznych do konkretnej instancji SQL Server.
Odtwarzanie do określonego momentu
SQL Server pozwala ograniczyć odtwarzanie logu do wskazanej chwili za pomocą opcji STOPAT. Przykładowo RESTORE LOG Baza FROM DISK = 'log_003.trn' WITH STOPAT = '2026-08-24T14:35:00', RECOVERY; oznacza próbę zakończenia odtwarzania o podanym czasie. Wartość musi mieścić się w zakresie objętym danym plikiem dziennika. Jeżeli moment znajduje się w późniejszej kopii, poprzednie pliki należy odtworzyć z NORECOVERY, a STOPAT zastosować w odpowiednim, ostatnim pliku.
Odtwarzanie punktualne jest możliwe tylko wtedy, gdy dziennik zawiera wymagane operacje oraz nie został przerwany łańcuch logów. Czas zapisany w kopii i czas używany przez STOPAT trzeba interpretować z uwzględnieniem konfiguracji serwera oraz formatu daty. W praktyce bezpieczniej jest stosować jednoznaczny zapis ISO i wcześniej sprawdzić zakres LSN oraz metadane kopii poleceniem RESTORE HEADERONLY. Do weryfikacji historii kopii można wykorzystać także tabelę msdb.dbo.backupset, która przechowuje informacje o wykonanych backupach.
Kontrola spójności po zakończeniu restore
Po zakończeniu odtwarzania należy sprawdzić stan bazy oraz wykonać kontrolę strukturalnej spójności poleceniem DBCC CHECKDB. Samo pomyślne wykonanie poleceń RESTORE potwierdza odczyt i zastosowanie kopii, ale nie zastępuje pełnej weryfikacji użyteczności danych. Warto również sprawdzić, czy baza otworzyła się z opcją RECOVERY, czy użytkownicy mogą wykonywać wymagane operacje oraz czy ostatnie transakcje zostały odtworzone zgodnie z założonym punktem czasowym.
Jeżeli baza ma pozostać dostępna w trybie tylko do odczytu pomiędzy kolejnymi etapami, SQL Server obsługuje opcję STANDBY, która wykorzystuje plik cofania zmian. Ten wariant ma ograniczenia i nie powinien być wybierany bez sprawdzenia procedury dalszego odtwarzania. W środowisku diagnostycznym można przywrócić kopie na oddzielnej instancji, porównać oczekiwany moment odzyskania i dopiero później wykonać właściwą procedurę. Przy problemach z nośnikiem, plikami .bak lub .trn oraz błędami odczytu potrzebna jest diagnostyka sprzętu i kopii, ponieważ uszkodzenie dysku może uniemożliwić dalsze odtwarzanie niezależnie od poprawności składni polecenia.
