Plan przywracania

Plan przywracania obejmuje kopię pełną, ewentualną różnicową i wszystkie kolejne kopie dziennika transakcji.

Łańcuch kopii tworzących plan przywracania

Plan przywracania w SQL Server określa kolejność użycia kopii zapasowych potrzebnych do odtworzenia bazy danych do określonego momentu. Jego podstawą jest pełna kopia bazy danych. Jeżeli stosowane są kopie różnicowe, plan obejmuje również wybraną kopię różnicową oraz wszystkie kopie dziennika transakcji wykonane po pełnej kopii, od której zależy ta kopia różnicowa. Kopia różnicowa zawiera zmiany od czasu wykonania bazowej kopii pełnej, dlatego nie zastępuje jej w procesie przywracania.

W modelu odzyskiwania full albo bulk-logged SQL Server rejestruje operacje w dzienniku transakcji i może wykonywać jego kopie zapasowe. Każda kolejna kopia dziennika jest elementem tego samego łańcucha i musi być przywracana w prawidłowej kolejności. Nie można pominąć kopii dziennika znajdującej się pomiędzy kopią bazową a docelowym punktem odtworzenia. W praktyce plan powinien wskazywać identyfikatory kopii, czas ich wykonania, lokalizację plików oraz moment, do którego baza ma zostać odtworzona.

Dobór punktu odtworzenia i kompletności danych

Przywracanie rozpoczyna się od pełnej kopii bazy. Następnie można zastosować najnowszą kopię różnicową wykonaną po tej kopii pełnej. Po przywróceniu kopii różnicowej stosuje się kopie dziennika transakcji wykonane po kopii różnicowej, a także odpowiednie kolejne kopie dziennika aż do osiągnięcia wymaganego czasu. Jeżeli nie użyto kopii różnicowej, po pełnej kopii należy odtworzyć wszystkie wymagane kopie dziennika od pierwszej kopii wykonanej po pełnej kopii.

SQL Server pozwala zakończyć odtwarzanie na określonym czasie za pomocą opcji STOPAT w instrukcji RESTORE LOG. Jest to przydatne, gdy trzeba cofnąć skutki błędnej operacji wykonanej o znanej godzinie. Warunkiem jest posiadanie nieprzerwanego łańcucha dziennika obejmującego ten moment. Jeżeli uszkodzenie wystąpiło przed wykonaniem ostatniej kopii dziennika, można wykorzystać tail-log backup, o ile plik dziennika i baza są dostępne w zakresie pozwalającym na jego utworzenie.

Tryby NORECOVERY, RECOVERY i kontrola kolejności

Podczas odtwarzania pełnej kopii oraz kolejnych kopii dziennika bazę pozostawia się w stanie niegotowym do użycia, stosując opcję WITH NORECOVERY. Ten tryb umożliwia zastosowanie następnej kopii z tego samego łańcucha. Przykładowa sekwencja obejmuje RESTORE DATABASE ... WITH NORECOVERY, potem jedno lub więcej poleceń RESTORE LOG ... WITH NORECOVERY, a na końcu RESTORE LOG ... WITH RECOVERY. Ostatnia operacja kończy fazę przywracania i udostępnia bazę użytkownikom.

Po użyciu WITH RECOVERY nie można kontynuować tego samego łańcucha kopii dziennika. Z tego powodu przed zakończeniem operacji trzeba ustalić, czy istnieją jeszcze kopie, które mają zostać zastosowane, oraz czy wymagany jest konkretny czas odtworzenia. Do weryfikacji zawartości plików kopii służą między innymi polecenia RESTORE HEADERONLY i RESTORE FILELISTONLY. Można także użyć RESTORE VERIFYONLY, jednak pomyślne sprawdzenie struktury kopii nie gwarantuje, że każda kopia w łańcuchu jest dostępna ani że cała procedura zakończy się poprawnie.

Testowanie planu przywracania bazy SQL Server

Plan powinien być opisany jako powtarzalna procedura, a nie tylko jako lista plików znajdujących się na nośniku. Dokumentacja powinna określać nazwę bazy, model odzyskiwania, kolejność kopii, wymagany punkt odtworzenia, sposób odtworzenia plików oraz czynności kontrolne po zakończeniu. Warto przechowywać także informacje o rozmiarach kopii, czasie ich wykonania i wyniku zadania tworzącego backup. Osobno należy sprawdzić, czy kopie dziennika wykonywały się regularnie, ponieważ przerwanie tego procesu może uniemożliwić odzyskanie danych do późniejszego momentu.

Test odtworzeniowy powinien odbywać się w odseparowanym środowisku i obejmować rzeczywistą sekwencję: pełna kopia, wybrana różnicowa kopia zapasowa, wszystkie wymagane kopie dziennika oraz zakończenie przez WITH RECOVERY. Po otwarciu bazy można sprawdzić jej dostępność, integralność logiczną poleceniem DBCC CHECKDB oraz obecność danych z oczekiwanego czasu. W środowisku serwerowym plan przywracania powinien również uwzględniać zależności aplikacji, zgodność nazw plików i uprawnień oraz czas potrzebny na wykonanie całej procedury, ponieważ sama obecność kopii nie potwierdza gotowości do odzyskania usługi.