Uszkodzony backup

Uszkodzony backup to kopia zapasowa niemożliwa do poprawnego przywrócenia, wykrywana poleceniem RESTORE VERIFYONLY.

Czym jest uszkodzony backup w SQL Server

Uszkodzony backup to kopia zapasowa SQL Server, której nie można poprawnie odczytać albo wykorzystać do odtworzenia bazy danych. Problem może dotyczyć całego pliku, pojedynczego zestawu backupu znajdującego się na nośniku albo fragmentu danych zapisanych w kopii. Plik może nadal istnieć, mieć prawidłowe rozszerzenie .bak lub .trn i zajmować oczekiwany rozmiar, a mimo to zawierać uszkodzone bloki, niepełną zawartość albo błędy powstałe podczas kopiowania.

Do podstawowej kontroli kopii służy polecenie RESTORE VERIFYONLY. Sprawdza ono, czy SQL Server potrafi odczytać strukturę zestawu backupu i czy kopia jest wystarczająca do wykonania operacji przywracania na poziomie informacji zapisanych w nagłówku oraz metadanych backupu. Przykładowa składnia to: <RESTORE VERIFYONLY FROM DISK = 'D:\Backup\baza.bak'>. Pomyślne wykonanie polecenia jest ważną informacją diagnostyczną, ale nie stanowi pełnej gwarancji, że odtworzenie zakończy się sukcesem w każdej konfiguracji.

Jak powstaje problem z plikiem kopii

Uszkodzenie backupu może powstać już podczas tworzenia kopii, na przykład wskutek błędu odczytu danych z dysku, problemu z systemem plików, przerwania zadania lub błędu urządzenia docelowego. Inną przyczyną jest uszkodzenie pliku po zakończeniu backupu. Dotyczy to między innymi awarii dysku, błędów pamięci masowej, niepełnego kopiowania na inny nośnik albo przypadkowego nadpisania pliku. Sam fakt, że plik można skopiować w Eksploratorze Windows, nie potwierdza poprawności jego wewnętrznej struktury.

Znaczenie ma także sposób utworzenia kopii i jej miejsce w sekwencji odtwarzania. Pełny backup bazy, backup różnicowy oraz backup dziennika transakcji są różnymi typami kopii i mają określone zależności. Backup różnicowy wymaga właściwej kopii pełnej, a backup dziennika wymaga zachowania ciągłości łańcucha logów. W takiej sytuacji pojedynczy plik może przejść weryfikację, lecz cała planowana sekwencja przywracania może być niewykonalna z powodu brakującego albo niezgodnego elementu.

Weryfikacja i próba odtworzenia danych

Analizę należy rozpocząć od ustalenia, jaki typ kopii jest badany, z jakiej bazy pochodzi oraz czy plik został przeniesiony po utworzeniu. Następnie można odczytać informacje o backupie poleceniem RESTORE HEADERONLY, a zawartość logiczną zestawu sprawdzić poleceniem RESTORE FILELISTONLY. Te polecenia nie naprawiają kopii, ale pomagają ustalić, czy SQL Server rozpoznaje jej nagłówki, pliki danych i pliki dziennika transakcji.

Jeżeli backup został utworzony z kontrolą sum kontrolnych, podczas kontroli można użyć opcji WITH CHECKSUM, na przykład: <RESTORE VERIFYONLY FROM DISK = 'D:\Backup\baza.bak' WITH CHECKSUM>. Wykrycie błędu oznacza, że integralność odczytywanych danych nie zgadza się z informacją zapisaną w kopii. Bezpieczniejszym testem jest rzeczywiste przywrócenie backupu do odrębnej bazy testowej, o ile dostępny jest wystarczający nośnik i komplet wymaganych kopii. Dopiero taki test pozwala sprawdzić praktyczny przebieg odtworzenia, kolejność backupów oraz możliwość uruchomienia przywróconej bazy.

RESTORE VERIFYONLY nie zastępuje kontroli całego procesu odzyskiwania. Nie potwierdza między innymi, że administrator posiada wszystkie kopie potrzebne do odtworzenia konkretnego punktu w czasie, że ścieżki docelowe są dostępne ani że środowisko ma odpowiednią ilość wolnego miejsca. Dlatego wynik weryfikacji powinien być interpretowany razem z nagłówkiem backupu, dziennikiem zadania tworzącego kopię i próbą odtworzenia wykonанą w kontrolowanych warunkach.

Postępowanie przy podejrzeniu niepełnej kopii

Jeżeli SQL Server zgłasza błąd podczas RESTORE VERIFYONLY albo przywracania, należy zachować oryginalny plik i pracować na jego kopii, aby nie zmienić materiału potrzebnego do dalszej analizy. Warto porównać rozmiar pliku z informacjami z systemu tworzącego backup, sprawdzić datę modyfikacji oraz ustalić, czy kopiowanie zostało zakończone bez przerwania. Ponowne pobieranie lub kopiowanie pliku powinno odbywać się z kontrolą wyniku operacji, ponieważ drugi niepełny transfer może powielić ten sam problem.

Nie należy traktować zmiany nazwy rozszerzenia, kompresji, rozpakowania ani ponownego zapisania pliku jako naprawy backupu. Takie działania nie odtwarzają brakujących bloków ani nie rekonstruują uszkodzonego zestawu. Jeżeli istnieje wcześniejsza poprawna kopia pełna, można przeanalizować możliwość odtworzenia danych z niej oraz z dostępnych backupów różnicowych i dziennika transakcji. Zakres możliwego odzysku zależy od tego, które elementy łańcucha są czytelne i czy zachowano wymaganą kolejność przywracania.

Ocena uszkodzonej kopii SQL Server wymaga zachowania oryginalnych danych, sprawdzenia nośnika i rozdzielenia problemu programu od awarii dysku lub systemu plików.