Dokumentacja Microsoft dotycząca BACKUP DATABASE opisuje składnię i opcje polecenia tworzącego kopię zapasową bazy danych.
Rola instrukcji BACKUP DATABASE w SQL Server
BACKUP DATABASE jest instrukcją języka Transact-SQL używaną w Microsoft SQL Server do utworzenia kopii zapasowej bazy danych. Kopia może zostać zapisana na urządzeniu dyskowym albo na innym obsługiwanym nośniku wskazanym w klauzuli TO DISK lub TO URL. Podstawowa postać polecenia wygląda następująco: BACKUP DATABASE nazwa_bazy TO DISK = 'ścieżka_do_pliku.bak';. Nazwa bazy może być podana bezpośrednio albo zastąpiona zmienną, co pozwala budować skrypty wykonujące kopie dla wielu baz.
Instrukcja nie służy wyłącznie do prostego skopiowania plików bazy. SQL Server zapisuje w kopii informacje potrzebne do odtworzenia struktury i zawartości bazy w określonym momencie. Kopia zawiera także metadane backupu, między innymi typ kopii, identyfikator bazy, czas rozpoczęcia i zakończenia operacji oraz informacje o kolejności kopii w łańcuchu przywracania. Dzięki temu narzędzia administracyjne mogą zweryfikować, czy wybrany zestaw backupów tworzy logiczną sekwencję.
Typ kopii a model odzyskiwania bazy
Najczęściej wykonywana kopia pełna obejmuje całą bazę danych wraz z wystarczającą częścią dziennika transakcji, aby zachować spójność kopii. Do jej utworzenia używa się polecenia BACKUP DATABASE bez klauzuli WITH DIFFERENTIAL. Kopia różnicowa również jest kopią bazy, ale zawiera zmiany wykonane od ostatniej pełnej kopii bazowej. Wykonuje się ją przez dodanie WITH DIFFERENTIAL. Przy odtwarzaniu kopii różnicowej potrzebna jest odpowiadająca jej kopia pełna, ponieważ backup różnicowy nie jest samodzielnym zamiennikiem pełnego backupu.
Model odzyskiwania wpływa na dostępne scenariusze zabezpieczania dziennika transakcji. W modelu FULL oraz BULK_LOGGED można wykonywać kopie dziennika za pomocą instrukcji BACKUP LOG, zachowując ciągłość łańcucha logów. Model SIMPLE nie obsługuje kopii dziennika transakcji, ponieważ SQL Server automatycznie ponownie wykorzystuje jego wolne fragmenty. Sama kopia pełna nie skraca automatycznie dziennika transakcji i nie zastępuje planu wykonywania backupów logu, gdy wymagane jest odtwarzanie do określonego momentu.
Opcje zapisu, kontroli i zabezpieczenia backupu
Klauzula WITH pozwala dopasować sposób tworzenia kopii do wymagań środowiska. COMPRESSION zmniejsza ilość zapisywanych danych, ale może zwiększyć zużycie procesora podczas tworzenia i odtwarzania kopii. CHECKSUM powoduje obliczanie sum kontrolnych dla stron danych przetwarzanych w czasie operacji, co pomaga wykrywać uszkodzenia napotkane podczas backupu. Opcja STATS określa częstotliwość wyświetlania informacji o postępie, na przykład STATS = 10 raportuje postęp co dziesięć procent.
Backup może być zapisany do nowego pliku albo do istniejącego zestawu backupów. Opcja INIT zastępuje zawartość nośnika, natomiast NOINIT dopisuje nowy zestaw do istniejącego nośnika, o ile pozostałe warunki operacji na to pozwalają. Przy nadpisywaniu trzeba świadomie sprawdzić, czy wskazany plik nie zawiera jedynej dostępnej kopii. FORMAT tworzy nowy nagłówek nośnika i usuwa informacje o wcześniejszych zestawach, dlatego wymaga szczególnej ostrożności.
SQL Server umożliwia także szyfrowanie kopii podczas tworzenia. W tym celu stosuje się klauzulę ENCRYPTION z algorytmem oraz certyfikatem lub kluczem asymetrycznym skonfigurowanym w bazie master. Do odtworzenia zaszyfrowanej kopii potrzebny jest ten sam materiał kryptograficzny, dlatego certyfikat lub klucz trzeba zabezpieczyć niezależnie od pliku backupu. Utrata certyfikatu może uniemożliwić przywrócenie kopii, nawet jeśli sam plik .bak pozostał nieuszkodzony.
Weryfikacja kopii i przygotowanie odtwarzania
Utworzenie pliku backupu nie dowodzi jeszcze, że cała procedura odzyskiwania zakończy się powodzeniem. Do podstawowej kontroli można użyć RESTORE VERIFYONLY, które sprawdza, czy zestaw backupów jest kompletny i możliwy do odczytania przez SQL Server. Polecenie nie odtwarza jednak bazy i nie zastępuje próbnego przywrócenia na oddzielnej instancji. W praktyce należy również sprawdzić, czy można odczytać nagłówki przez RESTORE HEADERONLY oraz listę plików bazy przez RESTORE FILELISTONLY.
Plan odtwarzania zależy od rodzaju wykonanych kopii. Dla typowego scenariusza potrzebna jest ostatnia pełna kopia, opcjonalnie najnowsza kopia różnicowa oraz wszystkie wymagane kopie dziennika transakcji w prawidłowej kolejności. Przywracanie rozpoczyna się z opcją NORECOVERY, jeżeli po danej kopii mają zostać zastosowane kolejne backupy. Opcja RECOVERY kończy sekwencję i udostępnia bazę użytkownikom, dlatego użycie jej zbyt wcześnie uniemożliwia zastosowanie następnych kopii z tej samej ścieżki odzyskiwania.
Podczas diagnostyki problemów z backupem sprawdza się między innymi uprawnienia konta usługi SQL Server do katalogu docelowego, dostępność wolnego miejsca, poprawność ścieżki, stan nośnika oraz komunikaty zapisane w dzienniku SQL Server. Warto odróżnić zwykłą kopię od kopii typu COPY_ONLY. Backup typu copy-only jest przeznaczony do jednorazowych lub pomocniczych operacji i nie zmienia normalnej podstawy dla kopii różnicowych; może być przydatny podczas testów albo wykonywania dodatkowej kopii poza stałym harmonogramem. Odtwarzanie powinno być okresowo testowane na środowisku odseparowanym od produkcyjnej bazy.
