Backup z SSMS

Backup z SSMS to skrótowe określenie wykonania kopii zapasowej za pomocą tego narzędzia zarządzania bazami danych.

Backup z SSMS jako kopia bazy SQL Server

Backup z SSMS oznacza wykonanie kopii zapasowej bazy danych Microsoft SQL Server za pomocą programu SQL Server Management Studio. SSMS jest graficznym narzędziem administracyjnym, które pozwala połączyć się z konkretną instancją SQL Server, wybrać bazę danych i uruchomić polecenie tworzenia kopii. Sama kopia nie jest przechowywana w programie SSMS. Jest zapisywana do wskazanego pliku, zwykle z rozszerzeniem .bak, na dysku dostępnym dla usługi SQL Server.

Ważne jest rozróżnienie między komputerem, na którym działa SSMS, a serwerem, na którym działa silnik SQL Server. Operacja backupu jest wykonywana przez silnik bazy danych, dlatego ścieżka pliku musi być dostępna z perspektywy serwera SQL Server. Jeżeli w oknie konfiguracji zostanie podana lokalizacja istniejąca wyłącznie na komputerze administratora, SQL Server może zgłosić błąd dostępu do pliku. Uprawnienia do zapisu w wybranym katalogu musi posiadać konto, pod którym działa usługa SQL Server.

Rodzaje kopii dostępne w SQL Server

SQL Server obsługuje kilka rodzajów kopii zapasowych. Pełna kopia bazy danych obejmuje dane potrzebne do odtworzenia całej bazy w określonym momencie. Kopia różnicowa zawiera zmiany wykonane od czasu ostatniej pełnej kopii. Jej odtworzenie wymaga najpierw użycia odpowiedniej pełnej kopii, a następnie najnowszej kopii różnicowej. W bazach działających w modelu odzyskiwania Full lub Bulk-logged można dodatkowo wykonywać kopie dziennika transakcji, które obejmują zapisane operacje dziennika od poprzedniej kopii tego typu.

W SSMS rodzaj kopii wybiera się w oknie Back Up Database, dostępnym po użyciu polecenia Tasks i Back Up dla wybranej bazy. W polu typu kopii można wskazać między innymi Full, Differential albo Transaction Log, o ile konfiguracja bazy pozwala na wykonanie danego rodzaju backupu. Przy kopii dziennika transakcji istotny jest model odzyskiwania. Model Simple nie zachowuje dziennika w sposób umożliwiający regularne wykonywanie kopii logu transakcji, dlatego plan odtwarzania trzeba dopasować do ustawień konkretnej bazy.

Plik backupu, nośnik i weryfikacja odtwarzania

Podczas tworzenia backupu SQL Server zapisuje w pliku informacje potrzebne do późniejszego odtworzenia bazy, w tym dane, metadane oraz elementy struktury kopii. Jedna kopia może zostać zapisana na jednym lub kilku nośnikach backupu. W typowym zastosowaniu SSMS wskazuje się plik jako miejsce docelowe i można dodać nowy plik albo zastąpić istniejący zestaw backupu. Opcja dołączania kopii do istniejącego nośnika oraz opcja nadpisania mają inne skutki, dlatego należy sprawdzić ustawienie przed uruchomieniem operacji.

Po zakończeniu backupu warto użyć polecenia weryfikacji, ale sam pomyślny komunikat nie potwierdza jeszcze, że cała procedura odtwarzania jest poprawna. Techniczna kontrola może obejmować polecenie RESTORE VERIFYONLY, które sprawdza, czy zestaw backupu wydaje się kompletny i możliwy do odczytania przez SQL Server. Pełniejszym testem jest odtworzenie kopii do osobnej bazy przy użyciu RESTORE DATABASE, a następnie sprawdzenie, czy baza uruchamia się i zawiera oczekiwane dane. Należy także kontrolować rozmiar pliku, datę utworzenia oraz komunikaty z historii backupów zapisanej w systemowych widokach i tabelach historii SQL Server.

Odtwarzanie bazy po wykonaniu kopii w SSMS

Backup ma wartość dopiero wtedy, gdy można go wykorzystać w procedurze restore. W SSMS odtwarzanie rozpoczyna się od wyboru polecenia Restore Database i wskazania źródła kopii. Przy odtwarzaniu pełnej kopii SQL Server może przywrócić bazę do stanu z momentu zakończenia backupu. Jeżeli używany jest łańcuch kopii różnicowych lub dziennika transakcji, trzeba zachować właściwą kolejność: pełna kopia, odpowiednia kopia różnicowa oraz kolejne kopie logu bez przerwania łańcucha.

Podczas przywracania na inną instancję mogą być potrzebne dodatkowe ustawienia ścieżek plików danych i dziennika, ponieważ pierwotne lokalizacje nie zawsze istnieją na komputerze docelowym. W takim przypadku w SSMS można przejść do zakładki Files i wskazać nowe lokalizacje plików, a także użyć opcji WITH MOVE w poleceniu T-SQL. Przed odtworzeniem działającej bazy trzeba również uwzględnić istniejące połączenia, stan bazy oraz możliwość nadpisania aktualnych danych. Błędnie dobrany backup, niepełny łańcuch logów albo brak uprawnień do pliku może uniemożliwić odzyskanie oczekiwanego stanu SQL Server.