Backup typu COPY_ONLY

Backup typu COPY_ONLY to kopia zapasowa niewpływająca na sekwencję standardowych kopii pełnych i różnicowych bazy danych.

Rola opcji COPY_ONLY w SQL Server

Backup typu COPY_ONLY jest specjalnym rodzajem kopii zapasowej dostępnej w Microsoft SQL Server. Jego cechą nie jest odmienny format pliku ani inny sposób przechowywania stron danych, lecz niezależność od zwykłego harmonogramu wykonywania kopii. Utworzenie takiej kopii nie zmienia punktu odniesienia używanego później przez standardowe kopie różnicowe. Dzięki temu można wykonać dodatkową pełną kopię bazy danych bez wpływania na przyjęty łańcuch backupów.

Typowym zastosowaniem jest jednorazowe przygotowanie kopii do testów, migracji, analizy albo przekazania innemu zespołowi. Jeżeli regularnie wykonywana jest pełna kopia bazy, a następnie kopie różnicowe, dodatkowy backup COPY_ONLY może powstać pomiędzy nimi bez powodowania, że następna kopia różnicowa zacznie odnosić się do tej dodatkowej kopii. Jest to istotne, ponieważ zwykła pełna kopia wyznacza nową bazę dla przyszłych backupów różnicowych.

Wpływ na pełne i różnicowe kopie bazy

W SQL Server pełna kopia zapasowa zawiera dane potrzebne do odtworzenia stanu bazy z określonego momentu. Kopia różnicowa przechowuje zmiany wykonane od tak zwanej differential base, czyli ostatniej pełnej kopii będącej podstawą dla danego ciągu backupów różnicowych. Zwykły backup pełny aktualizuje tę podstawę. Pełny backup wykonany z opcją COPY_ONLY może zostać odtworzony jak standardowa kopia pełna, ale nie staje się nową podstawą dla późniejszych kopii różnicowych.

Przykładowo, jeżeli regularny harmonogram obejmuje pełną kopię w poniedziałek i kopie różnicowe od wtorku do piątku, dodatkowy backup COPY_ONLY wykonany w środę nie zmienia relacji pozostałych kopii różnicowych do poniedziałkowej kopii pełnej. Przy odtwarzaniu regularnego zestawu nadal można wykorzystać poniedziałkowy backup jako bazę oraz właściwą kopię różnicową. Dodatkowa kopia COPY_ONLY pozostaje osobnym punktem odtwarzania i nie należy automatycznie zakładać, że zastąpi ona całą zaplanowaną sekwencję.

Opcja ta nie rozwiązuje problemów z miejscem na dysku, uszkodzeniem pliku backupu ani nieprawidłowo zaplanowanym procesem odtwarzania. Nadal trzeba sprawdzić, czy kopia zakończyła się poprawnie, czy plik jest kompletny oraz czy można go odczytać podczas testowego przywracania. Sam fakt użycia słowa COPY_ONLY w poleceniu nie potwierdza poprawności całej procedury ochrony danych.

COPY_ONLY a kopie dziennika transakcji

W SQL Server opcja COPY_ONLY może być używana także przy wykonywaniu kopii dziennika transakcji. Taki backup logu jest niezależnym przechwyceniem zawartości dziennika i nie zmienia zwykłej sekwencji kopii dziennika wykonywanych przez regularny harmonogram. Jest to przydatne, gdy trzeba pobrać dodatkową kopię logu przed operacją administracyjną albo przed rozpoczęciem prac diagnostycznych, a jednocześnie nie powinno się zmieniać zachowania istniejącego procesu tworzenia backupów.

Backup COPY_ONLY dziennika transakcji nie zastępuje pełnej kopii bazy i nie tworzy samodzielnie kompletnego zestawu potrzebnego do odtworzenia bazy. Przy przywracaniu należy zachować właściwą kolejność: najpierw odtworzyć odpowiednią pełną kopię, następnie ewentualną kopię różnicową, a potem kolejne kopie dziennika transakcji zgodnie z ich zakresem LSN, czyli numerami identyfikującymi położenie operacji w dzienniku. Niezgodność kolejności albo brak fragmentu dziennika może uniemożliwić kontynuowanie przywracania.

Warto odróżnić wpływ COPY_ONLY od mechanizmu truncation logu. Wykonanie kopii dziennika jest związane z normalnym zarządzaniem dziennikiem w bazie działającej w modelu odzyskiwania full albo bulk-logged, ale opcja COPY_ONLY służy przede wszystkim zachowaniu niezależności od regularnego łańcucha backupów. O tym, czy miejsce w pliku dziennika zostanie ponownie wykorzystane, decydują również aktywne transakcje, opóźnione operacje oraz inne warunki modelu odzyskiwania.

Weryfikacja pliku i plan odtwarzania

Po utworzeniu backupu COPY_ONLY należy zweryfikować zarówno wynik operacji, jak i sposób późniejszego użycia kopii. Przydatne jest sprawdzenie metadanych backupu w SQL Server, w tym czasu wykonania, typu kopii, nazwy bazy, zakresu dziennika oraz informacji o urządzeniu docelowym. W praktyce należy również kontrolować komunikaty zwrócone przez polecenie BACKUP DATABASE albo BACKUP LOG, ponieważ poprawne utworzenie pliku wymaga nie tylko wskazania opcji COPY_ONLY, ale także dostępnego miejsca, prawidłowych uprawnień i sprawnego nośnika.

Przy planowaniu odtworzenia trzeba ustalić, czy backup COPY_ONLY ma być użyty jako samodzielna pełna kopia, czy jako element większego zestawu. Pełną kopię COPY_ONLY można wykorzystać jako punkt początkowy odtwarzania, ale dalsze kopie dziennika muszą obejmować właściwy zakres zmian po wykonaniu tej kopii. Jeżeli celem jest odtworzenie regularnego harmonogramu, należy posługiwać się informacjami o bazie różnicowej i kolejności backupów, a nie wyłącznie nazwami plików.

Diagnostyka problemu z backupem powinna obejmować także próbę odczytu kopii oraz kontrolowane odtworzenie na odseparowanym środowisku. Należy sprawdzić, czy plik nie został przerwany, skopiowany tylko częściowo albo uszkodzony podczas przesyłania. W środowisku laptopa lub komputera PC SQL Server może występować jako lokalny silnik wykorzystywany przez aplikację, dlatego błędna konfiguracja ścieżki, brak uprawnień konta usługi lub niewystarczająca przestrzeń dyskowa mogą ujawnić się jako problemy z wykonaniem kopii, mimo że sama składnia COPY_ONLY jest prawidłowa.