Przywracanie z backupu jako alternatywa

Przywracanie z backupu jako alternatywa wobec naprawy bywa bezpieczniejsze niż ryzykowna próba DBCC z utratą danych.

Backup jako kontrolowana ścieżka odzyskania bazy

Przywracanie z backupu oznacza odtworzenie bazy danych SQL Server z wcześniej wykonanej kopii zapasowej. W praktyce jest to alternatywa wobec prób naprawy uszkodzonych struktur bazy za pomocą poleceń DBCC, zwłaszcza gdy kontrola spójności wykazuje uszkodzenia stron danych, indeksów albo metadanych. Jeżeli istnieje poprawna kopia wykonana przed wystąpieniem awarii, odtworzenie jej może ograniczyć zakres niepewnych zmian bezpośrednio w uszkodzonych plikach danych.

Backup nie jest jednak pojedynczym, uniwersalnym plikiem gwarantującym odzyskanie całego aktualnego stanu. W SQL Server znaczenie ma rodzaj kopii: pełna kopia bazy zawiera zapis danych potrzebny do odtworzenia określonego punktu, kopia różnicowa obejmuje zmiany od ostatniej pełnej kopii, a kopie dziennika transakcji pozwalają odtworzyć kolejne operacje po wykonaniu pełnego backupu. Możliwość odzyskania konkretnego momentu zależy od zachowanego łańcucha kopii oraz od tego, czy dziennik transakcji był zabezpieczany bez przerwy.

Różnica między odtworzeniem a naprawą DBCC

Naprawa DBCC CHECKDB jest mechanizmem diagnostycznym i naprawczym SQL Server, ale jej użycie w trybie naprawy może prowadzić do usunięcia lub odrzucenia elementów, których silnik nie potrafi jednoznacznie odtworzyć. Polecenia naprawcze DBCC nie rekonstruują automatycznie danych na podstawie wcześniejszej historii. Działają na aktualnym stanie plików bazy, dlatego przed ich użyciem należy zachować kopię uszkodzonej bazy i ustalić, jakie informacje mogą zostać utracone.

Przywrócenie backupu korzysta z innego źródła prawdy: z zapisanej kopii danych oraz, jeżeli są dostępne, kolejnych kopii dziennika transakcji. Oznacza to cofnięcie bazy do wybranego punktu, a nie próbę logicznego odtworzenia uszkodzonych stron w miejscu ich wystąpienia. W zależności od konfiguracji można odtworzyć pełną kopię, następnie właściwą kopię różnicową i kolejne kopie logu. Każda część sekwencji musi pochodzić z tego samego łańcucha odzyskiwania i być zastosowana w prawidłowej kolejności.

Nie należy utożsamiać przywracania z bezstratnym rozwiązaniem. Jeśli ostatnia poprawna kopia powstała przed częścią operacji biznesowych, tych operacji nie będzie w odtworzonej bazie. Jeżeli zachowano kopie dziennika transakcji obejmujące okres między backupem pełnym a awarią, można zmniejszyć zakres utraconych zmian, ale tylko do momentu objętego poprawnym logiem. Ocena tej różnicy jest ważniejsza niż samo stwierdzenie, że backup istnieje.

Weryfikacja kopii przed decyzją o odzyskaniu

Przed rozpoczęciem odtwarzania trzeba sprawdzić, z jakiej daty pochodzi kopia, jaki obejmuje zakres danych oraz czy można ją odczytać. W SQL Server do podstawowej kontroli kopii służą między innymi RESTORE VERIFYONLY, RESTORE HEADERONLY i RESTORE FILELISTONLY. VERIFYONLY sprawdza, czy zestaw backupu ma poprawną strukturę i może być potencjalnie odczytany, natomiast pozostałe polecenia pozwalają odczytać metadane kopii oraz informacje o plikach logicznych i fizycznych. Sam wynik weryfikacji nie dowodzi jednak, że każda wartość biznesowa w bazie jest poprawna.

Bezpieczna ocena powinna obejmować także próbne odtworzenie kopii do odrębnej lokalizacji lub instancji SQL Server, jeśli dostępne środowisko na to pozwala. Po odtworzeniu można uruchomić DBCC CHECKDB bez opcji naprawczych i sprawdzić spójność logiczną oraz fizyczną bazy. Należy również porównać kluczowe tabele, liczbę rekordów, indeksy, widoki i obiekty zależne od bazy. Szczególnej uwagi wymagają kopie różnicowe i logi transakcji, ponieważ ich użycie ma sens tylko wtedy, gdy SQL Server może zbudować ciągłą sekwencję od właściwego backupu pełnego.

Ważne jest rozróżnienie między uszkodzeniem bazy a uszkodzeniem samego nośnika lub pliku backupu. Jeżeli pliki danych są niestabilne, dalsza praca na nich może pogłębiać problem. Jeżeli natomiast kopia zapasowa została zapisana na uszkodzonym dysku, najpierw trzeba zabezpieczyć dostępne kopie i ich metadane. Wynik kontroli powinien odpowiedzieć na trzy pytania: jaki jest najnowszy możliwy punkt odzyskania, które transakcje zostaną utracone oraz czy odtworzona baza przejdzie kontrolę spójności.

Dobór punktu odzyskania i dalsza obsługa

Wybór backupu powinien wynikać z porównania dwóch ryzyk: utraty zmian od czasu wykonania kopii oraz nieprzewidywalnych skutków naprawy aktualnej bazy. Gdy priorytetem jest zachowanie spójnego, znanego stanu, przywrócenie zaakceptowanej kopii może być właściwsze niż wymuszanie naprawy na jedynym egzemplarzu uszkodzonych danych. Jeżeli wymagane jest odzyskanie możliwie najpóźniejszego stanu, trzeba ustalić, czy dostępne kopie dziennika obejmują czas bezpośrednio poprzedzający awarię.

Po odtworzeniu należy zweryfikować działanie aplikacji korzystającej z SQL Server, uprawnienia, połączenia, zadania zależne od bazy oraz poprawność najważniejszych operacji odczytu i zapisu. Przywrócenie plików nie oznacza automatycznego przywrócenia całego środowiska pracy. Trzeba także udokumentować użyte kopie, kolejność operacji, wybrany punkt odzyskania i zakres zmian, których nie udało się odtworzyć. Taka dokumentacja pozwala odróżnić dane odzyskane z backupu od danych, które wymagały ponownego wprowadzenia.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, natomiast decyzje dotyczące przywracania baz SQL Server powinny uwzględniać właściwości konkretnej instancji, dostępność kopii oraz wymagania środowiska, w którym baza pracuje. W przypadku zwykłego komputera używanego do przechowywania kopii najpierw należy zabezpieczyć nośniki i nie nadpisywać istniejących plików backupu. Dopiero po zachowaniu materiału źródłowego można przeprowadzić kontrolowane testy odczytu i ocenić, czy odzyskanie danych jest możliwe bez dalszego pogorszenia ich stanu.