Podobnie jak w przypadku log shipping, transakcje w lustrzanych kopiach baz danych są przenoszone z serwera głównego (Principial Server) na serwer pomocniczy, nazywany tutaj serwerem lustrzanym (Mirror Server) z tą różnicą, że transakcje są zatwierdzanie w momencie, kiedy następują.
Na serwerze głównym znajduje się główna baza danych, gdzie przeprowadzane są transakcje. Serwer główny zapisuje zmiany w głównym dzienniku transakcji i automatycznie przenosi informacje na temat przeprowadzonych transakcji na serwer lustrzany, który dokonuje wpisu w swoim dzienniku transakcji. Następnie serwer lustrzany wysyła potwierdzenie do serwera głównego.
W ten sposób serwer lustrzany zawiera pełną kopię bazy danych ze wszystkimi wykonanymi transakcjami. Należy jednak pamiętać, że nie można tworzyć lustrzanych baz danych z baz systemowych.
W celu zapewnienia wysokiej dostępności możemy skonfigurować dodatkowy serwer zwany serwerem pomocniczym (Witness Server), który monitoruje serwery z główną i lustrzaną bazą danych.  W momencie, gdy następuje awaria i przestanie działać serwer główny, serwer nadzorujący wykonuje automatyczne przekierowanie i serwer lustrzany pełni funkcję serwera głównego. Aplikacje, które używają SNAC (SQL Native Client) lub .NET Data Provider są przełączane z serwera głównego na lustrzany transparentnie.

Jak skonfigurować lustrzaną bazę danych w SQL Management Studio?

W SQL Management Studio klikamy prawym przyciskiem myszy na bazie danych i w jej właściwościach przechodzimy do strony Mirroring. Najpierw musimy skonfigurować zabezpieczenia serwera głównego i lustrzanego, a przy wyborze opcji z serwerem nadzorującym – także i jego. W tym celu przyciskamy Configure Security.
Na pierwszej stronie kreatora określamy, czy chcemy używać serwera nadzorującego (Witness Server instance), który służy do automatycznego przywracania po awarii w trybie synchronicznym .

Na kolejnym ekranie Choose Servers to Configure możemy zaznaczyć, które instancje chcemy skonfigurować.

Na stronie Principal Server Instance określamy węzeł końcowy (Endpoint), poprzez który główny serwer będzie akceptował połączenia z serwera lustrzanego i serwera nadzorującego. W pozycji Listener port wpisujemy numer portu, którego chcemy używać. Należy pamiętać, że jeśli którykolwiek z instancji serwera: główny, lustrzany czy nadzorujący znajduje się na tym samym serwerze, numer portu musi się różnić.  Wpisujemy port i nadajemy węzłowi końcowemu nazwę oraz zaznaczamy czy chcemy szyfrować dane wysyłane przez ten endpoint (Enrypt data sent through this endpoint).

Na kolejnej stronie konfigurujemy instancję serwera lustrzanego. Z rozwijanej listy Mirror server instance wybieramy żądaną instancję i serwer oraz wciskamy przycisk Connect. Poniżej, podobnie jak na ekranie powyżej konfigurujemy port oraz nazwę węzła końcowego.

Jeśli wybraliśmy opcję z serwerem nadzorującym, wybieramy nazwę jego instancji w pozycji Witness server instance, wciskamy Connect i ponownie konfigurujemy numer portu i nazwę węzła.

Jeśli instancje używają różnych kont w zaufanej domenie jako kont usług SQL, należy je wpisać w pozycje Principal, Witness i Mirror. Jeśli wszystkie instancje używają tego samego konta, klikamy przycisk Next bez wpisywania czegokolwiek.

Na ostatniej stronie czytamy podsumowanie i wciskamy przycisk Finish.

Po zakończeniu zostanie stworzony mechanizm tworzenia lustrzanych baz danych.
Przed włączeniem mechanizmu, należy wykonać pełną kopię zapasową głównej bazy danych i odtworzyć ją na serwerze lustrzanym z opcją RESTORE WITH NORECOVERY. Lustrzana baza danych będzie znajdowała się teraz w stanie In Recovery.

Po odtworzeniu bazy danych powracamy do kreatora lustrzanych baz danych i przed wciśnięciem przycisku Start Mirroring wybieramy tryb w sekcji Operating Mode. Do wyboru mamy trzy tryby:

• Synchroniczny z automatycznym przywracaniem po awarii (Synchronous with automatic failover (high availability)), który gwarantuje wysoką dostępność. Do działania w tym trybie niezbędny jest uprzednio skonfigurowany serwer nadzorujący. Transakcja zostaje uważana za zakończoną na serwerze główny, gdy serwer lustrzany zapisze transakcję w swoim dzienniku i wyśle potwierdzenie do serwera głównego. Serwer nadzorujący kontroluje automatyczne przywrócenie po awarii na serwerze lustrzanym, gdy serwer główny jest niedostępny.
• Asynchroniczny (Asynchronous (high performance)) – Zmiany zostają zatwierdzone na serwerze głównym a następnie transferowane są na serwer lustrzany. W tym trybie, serwer główny zatwierdza transakcje bez oczekiwania na potwierdzenie od serwera lustrzanego. Nie działa tu automatyczne przywracanie po awarii. Jeśli główny serwer przestaje działać, należy ręcznie  przekazać jego działania serwerowi lustrzanemu. Tryb ten jest szybszy w działaniu niż tryb synchroniczny, niestety istnieje możliwość, że część transakcji nie zostanie zapisanych na serwerze lustrzanym.
• Synchroniczny (Synchronous (high protection)) zapewniający wysoką ochronę – Zatwierdzanie zmian odbywa się na obydwu serwerach. Nie zawiera serwera nadzorującego. Jeśli główny serwer przestaje działać, pełna kopia danych znajdująca się na serwerze lustrzanym zostaje ręcznie wypromowana do działania jako serwer główny. Jeśli natomiast serwer lustrzany przestaje działać, serwer główny przechodzi w tryb offline, a dane nie zostają utracone.

Ten sam process można wykonać poprzez zapytanie T-SQL:

CREATE ENDPOINT [Mirroring]
AS TCP (LISTENER_PORT = 5022)
FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = REQUIRED ALGORITHM RC4)
ALTER ENDPOINT [Mirroring] STATE = STARTED

CREATE ENDPOINT [Mirroring]
AS TCP (LISTENER_PORT = 5022)
FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = REQUIRED ALGORITHM RC4)
ALTER ENDPOINT [Mirroring] STATE = STARTED

CREATE ENDPOINT [Mirroring]
AS TCP (LISTENER_PORT = 5023)
FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM RC4)
ALTER ENDPOINT [Mirroring] STATE = STARTED

ALTER DATABASE [db] SET PARTNER = ‘TCP://serwer1.local:5022′
ALTER DATABASE [db] SET PARTNER = ‘TCP://serwer2.local :5022′
ALTER DATABASE [db] SET WITNESS = ‘TCP://witness.local:5023′