Backup bazy master to kopia zapasowa systemowej bazy przechowującej konfigurację całej instancji SQL Server.
Znaczenie tej bazy dla działania całej instancji
Baza master jest systemową bazą danych programu Microsoft SQL Server. Przechowuje informacje potrzebne do uruchomienia instancji oraz do rozpoznania jej podstawowej konfiguracji. Znajdują się w niej między innymi metadane baz danych należących do instancji, informacje o plikach tych baz, ustawienia konfiguracji serwera oraz dane dotyczące części obiektów działających na poziomie całej instancji. Bez dostępnej i spójnej bazy master SQL Server może nie być w stanie prawidłowo wystartować albo odtworzyć listy baz użytkownika.
Backup bazy master nie jest kopią wszystkich danych przechowywanych na serwerze. Zawiera stan wyłącznie tej konkretnej bazy systemowej. Nie zastępuje kopii baz aplikacyjnych, bazy msdb, bazy model ani kopii dzienników transakcji baz użytkownika. Szczególne znaczenie ma fakt, że tempdb nie jest przeznaczana do wykonywania trwałych kopii zapasowych; jest odtwarzana przez SQL Server podczas uruchamiania usługi.
Co obejmuje kopia zapasowa master
Kopia master może zachować informacje o strukturze instancji, w tym o zarejestrowanych bazach danych i ich lokalizacji. Obejmuje również dane systemowe związane z konfiguracją instancji oraz serwerowymi podmiotami zabezpieczeń zapisanymi w bazie systemowej. Dotyczy to między innymi loginów SQL Server i innych informacji używanych przy uwierzytelnianiu na poziomie serwera, choć sama kopia nie zawiera haseł w postaci jawnego tekstu. Przy odtwarzaniu należy pamiętać, że prawidłowe działanie loginów zależy także od zgodności identyfikatorów zabezpieczeń z użytkownikami zapisanymi w bazach użytkownika.
Backup wykonany poleceniem BACKUP DATABASE master jest backupem pełnym tej bazy. Przykładowa instrukcja ma postać BACKUP DATABASE [master] TO DISK = N'D:\SQLBackups\master_full.bak' WITH INIT, CHECKSUM, STATS = 10;. Ścieżka musi wskazywać lokalizację dostępną dla usługi SQL Server, a konto tej usługi musi mieć odpowiednie uprawnienia do zapisu. Opcja CHECKSUM powoduje wykonanie dodatkowych kontroli sum kontrolnych podczas tworzenia kopii, natomiast STATS = 10 wyświetla postęp co dziesięć procent. Przed użyciem konkretnej ścieżki należy potwierdzić, że katalog istnieje i znajduje się na nośniku objętym planem ochrony.
Wykonywanie i sprawdzanie backupu systemowej bazy
Backup bazy master należy wykonywać po zmianach, które wpływają na konfigurację instancji lub obiekty przechowywane na poziomie serwera. Praktycznym przykładem jest utworzenie albo usunięcie loginu, zmiana istotnych ustawień instancji, dodanie bazy danych lub modyfikacja informacji potrzebnych do jej odnalezienia. Sama obecność pliku .bak nie dowodzi, że kopia nadaje się do odtworzenia. Należy przechowywać ją poza dyskiem, którego awaria mogłaby jednocześnie uszkodzić pliki baz i backup, oraz stosować kontrolę dostępu odpowiednią dla kopii zawierającej dane konfiguracyjne i bezpieczeństwa.
SQL Server udostępnia polecenie RESTORE VERIFYONLY do sprawdzenia, czy zestaw backupu jest kompletny i możliwy do odczytania przez mechanizm przywracania. Przykład: RESTORE VERIFYONLY FROM DISK = N'D:\SQLBackups\master_full.bak' WITH CHECKSUM;. Jest to kontrola techniczna pliku, a nie pełny test procedury awaryjnej. Wiarygodność planu potwierdza dopiero testowe odtworzenie na odizolowanej instancji lub przeprowadzenie kontrolowanej procedury na właściwym środowisku, z zachowaniem zgodności wersji SQL Server i lokalizacji plików.
Backup master powinien mieć jednoznaczną nazwę zawierającą nazwę bazy, typ kopii oraz datę i godzinę wykonania. Warto rejestrować wynik polecenia, rozmiar pliku, sumę kontrolną oraz miejsce przechowywania. Harmonogram kopii musi być powiązany z harmonogramem kopii pozostałych baz systemowych i użytkownika, ponieważ przywrócenie samego master nie odtworzy zadań SQL Server Agent, historii zadań ani konfiguracji przechowywanej w msdb.
Odtworzenie master po uszkodzeniu instancji
Przywracanie bazy master jest operacją administracyjną dotyczącą całej instancji, a nie zwykłym przywróceniem bazy aplikacyjnej. Jeżeli uszkodzenie uniemożliwia uruchomienie SQL Server, najpierw trzeba zapewnić dostęp do właściwego pliku backupu, ustalić wersję i konfigurację instancji oraz uruchomić usługę w trybie umożliwiającym przywrócenie bazy systemowej. W typowej procedurze instancję uruchamia się w trybie pojedynczego użytkownika, a następnie wykonuje polecenie przywracania z odpowiednio uprzywilejowanej sesji. Podczas tej czynności inne narzędzia, takie jak automatyczne monitory lub agenty, mogą próbować zająć jedyne dostępne połączenie.
Przykładowa instrukcja przywracania ma postać RESTORE DATABASE [master] FROM DISK = N'D:\SQLBackups\master_full.bak' WITH REPLACE, RECOVERY;, ale dokładne opcje zależą od procedury i środowiska. Po odtworzeniu SQL Server zwykle wymaga ponownego uruchomienia, a administrator powinien sprawdzić dostępność baz, loginów, konfiguracji oraz ścieżek plików. Jeżeli przyczyną awarii była utrata dysku, sama kopia master nie odtworzy fizycznych plików baz użytkownika; do tego potrzebne są osobne backupy tych baz.
Diagnostyka problemu z backupem obejmuje odczyt komunikatów SQL Server, sprawdzenie historii operacji tworzenia kopii, weryfikację uprawnień konta usługi oraz potwierdzenie, że plik nie został częściowo skopiowany lub zmieniony po wykonaniu backupu. Należy także zweryfikować, czy odtwarzany plik pochodzi z tej samej instancji i odpowiada wymaganej wersji silnika. Po zakończeniu procedury warto wykonać nową kopię master, ponieważ jej zawartość może różnić się od stanu sprzed awarii.
