Export-DbaLogin

Export-DbaLogin to polecenie modułu PowerShell dbatools eksportujące definicje loginów SQL Server do skryptu.

Rola Export-DbaLogin w administracji SQL Server

Export-DbaLogin jest poleceniem modułu PowerShell dbatools przeznaczonym do eksportowania definicji loginów z instancji Microsoft SQL Server do pliku zawierającego instrukcje Transact-SQL. Login jest obiektem na poziomie całej instancji, a nie pojedynczej bazy danych. Służy do uwierzytelniania użytkownika lub aplikacji wobec SQL Server i może być powiązany z użytkownikiem utworzonym w konkretnej bazie.

Eksport przydaje się przede wszystkim podczas odtwarzania konfiguracji po migracji instancji, przenoszenia ustawień dostępu na drugi serwer albo przygotowywania skryptu awaryjnego. Polecenie zapisuje informacje potrzebne do ponownego utworzenia obsługiwanych loginów, w tym ich typ, nazwę, identyfikator SID, ustawienia domyślnej bazy i języka oraz przypisania do ról serwerowych. Zakres generowanego skryptu zależy od rodzaju loginu i dostępnych uprawnień konta wykonującego eksport.

Przykładowe użycie i wybór loginów

Najprostsze wywołanie może wyglądać następująco: Export-DbaLogin -SqlInstance 'SQL01' -Path 'C:\Backup\logins.sql'. Parametr -SqlInstance wskazuje instancję SQL Server, natomiast -Path określa plik wynikowy. Przy instancji nazwanej należy podać nazwę w formacie używanym przez narzędzia SQL Server, na przykład SQL01\PRODUKCJA. Plik powinien być zapisywany w lokalizacji, do której proces PowerShell ma prawo zapisu.

Eksport można ograniczyć do wybranych loginów za pomocą parametrów filtrowania dostępnych w danej wersji dbatools, zamiast generować skrypt dla całej instancji. W praktyce przed uruchomieniem warto sprawdzić składnię poleceniem Get-Help Export-DbaLogin -Full oraz listę parametrów przez Get-Command Export-DbaLogin -Syntax. Przykładowy schemat z poświadczeniami SQL Server to Export-DbaLogin -SqlInstance 'SQL01' -SqlCredential $credential -Path 'C:\Backup\logins.sql', gdzie zmienna $credential zawiera obiekt PSCredential.

Co rzeczywiście trafia do skryptu

Wynik działania nie jest kopią baz danych ani pełnym eksportem bezpieczeństwa SQL Server. Skrypt może odtwarzać definicje loginów Windows, grup Windows oraz loginów uwierzytelnianych przez SQL Server, a także ustawienia związane z ich kontami. W przypadku loginów SQL Server istotne są między innymi SID i skrót hasła zapisany w formacie przeznaczonym do użycia przez instrukcję tworzenia loginu. Dzięki zachowaniu SID można ograniczyć ryzyko powstania niedopasowania między loginem na poziomie serwera a użytkownikiem w bazie.

Eksport może obejmować również członkostwo loginów w stałych lub zdefiniowanych rolach serwerowych oraz uprawnienia przyznane na poziomie serwera, jeśli są obsługiwane przez polecenie i możliwe do odczytania z użyciem bieżącego konta. Nie należy jednak zakładać, że skrypt odtworzy użytkowników baz danych, ich członkostwo w rolach bazodanowych, uprawnienia obiektowe w każdej bazie, certyfikaty, klucze, poświadczenia, profile Database Mail albo konfigurację innych usług. Te elementy wymagają osobnych procedur i weryfikacji.

Weryfikacja skryptu przed wykonaniem na docelowej instancji

Wygenerowany plik należy traktować jako skrypt administracyjny, który trzeba przejrzeć przed uruchomieniem. Najpierw należy sprawdzić, czy wskazuje właściwe nazwy loginów, poprawną instancję oraz bazy domyślne istniejące na serwerze docelowym. Jeśli baza domyślna nie istnieje, utworzenie loginu może zakończyć się błędem albo wymagać późniejszej korekty ustawienia. Należy też uwzględnić różnice wersji SQL Server, dostępnych dostawców uwierzytelniania i uprawnień operatora.

Uruchomienie eksportu nie zmienia konfiguracji źródłowej instancji, ale wykonanie wygenerowanego skryptu już tak. Dlatego bezpieczna procedura obejmuje zachowanie kopii pliku, test na środowisku docelowym, sprawdzenie rezultatów w widokach katalogowych, takich jak sys.server_principals, sys.server_role_members i sys.server_permissions, oraz dopiero potem zastosowanie zmian produkcyjnych. Po migracji trzeba dodatkowo zweryfikować mapowanie użytkowników baz danych, ponieważ sam login serwera nie zastępuje użytkownika istniejącego wewnątrz konkretnej bazy.