
Backup przy pomocy T-SQL to wykonanie kopii zapasowej za pomocą bezpośredniego polecenia w tym dialekcie języka SQL.
Na czym polega backup wykonany poleceniem T-SQL
Backup przy pomocy T-SQL oznacza utworzenie kopii zapasowej bazy danych za pomocą instrukcji języka Transact-SQL, używanego przez Microsoft SQL Server. Najczęściej stosuje się polecenie BACKUP DATABASE, które zapisuje kopię całej bazy do wskazanego urządzenia docelowego, na przykład pliku dyskowego. Przykładowa instrukcja ma postać BACKUP DATABASE [BazaFirmowa] TO DISK = N'D:\Backup\BazaFirmowa_full.bak' WITH INIT, COMPRESSION, CHECKSUM;. Nazwa bazy, ścieżka oraz opcje muszą odpowiadać rzeczywistej konfiguracji instancji SQL Server.
Wykonanie kopii zapasowej nie jest tym samym co skopiowanie pliku bazy danych .mdf lub .ndf. SQL Server korzysta z własnego formatu backupu, zawierającego między innymi informacje o stronach danych, metadane kopii oraz elementy potrzebne do późniejszego odtworzenia. Plik kopii powinien być zapisywany w miejscu, do którego konto usługi SQL Server ma uprawnienia zapisu. Ścieżka widoczna z perspektywy administratora może nie być dostępna dla samej usługi, szczególnie gdy wskazuje lokalny dysk, udział sieciowy albo katalog o ograniczonych prawach dostępu.
Rodzaje kopii dostępne w SQL Server
Instrukcja T-SQL pozwala wykonywać kilka rodzajów kopii zapasowych. Pełna kopia bazy, tworzona przez BACKUP DATABASE bez opcji DIFFERENTIAL, obejmuje dane potrzebne do odtworzenia stanu bazy z momentu rozpoczęcia operacji, z uwzględnieniem mechanizmów spójności SQL Server. Kopia różnicowa jest wykonywana również poleceniem BACKUP DATABASE, ale z opcją WITH DIFFERENTIAL. Zawiera zmiany od ostatniej pełnej kopii zapasowej, a nie od poprzedniej kopii różnicowej.
W modelu odzyskiwania FULL albo BULK_LOGGED można dodatkowo wykonywać kopie dziennika transakcji instrukcją BACKUP LOG. Przykład to BACKUP LOG [BazaFirmowa] TO DISK = N'D:\Backup\BazaFirmowa_log.trn' WITH COMPRESSION, CHECKSUM;. Kopie dziennika tworzą łańcuch logów, który może umożliwić odtworzenie bazy do określonego punktu w czasie. Warunkiem jest zachowanie wymaganej kolejności kopii oraz niewykonanie operacji, która przerwałaby łańcuch. W modelu SIMPLE kopie dziennika transakcji nie są używane do standardowego odtwarzania punkt-w-czasie.
Opcja COMPRESSION zmniejsza rozmiar pliku kopii kosztem dodatkowego użycia procesora podczas tworzenia i odtwarzania backupu. Opcja CHECKSUM powoduje obliczanie sum kontrolnych podczas operacji i może pomóc wykryć uszkodzenia odczytywanych stron lub danych zapisywanych w kopii. Nie zastępuje ona jednak pełnego testu odtworzenia. Jedna kopia może być zapisana do kilku urządzeń backupu, a podział strumienia na wiele plików może skrócić operację, gdy urządzenia docelowe zapewniają równoległy zapis.
Spójność, historia i odtwarzanie kopii
Po wykonaniu backupu warto sprawdzić jego strukturę poleceniem RESTORE VERIFYONLY, na przykład RESTORE VERIFYONLY FROM DISK = N'D:\Backup\BazaFirmowa_full.bak';. Taka kontrola może potwierdzić, że SQL Server odczytuje nagłówki i strukturę kopii. Nie daje jednak pełnej gwarancji, że cała procedura odtworzenia zakończy się powodzeniem. Rzeczywista weryfikacja wymaga odtworzenia kopii do środowiska testowego, sprawdzenia kolejności plików oraz wykonania kontroli integralności odtworzonej bazy.
Informacje o wykonanych kopiach SQL Server zapisuje w bazie msdb. Do analizy historii można wykorzystać widoki backupset i backupmediafamily, które zawierają między innymi typ kopii, czas rozpoczęcia i zakończenia, rozmiar oraz informacje o urządzeniu backupu. Przykładowe zapytanie pozwalające znaleźć ostatnie kopie bazy może odwoływać się do tabeli msdb.dbo.backupset i filtrować rekordy według database_name oraz type. Historia w msdb nie powinna być traktowana jako jedyna kopia zapasowa tej historii, ponieważ utrata lub wyczyszczenie bazy systemowej może usunąć dane ewidencyjne.
Odtwarzanie pełnej kopii wykonuje się poleceniem RESTORE DATABASE. Jeżeli po pełnym backupie dostępne są kopie różnicowe lub dziennika, należy zachować właściwą sekwencję: najpierw odtworzyć pełną kopię z opcją NORECOVERY, następnie właściwą kopię różnicową, a potem kolejne kopie logu. Ostatnia operacja jest kończona zwykle opcją RECOVERY, która udostępnia bazę użytkownikom. Przy odtwarzaniu na inną instancję konieczne może być użycie WITH MOVE, aby wskazać nowe lokalizacje plików danych i dziennika.
Najczęstsze problemy przy poleceniach BACKUP
Błąd podczas backupu może wynikać z braku uprawnień do katalogu, niewystarczającej ilości wolnego miejsca, zajętego lub niedostępnego udziału sieciowego albo błędnej ścieżki. SQL Server interpretuje ścieżkę po stronie serwera, dlatego zapis C:\Backup\plik.bak oznacza katalog na komputerze, na którym działa instancja, a niekoniecznie na komputerze z uruchomionym narzędziem SQL Server Management Studio. Przy lokalizacji sieciowej należy używać ścieżki UNC, na przykład \\serwer-backupu\sql\Baza.bak, oraz zapewnić odpowiednie uprawnienia kontu usługi.
Niepoprawne planowanie kopii może również prowadzić do pozornego bezpieczeństwa. Sam backup pełny nie zapewnia odzyskania zmian wykonanych po jego utworzeniu, a kopia różnicowa wymaga dostępnej ostatniej pełnej kopii bazowej. Kopie dziennika muszą być wykonywane regularnie i przechowywane bez przerw w łańcuchu. Opcja WITH INIT nadpisuje istniejący zestaw backupu na wskazanym nośniku, dlatego jej użycie powinno być świadome. W wielu sytuacjach bezpieczniejsze jest użycie nowego pliku albo WITH FORMAT tylko wtedy, gdy administrator rozumie skutki utworzenia nowego nagłówka nośnika.
Przy diagnostyce problemu należy rozdzielić trzy kwestie: czy instrukcja T-SQL jest poprawna, czy SQL Server może odczytać dane i zapisać plik oraz czy utworzona kopia rzeczywiście nadaje się do odtworzenia. Sprawdza się komunikaty z historii zadań i dziennika SQL Server, status miejsca na dysku, uprawnienia konta usługi, model odzyskiwania bazy oraz ciągłość kopii dziennika. Dopiero po tych kontrolach można ocenić, czy problem dotyczy samego polecenia BACKUP, konfiguracji środowiska, przechowywania plików czy późniejszego procesu RESTORE.