RESTORE HEADERONLY odczytuje nagłówek kopii zapasowej, ujawniając jej datę i typ bez uruchamiania przywracania.
RESTORE HEADERONLY jako odczyt metadanych kopii zapasowej
RESTORE HEADERONLY jest instrukcją języka Transact-SQL dostępnego w Microsoft SQL Server. Służy do odczytania informacji zapisanych w nagłówku kopii zapasowej znajdującej się w urządzeniu backupu, najczęściej w pliku z rozszerzeniem .bak. Polecenie analizuje strukturę kopii, ale nie odtwarza bazy danych, nie tworzy jej na serwerze i nie zmienia zawartości istniejących baz. Dzięki temu można sprawdzić podstawowe właściwości pliku przed uruchomieniem właściwego procesu przywracania.
Typowa składnia ma postać RESTORE HEADERONLY FROM DISK = N'C:\Backup\baza.bak';. W środowisku SQL Server ścieżka jest interpretowana przez usługę silnika bazy danych, a nie przez komputer, z którego wysłano polecenie. Oznacza to, że plik musi być dostępny dla serwera SQL Server, a konto usługi musi mieć odpowiednie uprawnienia do jego odczytu. Przy użyciu udziału sieciowego należy podać ścieżkę UNC, na przykład \\serwer\backup\baza.bak, z uwzględnieniem uprawnień systemu Windows.
Jakie informacje zwraca polecenie
Wynikiem działania instrukcji jest zestaw kolumn opisujących kopię zapasową. Można w nim znaleźć między innymi nazwę bazy źródłowej, nazwę serwera, identyfikator kopii, typ kopii, datę rozpoczęcia i zakończenia tworzenia backupu oraz numer pozycji zestawu backupu. Polecenie zwraca również informacje o oprogramowaniu, które utworzyło kopię, wersji tego oprogramowania, rozmiarze danych i użytym typie nośnika. Konkretna lista oraz format kolumn zależą od wersji Microsoft SQL Server.
Jednym z istotnych pól jest BackupType, wskazujące rodzaj kopii. Wartości tego pola pozwalają odróżnić między innymi pełną kopię bazy danych, kopię różnicową, kopię dziennika transakcji, kopię plikową oraz inne typy obsługiwane przez SQL Server. Ważne są także FirstLSN, LastLSN i CheckpointLSN, ponieważ odnoszą się do numerów sekwencji dziennika transakcji. Same daty zapisane w nagłówku nie wystarczają do oceny, czy zestaw kopii dziennika można zastosować w konkretnej sekwencji odtwarzania.
Weryfikacja pliku przed odtwarzaniem bazy
RESTORE HEADERONLY jest przydatne podczas wstępnej kontroli pliku otrzymanego z innego środowiska, po przeniesieniu backupu na nowy dysk albo przy porządkowaniu wielu kopii o podobnych nazwach. Odczyt nagłówka pozwala ustalić, czy plik rzeczywiście zawiera kopię oczekiwanej bazy, kiedy została utworzona oraz czy znajduje się w nim właściwy zestaw backupu. Jeżeli plik zawiera więcej niż jeden zestaw, wynik może obejmować kilka wierszy, a wtedy do dalszych operacji wykorzystuje się odpowiedni numer Position.
Odczyt nagłówka nie jest pełnym testem poprawności kopii. Pozytywny wynik oznacza, że SQL Server potrafił odczytać strukturę nagłówka, ale nie potwierdza całkowitej integralności wszystkich stron danych ani możliwości bezbłędnego odtworzenia bazy. Do dodatkowej kontroli służy między innymi RESTORE VERIFYONLY, które sprawdza, czy zestaw backupu jest kompletny i możliwy do odczytania przez operację przywracania w zakresie przewidzianym przez silnik. W praktyce przed odtworzeniem analizuje się także wynik RESTORE FILELISTONLY, aby poznać logiczne i fizyczne nazwy plików bazy oraz przygotować ewentualne mapowanie MOVE.
Znaczenie dat, pozycji i łańcucha kopii
Daty zwracane przez RESTORE HEADERONLY, takie jak BackupStartDate i BackupFinishDate, opisują moment wykonania konkretnej kopii według informacji zapisanych przez SQL Server. Pomagają uporządkować backupy chronologicznie, lecz nie zastępują analizy zależności między kopią pełną, różnicową i kopiami dziennika transakcji. Kopia różnicowa odnosi się do określonej kopii pełnej, a kopie dziennika muszą zachować ciągłość odpowiedniego łańcucha logu. Z tego powodu sama najnowsza data nie przesądza, że dany plik jest właściwym punktem rozpoczęcia odtwarzania.
Wynik polecenia może również ujawnić, że wskazany plik pochodzi z innej bazy, został utworzony przez inną wersję SQL Server albo zawiera kilka zestawów backupu. Te informacje są ważne przy planowaniu dalszych czynności administracyjnych, ale nie wykonują ich automatycznie. W razie problemów z odczytem pojawić się może błąd dostępu do pliku, nieprawidłowa ścieżka, uszkodzony nagłówek lub brak obsługi danego formatu przez używaną wersję silnika. W środowisku serwisowym analiza takiego komunikatu powinna obejmować zarówno SQL Server, jak i dostępność samego nośnika kopii.
