Weryfikacja kopii zapasowej poleceniem RESTORE VERIFYONLY sprawdza jej integralność bez faktycznego przywracania.
Co sprawdza polecenie RESTORE VERIFYONLY w SQL Server
RESTORE VERIFYONLY jest poleceniem Transact-SQL używanym w Microsoft SQL Server do weryfikacji kopii zapasowej bez odtwarzania bazy danych. SQL Server odczytuje informacje zapisane w zestawie kopii zapasowej i sprawdza, czy nośnik oraz struktura backupu pozwalają traktować go jako kopię przeznaczoną do przywrócenia. Operacja nie tworzy bazy, nie zmienia danych w istniejącej bazie i nie wykonuje właściwego procesu RESTORE DATABASE.
Przykładowe polecenie ma postać RESTORE VERIFYONLY FROM DISK = N'C:\Backup\Baza.bak';. W przypadku kopii zapisanej na urządzeniu taśmowym lub innym obsługiwanym nośniku wskazuje się odpowiednie urządzenie zamiast ścieżki pliku. Wynik pozytywny oznacza, że SQL Server odczytał kopię i potrafił zweryfikować jej podstawowe właściwości. Nie jest to jednak równoznaczne z pełnym potwierdzeniem, że każda strona danych jest logicznie poprawna.
Integralność pliku a możliwość pełnego odtworzenia
Weryfikacja dotyczy przede wszystkim kompletności zestawu backupu, możliwości odczytania jego nagłówków oraz zgodności informacji opisujących kopię. SQL Server może dzięki temu wykryć problemy takie jak uszkodzony plik, nieprawidłowy format nośnika, brak wymaganych fragmentów zestawu albo sytuację, w której wskazany plik nie zawiera oczekiwanego rodzaju kopii. Polecenie może także zwrócić informacje o bazie, z której wykonano backup, typie kopii i czasie jej utworzenia.
RESTORE VERIFYONLY nie odtwarza stron danych do plików MDF i LDF oraz nie sprawdza zachowania bazy po uruchomieniu. Nie zastępuje więc testowego przywrócenia kopii na oddzielnym środowisku. Dopiero rzeczywiste odtworzenie pozwala potwierdzić między innymi poprawność sekwencji kopii pełnej, różnicowej i dziennika transakcji, dostępność wszystkich wymaganych plików oraz możliwość wykonania kolejnych operacji przywracania w zakładanym punkcie czasu.
Opcje WITH i ograniczenia kontroli
Polecenie można rozszerzyć o opcje WITH zależnie od celu weryfikacji. WITH FILE = n wskazuje numer zestawu kopii zapisany w pliku backupu, gdy jeden nośnik zawiera więcej niż jeden zestaw. WITH LOADHISTORY zapisuje informacje o kopii w historii backupów w bazie msdb. Opcja WITH CHECKSUM powoduje sprawdzanie sum kontrolnych podczas odczytu, jeśli kopia zawiera odpowiednie informacje kontrolne.
Można również użyć opcji WITH MOVE w poleceniu RESTORE VERIFYONLY, aby wskazać docelowe lokalizacje plików bazy i sprawdzić, czy opisane pliki mogłyby zostać odtworzone pod podanymi ścieżkami. Przykład: RESTORE VERIFYONLY FROM DISK = N'C:\Backup\Baza.bak' WITH MOVE N'Baza_Data' TO N'D:\SQLData\Baza.mdf', MOVE N'Baza_Log' TO N'E:\SQLLogs\Baza.ldf';. Nazwy logiczne plików muszą odpowiadać nazwom zapisanym w kopii.
Brak błędu podczas wykonywania polecenia nie potwierdza istnienia kopii wszystkich zależnych elementów ani aktualności backupu. Dla kopii różnicowej trzeba mieć właściwą kopię pełną, a dla kopii dziennika transakcji także nieprzerwany łańcuch logów. Weryfikacja pojedynczego pliku nie wykryje braku wcześniejszego backupu wymaganego do zbudowania całej sekwencji odtwarzania.
Praktyczne użycie wyniku w procedurze backupowej
Wynik RESTORE VERIFYONLY powinien być interpretowany razem z historią wykonywania kopii, komunikatami SQL Server oraz informacją o miejscu przechowywania plików. Pozytywny rezultat warto rejestrować dla każdego utworzonego zestawu, ale sam test nie powinien być jedynym mechanizmem kontroli. Istotne jest także zachowanie kilku niezależnych kopii, sprawdzanie ich odczytu z rzeczywistego miejsca przechowywania oraz okresowe wykonanie kontrolnego przywrócenia.
Jeżeli polecenie zwraca błąd, nie należy uznawać danego pliku za bezpieczną podstawę odtworzenia. Przyczyną może być uszkodzenie danych, niepełne skopiowanie pliku, niedostępność ścieżki, brak uprawnień do odczytu albo użycie niewłaściwego numeru zestawu. Diagnostyka powinna obejmować pełny komunikat błędu, identyfikację nośnika, rozmiar pliku, czas utworzenia kopii oraz zgodność z planowaną kolejnością przywracania. W środowisku z laptopem lub komputerem PC analiza takich plików wymaga zachowania oryginalnej kopii i pracy na jej kopii roboczej, aby nie nadpisać materiału potrzebnego do dalszej weryfikacji.
