Backup z T-SQL to alternatywne określenie wykonania kopii zapasowej za pomocą bezpośredniego polecenia w tym dialekcie SQL.
Backup z T-SQL w środowisku SQL Server
Backup z T-SQL oznacza utworzenie kopii zapasowej bazy danych Microsoft SQL Server za pomocą instrukcji języka Transact-SQL, najczęściej BACKUP DATABASE albo BACKUP LOG. Polecenie jest wykonywane przez aparat SQL Server i zapisuje dane do wskazanego urządzenia kopii zapasowej, którym może być plik dyskowy, urządzenie skonfigurowane w SQL Server lub inny obsługiwany cel zależny od wersji i konfiguracji środowiska. T-SQL pozwala opisać operację jednoznacznie w skrypcie, zautomatyzować ją oraz uruchamiać z harmonogramu zadań.
Podstawowa kopia pełna ma postać BACKUP DATABASE [NazwaBazy] TO DISK = N'C:\Backup\NazwaBazy_full.bak'. Instrukcja odczytuje dane należące do bazy i zapisuje ich kopię w pliku. Rozszerzenie .bak jest często stosowane jako konwencja nazewnicza, ale samo rozszerzenie nie decyduje o formacie ani poprawności kopii. SQL Server zapisuje w pliku między innymi informacje pozwalające później ustalić typ kopii, nazwę bazy, zakres danych i kolejność operacji potrzebną do odtworzenia.
Rodzaje kopii i zależność od modelu odzyskiwania
Instrukcja BACKUP DATABASE może utworzyć kopię pełną, różnicową albo kopię określonych plików i grup plików. Kopia różnicowa jest wykonywana z użyciem opcji WITH DIFFERENTIAL. Zawiera zmiany od ostatniej pełnej kopii bazowej, dlatego do jej odtworzenia potrzebna jest odpowiednia kopia pełna oraz sama kopia różnicowa. W przypadku dużych baz można stosować kopie plików, na przykład przez składnię BACKUP DATABASE ... FILE = N'NazwaPliku' lub FILEGROUP = N'NazwaGrupy', jeśli taki sposób organizacji danych został wcześniej zaplanowany.
Kopia dziennika transakcji jest tworzona poleceniem BACKUP LOG [NazwaBazy] TO DISK = N'C:\Backup\NazwaBazy_log.trn'. Nie zastępuje ona kopii pełnej. Pozwala zapisać operacje z dziennika transakcji od poprzedniej kopii dziennika i może być użyta do odtworzenia bazy do określonego momentu, pod warunkiem zachowania ciągłości łańcucha kopii dziennika. Kopie dziennika mają zastosowanie w modelach odzyskiwania FULL i BULK_LOGGED. W modelu SIMPLE regularne kopie dziennika transakcji nie są obsługiwane w taki sam sposób, ponieważ SQL Server samodzielnie zarządza obcinaniem niepotrzebnej części dziennika.
Opcja WITH COPY_ONLY tworzy kopię niezależną od zwykłej sekwencji kopii. Kopia pełna typu copy-only nie staje się podstawą dla późniejszych kopii różnicowych, a kopia dziennika typu copy-only nie zmienia standardowego punktu odniesienia dla kolejnych kopii dziennika. Jest to przydatne, gdy trzeba wykonać dodatkową kopię, na przykład przed operacją administracyjną, bez wpływania na przyjęty harmonogram i zależności odtwarzania.
Opcje bezpieczeństwa, spójności i odtwarzania
Skrypt T-SQL może zawierać opcje kontrolujące sposób wykonania i późniejszej weryfikacji kopii. WITH INIT powoduje zastąpienie istniejącego zestawu kopii na wskazanym nośniku, natomiast WITH NOINIT dopisuje nowy zestaw do istniejącego urządzenia. Przy użyciu pliku jako celu należy świadomie wybrać tę opcję, ponieważ przypadkowe zastąpienie pliku może usunąć wcześniej zapisane zestawy backupu. Opcja WITH FORMAT inicjalizuje nośnik i usuwa jego wcześniejszą strukturę kopii, dlatego wymaga szczególnej ostrożności.
Do kontroli integralności danych podczas tworzenia kopii można użyć WITH CHECKSUM. SQL Server oblicza sumy kontrolne dla stron odczytywanych podczas operacji i zapisuje informacje umożliwiające dodatkową kontrolę. Po wykonaniu kopii można użyć RESTORE VERIFYONLY FROM DISK = N'C:\Backup\NazwaBazy_full.bak', aby sprawdzić, czy zestaw kopii wydaje się kompletny i możliwy do odczytania przez mechanizm przywracania. RESTORE VERIFYONLY nie odtwarza bazy, nie sprawdza całej procedury przywracania na docelowej instancji i nie zastępuje testowego odtworzenia.
Pełny plan powinien uwzględniać także polecenia RESTORE DATABASE i RESTORE LOG. Przy odtwarzaniu wielu kopii dziennika każda kolejna kopia musi następować po poprzedniej bez przerwania łańcucha. Opcja WITH NORECOVERY pozostawia bazę w stanie oczekiwania na następny etap sekwencji, a WITH RECOVERY kończy proces i udostępnia bazę użytkownikom. Możliwe jest również odtworzenie do określonego czasu za pomocą opcji STOPAT, jeżeli zachowane kopie dziennika obejmują wymagany moment.
Weryfikacja skryptu backupu z T-SQL
Sam fakt poprawnego zakończenia instrukcji BACKUP nie dowodzi, że cały proces zapewnia możliwość odzyskania systemu. Należy sprawdzić, czy konto wykonujące skrypt ma uprawnienia do tworzenia kopii, czy ścieżka docelowa jest dostępna z perspektywy serwera SQL Server, czy na nośniku znajduje się wystarczająca ilość miejsca oraz czy nazwy plików nie powodują przypadkowego nadpisywania wcześniejszych zestawów. Ścieżka C:\Backup oznacza lokalizację na komputerze, na którym działa usługa SQL Server, a niekoniecznie na komputerze, z którego uruchomiono narzędzie administracyjne.
W praktycznym skrypcie warto zapisywać datę wykonania, typ kopii, nazwę bazy i wynik operacji w systemie monitorowania lub dzienniku zadań. Przydatne są także informacje zwracane przez SQL Server oraz widoki systemowe, między innymi msdb.dbo.backupset i msdb.dbo.backupmediafamily, które przechowują metadane wykonanych kopii. Ocena procedury powinna obejmować próbne odtworzenie na odseparowanej instancji, kontrolę kompletności zestawu pełnego, różnicowego i dzienników oraz sprawdzenie, czy odtworzona baza uruchamia się w oczekiwanym stanie.
Problemy z backupem z T-SQL mogą wynikać zarówno z błędnej składni, jak i z nieprawidłowego modelu odzyskiwania, braku uprawnień, niedostępnej ścieżki, uszkodzenia nośnika albo przerwanego łańcucha logów. Diagnostyka powinna dlatego obejmować komunikat błędu SQL Server, historię kopii, konfigurację bazy i rzeczywisty test odtwarzania. W przypadku typowych laptopów i komputerów PC Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów stacjonarnych oraz ich podzespołów.
