Nieudany restore

Nieudany restore to przerwana operacja odtwarzania, po której baza pozostaje w stanie RESTORING i jest niedostępna.

Co oznacza stan RESTORING po nieudanym odtwarzaniu

Nieudany restore w SQL Server oznacza sytuację, w której operacja odtwarzania kopii zapasowej nie zakończyła się poprawnie, a baza danych nadal znajduje się w stanie RESTORING. W tym stanie SQL Server nie udostępnia bazy do normalnej pracy użytkowników. Jest ona traktowana jako oczekująca na dalsze odtwarzanie, zwykle kolejnego backupu różnicowego albo kopii dziennika transakcji.

Sam status RESTORING nie zawsze oznacza awarię. Może być wynikiem prawidłowego użycia opcji WITH NORECOVERY, która pozostawia bazę w stanie oczekiwania na następny element sekwencji backupów. Problem powstaje wtedy, gdy restore został przerwany, zgłosił błąd albo dalsze pliki kopii nie są dostępne, a baza miała już zostać przywrócona do użycia. Próba otwarcia takiej bazy w aplikacji kończy się wtedy błędem lub brakiem połączenia.

Najczęstsze przyczyny przerwania operacji restore

Jedną z przyczyn jest niezgodność sekwencji kopii. Przy odtwarzaniu pełnego backupu, backupu różnicowego i kolejnych backupów dziennika transakcji SQL Server sprawdza między innymi identyfikatory bazy, zakresy LSN oraz kolejność zapisów. Backup różnicowy musi odnosić się do właściwej kopii pełnej, a backup dziennika musi należeć do odpowiedniego łańcucha logów. Brak wcześniejszego elementu albo próba użycia kopii z innej gałęzi powoduje odrzucenie operacji.

Restore może również zakończyć się błędem z powodu uszkodzonego pliku backupu, niepełnego skopiowania pliku, braku dostępu do lokalizacji, niewystarczającego miejsca na dysku lub problemu z plikami danych i dziennika. Znaczenie ma także docelowa wersja SQL Server. Kopii utworzonej na nowszej wersji silnika nie można przywrócić na starszej wersji. Podczas analizy trzeba odczytać pełny komunikat z historii zadań SQL Server Agent, dziennika SQL Server oraz wyniku polecenia RESTORE, ponieważ sam status bazy nie wskazuje konkretnej przyczyny.

Warto odróżnić błąd od celowego pozostawienia bazy w trybie oczekiwania. RESTORE DATABASE ... WITH NORECOVERY kończy etap technicznego odtwarzania, ale nie wykonuje odzyskiwania bazy do normalnego stanu. Jeżeli nie ma już następnego backupu dziennika, wykonuje się końcowy etap za pomocą RESTORE DATABASE ... WITH RECOVERY. Ta operacja zamyka sekwencję restore i powoduje przejście bazy do stanu dostępnego dla użytkowników.

Sprawdzanie łańcucha backupów i stanu bazy

Diagnostykę należy rozpocząć od sprawdzenia bieżącego stanu bazy w widoku sys.databases. Kolumna state_desc pozwala potwierdzić, czy baza jest w stanie RESTORING, RECOVERY_PENDING, OFFLINE albo ONLINE. Przydatne jest także sprawdzenie pola user_access_desc, ponieważ ograniczenie dostępu może być dodatkowym skutkiem procesu odtwarzania, ale nie zastępuje analizy właściwego błędu.

Pliki backupów można weryfikować poleceniem RESTORE HEADERONLY oraz RESTORE FILELISTONLY. Pierwsze z nich pokazuje metadane zestawu kopii, między innymi typ backupu, identyfikator zestawu i informacje o bazie. Drugie pozwala sprawdzić logiczne i fizyczne nazwy plików zapisanych w kopii. Polecenie RESTORE VERIFYONLY może pomóc ocenić, czy zestaw backupu jest kompletny i czy można go odczytać, ale nie daje gwarancji, że odtworzenie zakończy się sukcesem w konkretnej konfiguracji docelowej.

Przed próbą kontynuowania restore należy ustalić, na którym etapie zakończyła się poprzednia operacja. Jeżeli pełna kopia została odtworzona z NORECOVERY, można potrzebować właściwego backupu różnicowego i kolejnych logów. Jeżeli odtworzono wszystkie wymagane kopie dziennika, ostatnim krokiem może być WITH RECOVERY. Trzeba zachować kolejność oraz zakres czasowy logów. Przedwczesne użycie WITH RECOVERY kończy sekwencję i uniemożliwia dołożenie kolejnych backupów dziennika do tej samej sesji odtwarzania.

Bezpieczne zakończenie lub ponowienie odtwarzania

Wybór sposobu naprawy zależy od tego, czy dostępny jest kompletny i poprawny łańcuch kopii. Gdy wszystkie wymagane backupy są dostępne, restore można kontynuować od właściwego etapu, zachowując odpowiednie opcje NORECOVERY aż do ostatniej kopii. Po zakończeniu ostatniego odtwarzania wykonuje się odzyskiwanie przez WITH RECOVERY. Jeżeli używany jest tryb STANDBY, SQL Server może udostępniać bazę tylko do odczytu pomiędzy kolejnymi operacjami restore, zapisując informacje potrzebne do dalszej pracy.

Jeżeli łańcuch backupów jest niekompletny, nie należy zgadywać kolejności ani zastępować brakującego logu przypadkową kopią. Konieczne jest ustalenie najnowszej dostępnej pełnej kopii, właściwego backupu różnicowego oraz ciągłego zestawu backupów dziennika. W niektórych scenariuszach przed odtworzeniem trzeba także wykonać kopię końca dziennika transakcji, o ile źródłowa baza i jej pliki są nadal dostępne. Pozwala to zachować możliwie najnowsze zmiany, ale wymaga poprawnego dostępu do instancji i plików bazy.

Przywracanie bazy SQL Server po nieudanym restore powinno obejmować również kontrolę ścieżek plików, uprawnień konta usługi, wolnego miejsca, zgodności wersji silnika oraz integralności backupów. Po przejściu bazy do stanu ONLINE należy sprawdzić dostęp aplikacji, podstawowe obiekty oraz spójność danych odpowiednimi procedurami kontrolnymi. Samo pojawienie się statusu ONLINE nie potwierdza jeszcze, że odtworzono właściwy punkt w czasie ani że proces biznesowy może bezpiecznie wznowić pracę.