Serwisanci dostępni teraz · czynne całą dobę, także w weekendy i świętaWarszawa i okolice · dojazd bezpłatny
Darmowa diagnoza laptopa

Darmowa diagnoza laptopa

Dojazd do klienta bezpłatnie

Dojazd do klienta bezpłatnie

Laptopy zastępcze bezpłatnie

Laptopy zastępcze bezpłatnie

Odbiór i zwrot sprzętu bezpłatnie

Odbiór i zwrot sprzętu bezpłatnie

Backup bazy systemowej

Termin Definicja
Backup bazy systemowej
Backup bazy systemowej

Backup bazy systemowej to zbiorcze określenie kopii zapasowych wewnętrznych baz wymaganych do działania instancji SQL Server.

Zakres pojęcia backupu baz systemowych w SQL Server

Backup bazy systemowej w Microsoft SQL Server oznacza wykonanie kopii zapasowej jednej z wewnętrznych baz danych używanych przez instancję. Najczęściej chodzi o master, model oraz msdb. Baza master przechowuje między innymi informacje o konfiguracji instancji, zarejestrowanych bazach użytkownika, kontach logowania oraz ustawieniach systemowych. Utrata tej bazy może uniemożliwić prawidłowe uruchomienie instancji albo spowodować utratę informacji potrzebnych do odnalezienia pozostałych baz.

Baza model jest szablonem używanym podczas tworzenia nowych baz danych. Znajdują się w niej ustawienia, obiekty i właściwości kopiowane do nowo tworzonych baz, dlatego jej backup może być potrzebny do odtworzenia ustalonego stanu konfiguracji. Baza msdb przechowuje dane wykorzystywane przez SQL Server Agent, historię zadań, harmonogramy, informacje o planach konserwacji oraz część metadanych związanych z backupami. Zakres kopii systemowych baz powinien wynikać z konfiguracji konkretnej instancji, a nie z samej nazwy pliku backupu.

Bazy systemowe objęte kopią oraz wyjątek tempdb

Do baz systemowych, dla których wykonuje się standardowe kopie zapasowe, należą przede wszystkim master, model i msdb. Baza tempdb nie jest przeznaczona do backupu ani odtwarzania. SQL Server tworzy ją ponownie podczas uruchamiania instancji, a przechowywane w niej dane tymczasowe nie są traktowane jako trwały stan wymagający odzyskiwania. Próba budowania procedury awaryjnej na kopii tempdb byłaby więc błędnym założeniem.

Backup bazy systemowej nie zastępuje kopii baz użytkownika. Odtworzenie master, msdb lub model przywraca stan odpowiedniej bazy, ale nie odtwarza danych aplikacyjnych przechowywanych w innych bazach. Trzeba również rozróżnić kopię samej bazy od kopii elementów kryptograficznych. Jeżeli instancja korzysta z klucza głównego usługi, certyfikatów lub kluczy szyfrujących, ich zabezpieczenie może wymagać osobnych operacji administracyjnych, takich jak eksport klucza głównego usługi. Nie należy zakładać, że każdy taki element można odzyskać wyłącznie z dowolnej kopii bazy.

Wykonanie backupu i kontrola jego użyteczności

Pełną kopię bazy można wykonać poleceniem BACKUP DATABASE. Przykładowa składnia dla bazy msdb wygląda następująco:

BACKUP DATABASE [msdb] TO DISK = N'D:\SQLBackup\msdb_full.bak' WITH INIT, CHECKSUM, STATS = 10;

W praktycznej procedurze należy wskazać rzeczywistą lokalizację dostępną dla usługi SQL Server, zapewnić odpowiednie uprawnienia i nie nadpisywać starszej kopii bez świadomej polityki retencji. Opcja CHECKSUM pozwala wykonywać dodatkowe kontrole sum kontrolnych podczas operacji, ale nie potwierdza, że backup da się skutecznie odtworzyć. Po wykonaniu kopii można użyć RESTORE VERIFYONLY, jednak wiarygodnym sprawdzianem pozostaje testowe odtworzenie na odseparowanej instancji.

Można odczytać podstawowe informacje o kopiach z widoku msdb.dbo.backupset, między innymi nazwę bazy, typ backupu, czas rozpoczęcia i zakończenia oraz identyfikator nośnika. Warto kontrolować spójność pliku, możliwość jego odczytu i zgodność kopii z planem odtwarzania. Sam fakt, że zadanie SQL Server Agent zakończyło się komunikatem sukcesu, nie wystarcza, jeśli plik został zapisany w lokalizacji niedostępnej po awarii hosta albo został później usunięty. Kopia powinna być także objęta procedurą przechowywania kolejnych wersji, aby pojedyncze uszkodzenie lub błędne nadpisanie nie usunęło jedynego punktu odzyskiwania.

Odtwarzanie po awarii instancji SQL Server

Odtworzenie baz systemowych wymaga uwzględnienia kolejności i trybu pracy instancji. Bazę master przywraca się w szczególnym trybie, ponieważ zawiera informacje niezbędne do działania serwera. W typowym scenariuszu instancję uruchamia się z minimalnym zestawem konfiguracji, zatrzymuje zwykłą pracę usług zależnych, a następnie wykonuje przywrócenie odpowiedniej kopii. Po odtworzeniu master instancję uruchamia się ponownie i sprawdza, czy widoczne są bazy użytkownika, logowania oraz ustawienia wymagane przez aplikacje.

Przywrócenie msdb może odtworzyć zadania SQL Server Agent, harmonogramy i historię operacji, natomiast odtworzenie model wpływa na sposób tworzenia nowych baz w przyszłości. Procedura powinna uwzględniać wersję SQL Server, ścieżki plików, konta usług i zależności między bazami. Po zakończeniu należy zweryfikować uruchamianie agenta, dostępność zadań, poprawność konfiguracji backupów oraz możliwość wykonania kontrolnego połączenia. Dobrze przygotowany backup bazy systemowej jest więc nie tylko plikiem .bak, lecz elementem sprawdzonego planu odtworzenia konkretnej instancji SQL Server.

+48 22 100 48 29Zadzwoń teraz · serwisant w 1 godzinę