Simple Recovery

Simple Recovery to model odzyskiwania automatycznie obcinający dziennik transakcji, uniemożliwiający odtworzenie do punktu w czasie.

Simple Recovery — czym jest ten model odzyskiwania

Simple Recovery to jeden z modeli odzyskiwania dostępnych w systemie Microsoft SQL Server. Określa sposób prowadzenia dziennika transakcji oraz zakres informacji, które pozostają w nim po wykonaniu operacji kontrolującej rozmiar pliku dziennika. Najważniejszą cechą tego modelu jest ograniczenie rozbudowy logu kosztem możliwości odtwarzania bazy danych do wybranej chwili. Po zakończeniu transakcji i wykonaniu punktu kontrolnego fragmenty dziennika, które nie są już potrzebne do bieżącej pracy, mogą zostać ponownie wykorzystane.

Nie oznacza to, że każda informacja o zmianach jest natychmiast tracona ani że system nie wykonuje żadnych kopii zapasowych. W tym modelu można tworzyć pełne kopie bazy danych oraz kopie różnicowe. Nie można jednak wykonywać kopii zapasowych samego dziennika transakcji. Z tego powodu nie da się zbudować ciągłego łańcucha kopii logu i wykorzystać go do odtworzenia stanu z dowolnego momentu pomiędzy pełnymi kopiami bazy.

Warto odróżnić model odzyskiwania od pojedynczej procedury backupu. Pełna kopia zawiera obraz danych z określonego czasu, natomiast model odzyskiwania definiuje, jak długo i w jakim celu przechowywane są informacje o zmianach. Simple Recovery może być właściwy tam, gdzie akceptuje się odtworzenie tylko do czasu ostatniej pełnej lub różnicowej kopii, a wymagania dotyczące utraty najnowszych zmian nie są restrykcyjne.

Simple Recovery a pełny model odzyskiwania i zakres odtworzenia

Najłatwiej zrozumieć Simple Recovery przez porównanie go z Full Recovery. W modelu pełnym dziennik transakcji jest utrzymywany w sposób pozwalający na wykonywanie kopii zapasowych logu. Każda taka kopia może obejmować kolejny fragment historii operacji, dzięki czemu odtwarzanie da się przeprowadzić etapami: najpierw przywracana jest pełna kopia, później ewentualna kopia różnicowa, a następnie kolejne kopie dziennika. Pozwala to ograniczyć zakres utraconych danych do niewielkiego przedziału, o ile kopie są wykonywane regularnie i pozostają dostępne.

W Simple Recovery po pełnej kopii można wykonać kopię różnicową. Kopia różnicowa zapisuje zmiany dokonane od czasu ostatniej pełnej kopii, dlatego kolejne kopie tego typu mogą rosnąć aż do wykonania następnej kopii pełnej. Przywracanie wymaga zazwyczaj użycia jednej pełnej kopii oraz najnowszej potrzebnej kopii różnicowej. Brakuje natomiast możliwości zastosowania kopii dziennika obejmującej operacje wykonane po utworzeniu tych plików.

Przykładowo, jeśli pełna kopia została utworzona rano, a kopia różnicowa w południe, awaria po południu może wymusić odtworzenie danych tylko do czasu tej kopii różnicowej. Operacje wykonane później mogą wymagać ponownego wprowadzenia z innych źródeł, takich jak dokumenty robocze, rejestry aplikacji lub dane przekazane przez użytkowników. Właśnie ten kompromis jest kluczowy przy wyborze modelu.

Simple Recovery upraszcza obsługę, ponieważ nie trzeba planować harmonogramu kopii dziennika ani pilnować jego ciągłości. Nie usuwa jednak potrzeby monitorowania miejsca na dysku, poprawności wykonywania kopii oraz możliwości ich odczytania. Prostszy model nie zastępuje strategii ochrony danych. Nadal potrzebny jest plan określający częstotliwość kopii pełnych i różnicowych, lokalizację plików, retencję oraz sposób testowania odtworzenia.

Simple Recovery — typowe problemy i skutki błędnej konfiguracji

Jednym z częstszych nieporozumień jest przekonanie, że Simple Recovery gwarantuje mały plik dziennika w każdej sytuacji. System może ponownie wykorzystywać zwolnione fragmenty logu, ale jeśli aktywna transakcja długo pozostaje otwarta, dziennik może nadal zajmować dużo miejsca. Podobny efekt może wystąpić podczas dużej operacji modyfikującej dane, przebudowy indeksów, importu, aktualizacji wielu rekordów albo oczekiwania na zakończenie procesu blokującego inne transakcje.

Wzrost rozmiaru pliku nie zawsze oznacza awarię. Należy sprawdzić, jaka część dziennika jest zajęta, co uniemożliwia ponowne wykorzystanie miejsca oraz czy plik ma ustawiony rozsądny przyrost. Wielokrotne powiększanie logu o bardzo małe wartości może prowadzić do fragmentacji pliku i niepotrzebnych opóźnień. Z kolei jednorazowe przydzielenie przesadnie dużego obszaru może ograniczyć wolne miejsce na woluminie. Zmiany rozmiaru powinny wynikać z obserwowanego obciążenia, a nie z przypadkowych ustawień.

Innym problemem jest mylenie skrócenia dziennika z pomniejszeniem pliku na dysku. Zwolnienie wewnętrznych fragmentów logu pozwala wykorzystać je ponownie, lecz nie musi zmniejszyć fizycznego rozmiaru pliku. Ręczne zmniejszanie dziennika po każdym większym zadaniu nie jest uniwersalnym sposobem zarządzania miejscem. Może powodować cykl ciągłego wzrostu i zmniejszania, który obciąża system oraz utrudnia przewidywanie zapotrzebowania na przestrzeń.

Ryzykowne jest także przełączenie modelu bez sprawdzenia istniejącej polityki kopii. Po zmianie z modelu pełnego na Simple Recovery wcześniejszy łańcuch kopii dziennika przestaje być użyteczny w dotychczasowy sposób. Po powrocie do modelu pełnego trzeba ponownie wykonać pełną kopię bazy, aby rozpocząć nowy, poprawny łańcuch kopii logu. Sama zmiana ustawienia nie tworzy kopii i nie zabezpiecza danych.

Simple Recovery — praktyczne wskazówki dotyczące kopii i kontroli

Przed wyborem modelu należy ustalić, ile danych można odtworzyć ręcznie oraz jak długi może być akceptowany okres między kopią a awarią. Jeżeli wystarcza odtworzenie do ostatniej kopii pełnej lub różnicowej, Simple Recovery może odpowiadać przyjętym wymaganiom. Jeżeli potrzebne jest odtwarzanie do konkretnej minuty, należy rozważyć model umożliwiający wykonywanie kopii dziennika i przygotować procedurę ich regularnego tworzenia.

Harmonogram kopii powinien uwzględniać wielkość bazy, częstotliwość zmian oraz znaczenie poszczególnych danych. Kopia pełna stanowi podstawę odtworzenia. Kopie różnicowe skracają czas odzyskiwania, ponieważ nie trzeba odtwarzać każdej kopii pełnej wykonanej wcześniej. Same pliki kopii powinny być przechowywane poza głównym nośnikiem danych, ponieważ awaria dysku, systemu plików lub całego urządzenia może pozbawić dostępu zarówno do bazy, jak i do lokalnego backupu.

Warto okresowo wykonywać próbne odtworzenie na oddzielnym środowisku. Taki test pozwala sprawdzić, czy pliki nie są uszkodzone, czy znana jest kolejność ich użycia oraz czy aplikacje potrafią połączyć się z odtworzoną bazą. Należy też zapisać osoby odpowiedzialne za uruchomienie procedury, lokalizację kopii oraz sposób potwierdzenia, że odtworzone dane są kompletne. Sam komunikat o pomyślnym zakończeniu zadania backupu nie dowodzi jeszcze, że odzyskiwanie zakończy się powodzeniem.

Przydatne jest monitorowanie wolnego miejsca, czasu trwania kopii, rozmiaru pliku dziennika i liczby błędów w zadaniach. Nagła zmiana tych wartości może wskazywać na nowy typ obciążenia, niezamkniętą transakcję, problem z miejscem na dysku albo niewłaściwie działający harmonogram. Dokumentacja powinna opisywać także wyjątki, na przykład duże importy wykonywane poza zwykłym cyklem pracy. Dzięki temu można odróżnić przewidywany chwilowy wzrost obciążenia od rzeczywistej awarii konfiguracji.

Simple Recovery — kiedy zgłosić się do serwisu

Wsparcie serwisowe może być potrzebne, gdy plik dziennika stale rośnie, baza zgłasza brak miejsca, kopie nie kończą się poprawnie albo nie ma pewności, czy można odtworzyć dane po awarii. W pierwszej kolejności należy zabezpieczyć aktualne pliki i logi systemowe, nie usuwać ich pochopnie oraz zanotować moment pojawienia się problemu. Szczególnie ostrożnie należy postępować wtedy, gdy baza jest używana przez aplikację obsługującą bieżące dokumenty, zamówienia lub ewidencję.

Podczas zgłoszenia warto przekazać informacje o modelu odzyskiwania, ostatnich poprawnych kopiach, wolnym miejscu na dysku, czasie wystąpienia błędu oraz operacjach wykonywanych bezpośrednio przed problemem. Pomaga to odróżnić kłopot z samym dziennikiem od uszkodzenia nośnika, przerwanego zadania kopii, blokady transakcji lub błędów połączenia. Nie powinno się zmieniać modelu odzyskiwania tylko po to, aby ukryć objaw, ponieważ taka decyzja może wpłynąć na późniejsze możliwości odtworzenia.

W przypadku potrzeby uporządkowania środowiska, oceny kopii lub przygotowania planu odzyskiwania można skorzystać z pomocy firmy Warszawskie Pogotowie Komputerowe 24/7. Przed rozpoczęciem prac należy ustalić zakres diagnostyki, sposób zabezpieczenia danych oraz kolejność działań. Prawidłowa ocena Simple Recovery powinna obejmować nie tylko bieżący rozmiar dziennika, lecz także wymagany poziom odtwarzania, dostępność kopii, stan nośników i realną procedurę przywrócenia pracy po awarii.