Restore bazy systemowej

Restore bazy systemowej wymaga trybu jednego użytkownika i wykonania go z zachowaniem szczególnej ostrożności.

Na czym polega restore bazy systemowej

Restore bazy systemowej oznacza odtworzenie zapisanej wcześniej kopii jednej z baz, które przechowują informacje niezbędne do pracy instancji Microsoft SQL Server. Do takich baz należą między innymi master, model, msdb i tempdb, ale każda z nich ma inną rolę oraz inne wymagania dotyczące odtwarzania. Kopia zapasowa musi pochodzić z tego samego silnika lub z wersji SQL Server zgodnej z zasadami odtwarzania kopii. Nie można traktować wszystkich baz systemowych jako jednego zasobu ani odtwarzać ich bez sprawdzenia, jaki element środowiska został uszkodzony.

Baza master zawiera między innymi informacje o konfiguracji instancji, bazach użytkownika, logowaniach i punktach końcowych. Baza msdb przechowuje dane związane z zadaniami SQL Server Agent, historią kopii zapasowych oraz planami konserwacji. Baza model służy jako wzorzec dla nowo tworzonych baz, natomiast tempdb jest tworzona ponownie podczas uruchamiania usługi i nie jest odtwarzana z klasycznej kopii zapasowej. Z tego powodu procedura restore musi być dobrana do konkretnej bazy, a nie tylko do ogólnego komunikatu o problemie z bazą systemową.

Tryb jednego użytkownika i kontrola dostępu

Odtwarzanie niektórych baz systemowych SQL Server, szczególnie master, wymaga uruchomienia instancji w trybie jednego użytkownika. W tym trybie tylko jedno połączenie może zostać zaakceptowane przez serwer. Warunek ten jest istotny, ponieważ podczas odtwarzania baza musi zostać przejęta przez procedurę przywracania, a równoczesne połączenie aplikacji, usługi monitorującej albo narzędzia administracyjnego może zająć jedyne dostępne miejsce.

Samo ustawienie trybu jednego użytkownika nie gwarantuje, że właściwe narzędzie uzyska dostęp. Jeżeli jako pierwsza połączy się usługa SQL Server Agent, aplikacja kliencka albo automatyczny skaner, administrator może otrzymać komunikat o braku możliwości przejęcia bazy. Przed rozpoczęciem należy więc zatrzymać procesy korzystające z instancji, zamknąć zbędne sesje i potwierdzić, jakie konto będzie wykonywało restore. Należy również unikać uruchamiania kilku narzędzi administracyjnych jednocześnie, ponieważ nawet krótkie połączenie może zostać potraktowane jako wykorzystanie jedynego dozwolonego kanału.

Kolejność odtwarzania i konsekwencje dla instancji

Przed restore trzeba zweryfikować integralność pliku kopii, jego pochodzenie, datę wykonania oraz zakres zawartych danych. W przypadku bazy master ważne jest ustalenie, czy kopia obejmuje konfigurację odpowiadającą aktualnemu układowi plików i baz. Po odtworzeniu starszej kopii mogą powrócić wcześniejsze definicje logowań, ustawień instancji, ścieżek baz lub innych obiektów zapisanych w master. Oznacza to, że przywrócenie pliku nie jest wyłącznie operacją naprawczą, lecz może zmienić stan administracyjny całego serwera.

Baza msdb wymaga osobnej oceny, ponieważ restore może cofnąć historię zadań, harmonogramy, konfigurację SQL Server Agent i informacje o wykonanych kopiach. Po zakończeniu należy sprawdzić, czy zadania nadal wskazują prawidłowe ścieżki, czy harmonogramy działają oraz czy konta wykonawcze mają wymagane uprawnienia. W przypadku bazy model trzeba uwzględnić wpływ jej zawartości na późniejsze tworzenie nowych baz. Tempdb jest odtwarzana inaczej: po zatrzymaniu i ponownym uruchomieniu SQL Server tworzona jest na podstawie konfiguracji instancji, dlatego należy kontrolować dostępność ścieżek, rozmiary plików i możliwość ich utworzenia.

Jeżeli uszkodzenie obejmuje więcej niż jedną bazę systemową, kolejność działań powinna wynikać z zależności między nimi oraz z dokumentacji konkretnej wersji SQL Server. Po każdym etapie należy potwierdzić możliwość uruchomienia usługi, dostęp do baz użytkownika, poprawność logowania i działanie zaplanowanych zadań. Wykonywanie kolejnych operacji bez sprawdzenia poprzedniej może utrudnić ustalenie, która zmiana spowodowała następny problem.

Weryfikacja po przywróceniu kopii

Po zakończeniu restore należy odczytać dzienniki SQL Server i systemu operacyjnego, a następnie sprawdzić stan wszystkich baz oraz komunikaty zgłaszane podczas startu instancji. Kontroli wymagają między innymi dostępność bazy master, możliwość otwarcia baz użytkownika, logowania administracyjne, zadania SQL Server Agent i konfiguracja kopii zapasowych. Sam fakt pomyślnego zakończenia polecenia przywracania nie dowodzi, że instancja działa prawidłowo w typowym obciążeniu.

Warto wykonać kontrolne zapytania diagnostyczne, sprawdzić spójność logiczną odtworzonych baz odpowiednimi mechanizmami SQL Server oraz porównać konfigurację z dokumentacją środowiska. Należy też potwierdzić, czy po przywróceniu nie pojawiły się brakujące logowania, zmienione ścieżki plików, nieaktywne harmonogramy albo błędy uprawnień. W środowisku, w którym baza systemowa zawiera informacje o zadaniach i kopiach, trzeba dodatkowo ocenić, czy historia i konfiguracja odpowiadają rzeczywistemu stanowi infrastruktury.

Diagnostyka i naprawa takiej awarii wymaga pracy na kopii zapasowej, kontrolowanego dostępu do instancji oraz zachowania kolejności czynności. W przypadku komputera używanego lokalnie istotne jest także zabezpieczenie plików kopii, potwierdzenie dostępności miejsca na dysku i sprawdzenie, czy usługa SQL Server może zostać bezpiecznie zatrzymana oraz ponownie uruchomiona.