Restore na nowy serwer

Restore na nowy serwer wymaga przeniesienia także powiązanych obiektów spoza samej bazy, np. loginów i zadań.

Na czym polega restore bazy SQL Server na nowy serwer

Restore na nowy serwer w środowisku Microsoft SQL Server oznacza odtworzenie bazy danych z kopii zapasowej na innej instancji SQL Server. Sama operacja przywraca obiekty znajdujące się wewnątrz bazy, między innymi tabele, widoki, procedury składowane, funkcje, dane oraz uprawnienia zapisane na poziomie tej bazy. Nie przenosi jednak automatycznie całej konfiguracji instancji, na której wcześniej działała baza.

Nowa instancja może mieć inną nazwę, inną ścieżkę plików danych i dziennika transakcji, inne ustawienia zabezpieczeń oraz inne konta usług. Przed rozpoczęciem trzeba ustalić, z jakiej wersji SQL Server pochodzi kopia i czy docelowa instancja obsługuje jej format. Kopii z nowszej wersji SQL Server nie można przywrócić bezpośrednio do starszej wersji silnika. Należy także sprawdzić, czy dostępna kopia jest pełna, czy obejmuje również wymagane kopie różnicowe albo dziennika transakcji.

Obiekty serwerowe, których nie obejmuje kopia bazy

Najważniejszą różnicą jest zakres przechowywania obiektów. Login w SQL Server jest obiektem na poziomie instancji i zwykle znajduje się w bazie systemowej master, dlatego nie jest częścią kopii zapasowej pojedynczej bazy użytkownika. Po odtworzeniu baza może zawierać użytkownika o określonej nazwie, ale nowa instancja może nie mieć odpowiadającego mu loginu. Taki użytkownik jest wtedy osierocony, czyli nie ma poprawnego powiązania z loginem używanym do uwierzytelnienia.

Podczas przygotowania migracji trzeba zinwentaryzować loginy, ich typ, domyślną bazę, członkostwo w rolach serwerowych oraz identyfikator SID. Przy logowaniu SQL Server identyfikator SID decyduje o powiązaniu loginu z użytkownikiem bazy. Utworzenie nowego loginu o tej samej nazwie, lecz z innym SID, nie zawsze przywróci dostęp. Konieczne może być odtworzenie loginu z właściwym SID albo ponowne powiązanie użytkownika z właściwym loginem, po wcześniejszym potwierdzeniu wymaganych uprawnień.

SQL Server Agent, harmonogramy i zależności poza bazą

Zadania SQL Server Agent są przechowywane w bazie systemowej msdb, a nie w odtwarzanej bazie użytkownika. Dlatego restore nie przywróci automatycznie harmonogramów, kroków zadań, warunków rozpoczęcia ani informacji o właścicielach zadań. Po migracji zadania mogą nie istnieć, mogą być wyłączone albo mogą uruchamiać się pod loginem, który nie został utworzony na nowej instancji.

Przed przełączeniem należy sprawdzić również elementy wykorzystywane przez kroki zadań: ścieżki plików, udziały sieciowe, konta proxy, poświadczenia, operatorów powiadomień oraz nazwy baz podane w poleceniach. Jeżeli zadanie wykonuje kopie zapasowe, importuje pliki lub uruchamia procedurę składowaną, trzeba potwierdzić dostęp do każdego zasobu i zgodność nazwy instancji. Warto odtworzyć definicje zadań w kontrolowany sposób, a następnie wykonać próbne uruchomienie pojedynczych kroków z odpowiednim kontem wykonawczym.

Kontrola działania po przywróceniu

Poprawne zakończenie polecenia RESTORE DATABASE nie oznacza jeszcze, że aplikacja będzie działać tak jak przed migracją. Po przywróceniu trzeba zweryfikować stan bazy, dostęp użytkowników, właściciela bazy, ustawienia zgodności oraz mapowanie użytkowników na loginy. Należy także sprawdzić, czy aplikacja wskazuje właściwą nazwę serwera i instancji, a łańcuch połączenia nie zawiera starego adresu lub portu.

Test powinien obejmować odczyt i zapis danych, wykonanie najważniejszych procedur składowanych, działanie zadań SQL Server Agent oraz utworzenie i odtworzenie kopii zapasowej na nowym środowisku. W przypadku bazy przywracanej z szeregu kopii trzeba zachować właściwą kolejność: pełna kopia, ewentualna różnicowa oraz kolejne kopie dziennika transakcji. Dopiero po potwierdzeniu tych zależności można uznać migrację za zakończoną technicznie.