Tail-Log Backup

Tail-Log Backup to ostatnia kopia dziennika wykonana tuż przed odtworzeniem, zapobiegająca utracie niezapisanych transakcji.

Rola Tail-Log Backup w odzyskiwaniu bazy SQL Server

Tail-Log Backup to kopia końcowego fragmentu dziennika transakcji bazy Microsoft SQL Server, wykonywana bezpośrednio przed rozpoczęciem operacji odtwarzania. Jej zadaniem jest zachowanie rekordów dziennika, które powstały po ostatniej regularnej kopii dziennika transakcji, lecz nie zostały jeszcze zapisane w żadnym pliku backupu. Dzięki temu można ograniczyć utratę zmian wykonanych po utworzeniu poprzedniej kopii. Nie jest to pełna kopia bazy ani osobny mechanizm cofania transakcji. To kolejny element łańcucha kopii zapasowych dziennika.

Określenie „tail” odnosi się do końca dziennika, czyli jego najnowszej części. W typowym scenariuszu baza uległa awarii albo jej pliki danych stały się niedostępne, a administrator chce rozpocząć odtwarzanie kopii pełnej, różnicowej i kolejnych kopii dziennika. Przed przywracaniem należy spróbować zapisać jeszcze końcowy fragment logu. Jeżeli operacja się powiedzie, Tail-Log Backup może zostać użyty jako ostatni element sekwencji RESTORE LOG, a następnie wykonywane jest RESTORE DATABASE ... WITH RECOVERY.

Warunki wykonania kopii końcowej

Tail-Log Backup ma zastosowanie przede wszystkim wtedy, gdy baza korzysta z modelu odzyskiwania full albo bulk-logged i działa ciągłość kopii dziennika. W modelu simple SQL Server nie utrzymuje dziennika w sposób pozwalający na wykonywanie regularnych kopii logu, dlatego nie można wykorzystać tego mechanizmu do zachowania końcowych transakcji. Sama dostępność wcześniejszej kopii pełnej również nie wystarcza: przywracanie do możliwie najnowszego punktu wymaga zachowania zgodnego łańcucha log backups.

Standardowe polecenie ma postać BACKUP LOG [NazwaBazy] TO DISK = 'D:\Backup\NazwaBazy_tail.trn' WITH NO_TRUNCATE;. Opcja NO_TRUNCATE pozwala wykonać kopię dziennika bez jego obcinania w sytuacji, w której baza jest uszkodzona, niedostępna albo znajduje się w stanie wymagającym specjalnego postępowania. Lokalizacja pliku musi znajdować się na nośniku dostępnym dla procesu SQL Server, a konto usługi musi mieć odpowiednie uprawnienia do zapisu. Przed użyciem konkretnej opcji trzeba sprawdzić stan bazy, dostępność plików i aktualną dokumentację używanej wersji SQL Server.

Pozycja w łańcuchu operacji RESTORE

Kopia końcowego dziennika jest użyteczna tylko wtedy, gdy zostanie odtworzona w prawidłowej kolejności. Najpierw przywraca się kopię pełną, opcjonalnie kopię różnicową, a potem kopie dziennika transakcji od najstarszej wymaganej do najnowszej. Wszystkie kopie pośrednie, poza ostatnią, są zwykle odtwarzane z opcją WITH NORECOVERY, aby baza pozostała w stanie oczekiwania na następny plik. Tail-Log Backup powinien być odtworzony po poprzedniej poprawnej kopii logu, o ile jego numer sekwencyjny dziennika i zakres LSN na to wskazują.

Nie wolno zakładać, że każdy plik opisany jako „tail” automatycznie pasuje do konkretnego łańcucha. SQL Server identyfikuje ciągłość dziennika między innymi za pomocą numerów sekwencyjnych i zakresów LSN, czyli Log Sequence Number. Przed odtwarzaniem można użyć polecenia RESTORE HEADERONLY oraz RESTORE FILELISTONLY do sprawdzenia metadanych backupu. Weryfikacji wymaga także zgodność nazwy bazy, czasu wykonania, typu kopii i wartości wskazujących początek oraz koniec zakresu dziennika. Przedwczesne użycie WITH RECOVERY kończy sekwencję odtwarzania i uniemożliwia dołożenie kolejnych kopii logu.

Znaczenie poprawnej diagnostyki przed odtworzeniem

Problemy z Tail-Log Backup często wynikają nie z samej składni polecenia, lecz ze stanu środowiska. Trzeba ustalić, czy baza nadal jest dostępna, czy pliki dziennika i danych znajdują się na sprawnym nośniku, czy proces SQL Server może odczytać dziennik oraz czy w czasie awarii nie zmieniono modelu odzyskiwania. Istotne jest również zachowanie oryginalnych plików backupu i zebranie informacji o ostatnich udanych kopiach. Nadpisanie pliku, usunięcie dziennika albo uruchomienie operacji naprawczej bez wcześniejszej kopii może zmniejszyć zakres możliwego odzyskania.

W diagnostyce analizuje się komunikaty SQL Server, historię zadań backupu, wpisy w SQL Server Error Log oraz metadane plików kopii. Jeżeli baza jest uszkodzona, należy rozdzielić dwa cele: zachowanie najnowszych rekordów logu i naprawę logicznej lub fizycznej spójności danych. Tail-Log Backup realizuje tylko pierwszy z tych celów. Po odtworzeniu trzeba sprawdzić dostępność bazy, wyniki kontroli spójności oraz kompletność danych aplikacyjnych. W przypadku laptopa lub komputera PC problem może dotyczyć także awarii dysku, systemu plików albo nagłego zaniku zasilania, dlatego przed dalszymi operacjami potrzebna jest ostrożna diagnostyka nośnika i kopii.