Kopie zapasowe SQL Server

Autor: Paul S. Randal

Opublikowano: 31 sierpnia 2009

Zawartość strony

	Pełne kopie zapasowe
	Różnicowe kopie zapasowe
	Kopie zapasowe dzienników transakcji
	Planowanie strategii archiwizacji
	Integralność kopii zapasowej

Czy naprawdę trzeba tworzyć kopie zapasowe SQL Server? Tak. Potrzebny jest jakiś sposób przywracania bazy danych do punktu nadającego się do użytku, chyba że ktoś nie dba o swoje dane lub nie przejmuje się koniecznością odtwarzania swojej bazy danych w przypadku awarii. Niektórzy twierdzą, iż posiadanie nadmiarowej kopii bazy danych w innym miejscu eliminuje potrzebę posiadania kopii zapasowych, lecz co będzie, gdy ta kopia jest uszkodzona lub niedostępna? Kopie zapasowe Backups są nadal konieczne, aby zawsze mieć pewność odzyskania danych.

Lecz jaki rodzaj kopii zapasowych należy wykonywać? Jak często trzeba je wykonywać? Jak wpływają one na bazę danych i obciążenie? I jak się upewnić, że są poprawne?

Zbudowanie strategii tworzenia kopi zapasowych jest w rzeczywistości łatwiejsze, niż można sądzić, mimo że polecenia BACKUP i RESTORE mają nadmiar opcji. Pomogę to wszystko zrozumieć.

To pierwszy artykuł z trzyczęściowej serii. Tutaj, w części 1., opisuję kopie zapasowe. W części 2. (wydanie we wrześniu 2009) omówię odzyskiwanie po awarii za pomocą kopii zapasowych. A w części 3 (wydanie w listopadzie 2009) popatrzymy na odzyskiwanie po awarii bez kopii zapasowych. Zamierzam zająć się tematem nieco głębiej niż zwykle w takich artykułach, lecz korzystając z materiałów wprowadzających czytelnicy powinni być w stanie go prześledzić.

W artykule z tego miesiąca wyjaśnię podstawy działania różnych typów kopii zapasowych i jak można ich użyć w strategii archiwizacji. Będzie to przydatne dla osób, które mają trochę wiedzy na temat działania dziennika transakcji (patrz mój artykuł „Rejestrowanie i odzyskiwanie w SQL Server"). Nie ma sensu posiadanie kopii zapasowych, jeśli okażą się uszkodzone, gdy spróbujemy ich użyć, więc wyjaśnię także, jak dodać do nich sprawdzanie integralności. Będę jednocześnie obalać niektóre powszechne błędne przekonania i podawać łącza do dalszych informacji.

Nie będę zajmować się jednak wyjaśnianiem, jak działa składnia BACKUP i jak wykonywać różne typy kopii zapasowych. SQL Server Books Online ma doskonałe fragmenty, które obejmują ten temat, po co więc tracić tutaj miejsce na ich dublowanie? Więcej informacji można znaleźć pod tematem „Backup (Transact-SQL)", szczególnie na końcu, w części Examples. Temat „Backing Up and Restoring How-to Topics (SQL Server Management Studio)" wyjaśnia, jak korzystać z narzędzi do tworzenia kopii zapasowych. Najlepiej jednak zobaczyć „jak to zrobić” po przeczytaniu niniejszego artykułu, ponieważ tutaj wyjaśnię „co” i „dlaczego”.

Implementacja strategii archiwizacji jest częścią stosunkowo łatwą. Projektowanie efektywnej strategii jest bardzo ważną, choć często pomijaną częścią.

Pełne kopie zapasowe

Najprostszym rodzajem kopii zapasowej jest pełna kopia zapasowa. Można także robić pełne kopie zapasowe pojedynczego pliku danych lub grupy plików. Nie jest to jednak powszechnie stosowane, a ponieważ wszystkie omówione zasady mają zastosowanie także do nich, skupię się na kopiach zapasowych na poziomie bazy danych. Począwszy od SQL Server 2005, każdy z bardziej szczegółowych typów kopii zapasowych funkcjonuje tak samo (nie było tak w SQL Server 2000). To samo dotyczy różnicowych kopii zapasowych – mogą być wykonywane dla pliku, grupy plików lub na poziomie bazy danych – wszystkie działają w taki sam sposób, niezależnie od archiwizowanego komponentu.

Pełna kopia zapasowa bazy danych zapewnia kompletną kopię bazy danych oraz pojedynczy punkt w czasie, do którego baza może być przywrócona. Chociaż wykonanie procesu archiwizacji może trwać godziny, nadal możemy przywrócić kopię zapasową do pojedynczego punktu (faktycznie na końcu kopii zapasowej, lecz w dalszej części artykułu omówię dokładniej ten punkt). Pełna kopia zapasowa nie pozwala na przywracanie do żadnego punktu w czasie wykonywania kopii zapasowej. To samo dotyczy kopii różnicowych.

Na ten temat istnieją jednak błędne wyobrażenia, dla których pożywką jest fakt, że przy przywracaniu pełnych lub różnicowych kopii zapasowych można użyć opcji WITH STOPAT=<czas lub numer kolejny dziennika>. Chociaż pozwala na to składnia, opcja nie działa i istnieje tylko dla wygody.

Innym mylnym wyobrażeniem na temat pełnych kopii zapasowych jest to, że zawierają one tylko dane. Zarówno pełne, jak i różnicowe kopie zapasowe zawierają także kilka rekordów dziennika transakcji, aby przywracany komponent (baza danych, plik lub grupa plików) mógł być spójny transakcyjnie.

Rozważmy przykład transakcji, która wstawia rekord do tabeli z pojedynczym indeksem nieklastrowanym. Strony tabeli i indeksu są rozłożone w pliku danych. Transakcja jest wewnętrznie podzielona na dwie części: wstawienie rekordu na stronę danych w tabeli, a następnie wstawienie wymaganego rekordu na stronę indeksu w indeksie nieklastrowanym. Jeśli tak się dzieje, że proces archiwizacji czyta stronę indeksu nieklastrowanego przed wstawieniem rekordu, ale czyta stronę danych tabeli po wstawieniu rekordu, wtedy baza danych reprezentowana tylko przez dane w kopii zapasowej jest transakcyjnie niespójna.

Tutaj do gry wchodzi dziennik transakcji. Poprzez włączenie do kopii zapasowej także niektórych rekordów dziennika transakcji, odzyskiwanie może działać na przywracanej kopii bazy danych i będzie ona spójna transakcyjnie. W przypadku tego przykładu transakcji, w zależności od tego, kiedy jest zatwierdzona, część odzyskiwania może przy przywracaniu przesunąć ją do przodu (co oznacza, że będzie się pojawiać jako zatwierdzona w przywróconej kopii bazy danych) lub cofnąć (co oznacza, że nie pojawi się w przywróconej kopii bazy danych). W obydwu przypadkach spójność transakcyjna jest utrzymana, co jest sprawą zasadniczą.

Pełna kopia zapasowa robi, co następuje:

• Narzuca punkt kontrolny bazy danych i tworzy zapis kolejnego numeru dziennika w tym punkcie. To przesyła wszystkie zaktualizowane w pamięci strony na dysk, zanim cokolwiek zostanie odczytane przez program kopii zapasowej, aby zminimalizować ilość pracy, jaka musi być wykonana przy przywracaniu.
• Rozpoczyna odczyt z plików danych w bazie danych.
• Kończy odczyt z plików danych i tworzy zapis kolejnego numeru dziennika początku najstarszej aktywnej transakcji w tym punkcie (patrz mój artykuł "Understanding Logging and Recovery in SQL Server" z wyjaśnieniem tych pojęć).
• Odczytuje tyle dziennika transakcji, ile jest potrzebne.

Najlepsze wyjaśnienie, ile potrzeba dziennika transakcji, jest przedstawione wizualnie na rysunku 1. Czerwone liczby na skali czasu są wyjaśnione na poniższej liście:

• Punkt kontrolny i początek odczytu bazy danych.
• Operacja odczytu czyta stronę X.
• Rozpoczyna się transakcja A.
• Transakcja A dokonuje zmiany na stronie X. Kopia w kopii zapasowej jest teraz nieaktualna. Zwróćmy uwagę, że kopia zapasowa nie będzie ponownie czytać strony X – już przeszła ten punkt w bazie danych.
• Rozpoczyna się transakcja B. Nie będzie zakończona, dopóki nie skończy się operacja odczytu.
• Transakcja A jest zatwierdzona. To powoduje zatwierdzenie zmian na stronie X.
• Operacja odczytu danych kopi zapasowej zostaje zakończona i rozpoczyna się odczyt dziennika transakcji.

Rysunek 1: Przykład linii zmian w czasie przy wykonywaniu pełnej kopii zapasowej.

Opis rysunku: 1 – punkt kontrolny, 2 – kopia zapasowa czyta stronę X, 3 – rozpoczyna się transakcja A, 4 – transakcja A zmienia stronę X, 5 – rozpoczyna się transakcja B, 6 – kończy się transakcja A, 7 – kończy się odczyt danych kopii zapasowej.

Wymagana jest archiwizacja wystarczającej części dziennika transakcji, aby odzyskanie mogło być z powodzeniem wykonane podczas przywracania i aby wszystkie strony w bazie danych miały taki sam punkt czasu – czas, w którym zakończy się odczyt porcji danych przez operację tworzenia kopii zapasowej (punkt 7). Dziennik transakcji od rozpoczęcia najstarszej aktywnej (lub niezatwierdzonej) transakcji (punkt 5, transakcja B) do końca kopii zapasowej (punkt 7), jest potrzebny, aby odzyskanie mogło być uruchomione. Dziennik transakcji od punktu kontrolnego kopii zapasowej (punkt 1) do końca kopii zapasowej (punkt 7) jest potrzebny, aby wszystkie strony zostały sprowadzone do tego samego punktu w czasie.

Gdyby dziennik transakcji został włączony tylko na początku najstarszej aktywnej transakcji (punkt 5), wtedy kopia strony X, która została przywrócona z odczytu kopii zapasowej w punkcie 2., nie byłaby zaktualizowana za pomocą zmian z transakcji A, które miały miejsce w punkcie 4. To oznacza, że nie byłaby spójna transakcyjnie z resztą bazy danych dla punktu czasu zakończenia operacji odczytu danych (punkt 7).

Tak więc najmniejszy kolejny numer dziennika (LSN, log sequence number) dziennika transakcji, który jest włączony do pełnej kopii zapasowej, jest równy MIN (LSN punktu kontrolnego kopii zapasowej, LSN najstarszej aktywnej transakcji) i może dotyczyć nawet transakcji, która zaczyna się przed rozpoczęciem archiwizacji. To gwarantuje, że przywracana kopia bazy danych (lub tego, co jest przywracane – strony, pliku, grupy plików, bazy danych) jest całkowicie spójna.

Ten mechanizm oznacza, że transakcja nie została zatrzymana w żaden sposób przez operacje archiwizacji, chociaż dodatkowe obciążenie we/wy w bazie danych może nieco ją zwolnić. Wadą tego mechanizmu jest fakt, że dziennik transakcji nie może być czyszczony w czasie wykonywania kopii zapasowej, ponieważ jest potrzebny. Jeśli jest dużo działań aktualizacyjnych i wykonanie pełnej kopii zapasowej zajmuje dużo czasu, to może doprowadzić do zwiększenia dziennika transakcji – problemu, który już był omawiany w kilku wcześniejszych artykułach w dziale SQL Q&A.

Dane zawarte w pełnej kopii zapasowej nie muszą być koniecznie całą zawartością wszystkich plików danych. Kopia zapasowa będzie zawierać tylko strony z plików danych, które są alokowane. Na przykład jednoplikowa baza danych może mieć 100 GB, a zawierać tylko 15 GB alokowanych danych. W takim przypadku pełna kopia zapasowa będzie zawierać tylko 15 GB alokowanych danych plus konieczny dziennik transakcji (jednak przywrócona baza danych będzie zawsze tego samego rozmiaru co oryginalna – w tym przypadku 100 GB).

Innym błędnym przekonaniem jest to, że proces archiwizacji bada lub zmienia archiwizowane dane. To nieprawda, z wyjątkiem pojedynczego przypadku, gdy są włączone sumy kontrolne, które dalej wyjaśnię.

 Do początku strony

Różnicowe kopie zapasowe

Innym typem kopii zapasowych danych są kopie różnicowe. Różnicowa kopia zapasowa wykonuje takie same operacje jak pełna kopia zapasowa, lecz zawiera tylko dane zmienione lub dodane od wykonania poprzedniej pełnej kopii zapasowej. Powszechnym błędnym przekonaniem jest tutaj to, że kopie różnicowe są przyrostowe. Są one faktycznie narastającymi i sukcesywnymi kopiami różnicowymi po pełnej kopii zapasowej i będą rosnąć, gdy coraz więcej danych będzie zmienianych lub dodawanych.

W każdej 4-gigabatowej części (zwanej interwałem GAM) każdego pliku danych jest specjalna strona bazy danych nazywana bitmapą różnicową, która śledzi, jakie porcje (nazywane ekstensjami) 4-gigabajtowej sekcji zmieniły się od ostatniej pełnej kopii zapasowej, wskazując dane, które zostały zmienione lub dodane do bazy danych. (Jest również kilka innych map bitowych alokacji. Więcej informacji na ten temat można znaleźć w moim blogu, w artykule „Inside The Storage Engine: GAM, SGAM, PFS and other allocation maps").

Różnicowa baza danych przeszukuje te mapy bitowe i archiwizuje tylko ekstensje plików danych, które są oznaczone jako zmienione. Mapy bitowe są ponownie ustawiane przez następną pełną kopię zapasową, więc można zobaczyć, że gdy liczba zmian w bazie danych będzie się powiększać, tym większa jej część będzie zaznaczona w różnicowych mapach bitowych i kolejne różnicowe kopie zapasowe będą coraz większe. W końcu, jeśli większość bazy danych zostanie zmieniona, kopia różnicowa może stać się tak duża jak pełna kopia zapasowa. Można dowiedzieć się, jak duża będzie następna kopia różnicowa, korzystając z napisanego przeze mnie skryptu, który jest dostępny na moim blogu, w artykule „New script: How much of the database has changed since the last full backup?". Nawiasem mówiąc, tego skryptu można także użyć, aby poznać ideę wskaźnika migracji (ang. churn rate) bazy danych – na przykład w bazie danych zawartości SharePoint.

Na marginesie, jeśli ktoś chce zrobić pełną kopię zapasową ad-hoc i nie ma zresetowanych jej różnicowych map bitowych, powinien użyć opcji WITH COPY_ONLY w instrukcji BACKUP. To bardzo przydatne, ponieważ inaczej następne kopie różnicowe będą oparte na zrobionej ad-hoc pełnej kopii zapasowej, zamiast regularnej (prawdopodobnie zaplanowanej) pełnej kopii zapasowej. To może prowadzić do dużych problemów, gdy próbujemy ją przywrócić w sytuacji awaryjnej.

Dlaczego więc różnicowe kopie zapasowe są użyteczne? Jak to omawiam w części dotyczącej strategii archiwizacji, różnicowe kopie zapasowe mogą faktycznie przyspieszyć operacje przywracania, gdyż pozwalają na pominięcie w procesie przywracania wielu kopii zapasowych transakcji. W gruncie rzeczy dużo szybciej jest skoczyć do przodu w czasie, korzystając z różnicowej kopii zapasowej, niż być zmuszonym do powtarzania wielu rekordów dziennika transakcji, aby uzyskać taki sam punkt w czasie.

 Do początku strony

Kopie zapasowe dzienników transakcji

Kopie zapasowe dzienników transakcji można tworzyć tylko w modelach odzyskiwania FULL lub BULK_LOGGED, podczas gdy pełne i różnicowe kopie zapasowe są także dostępne w modelu SIMPLE.

Kopia zapasowa dziennika transakcji zawiera wszystkie rekordy dziennika transakcji wygenerowane od ostatniej kopi zapasowej dziennika (lub pełnej kopii, która rozpoczyna łańcuch kopii zapasowych dziennika) i umożliwia odzyskiwanie bazy danych do określonego punktu w czasie (zwykle czas tuż przed nadejściem awarii). Oznacza to, że są one przyrostowe, w przeciwieństwie do różnicowych kopii zapasowych, które są kumulacyjne. Ponieważ są one przyrostowe, jeśli chcemy przywrócić bazę danych do określonego punktu w czasie, musimy mieć wszystkie rekordy dzienników transakcji potrzebne do powtórzenia zmian od tego punktu czasu. Są one zawarte w łańcuchu kopii zapasowych dziennika.

Łańcuch kopii zapasowych dziennika jest nieprzerwanym szeregiem kopii zapasowych dziennika, który zawiera wszystkie rekordy dziennika transakcji potrzebne do przywrócenia bazy do określonego punktu w czasie. Łańcuch zaczyna się od pełnej kopii zapasowej bazy danych i trwa aż nie zostanie przerwany, nie dopuszczając w ten sposób, aby więcej kopii zapasowych dziennika było wykonanych przed zrobieniem jeszcze jednej pełnej (lub różnicowej) kopii zapasowej.

Operacje, które przerywają łańcuch kopii zapasowych dziennika, obejmują przełączenie do modelu odzyskiwania SIMPLE, co powoduje powrót z migawki bazy danych i przymusowe czyszczenie dziennika przy użyciu opcji WITH NO_LOG lub TRUNCATE_ONLY (które nie są dostępne w SQL Server 2008). Niewskazane jest przerywanie łańcucha kopii zapasowych dziennika, ponieważ wymusza to wykonanie jeszcze jednej (potencjalnie dużej) pełnej kopii zapasowej.

Chociaż łańcuch kopii zapasowych dziennika rozciąga się wstecz do pełnej kopii zapasowej, nie trzeba koniecznie podczas odzyskiwania przywracać wszystkich tych kopii zapasowych dzienników. Jeśli zrobiliśmy pełną kopię zapasową, powiedzmy w niedzielę wieczorem i w środę wieczorem, z kopiami zapasowymi dziennika co pół godziny od niedzieli wieczorem, przywracając następnie bazę danych po awarii w piątek możemy użyć pełnej kopii zapasowej ze środy plus wszystkich kopii zapasowych od środy wieczorem, zamiast wracać do pełnej kopii zapasowej z niedzieli. (W drugim artykule w naszej serii wejdziemy głębiej w ten temat).

Kopie zapasowe dziennika są potrzebne także jako pomoc w zarządzaniu rozmiarem dziennika transakcji. W modelach odzyskiwania FULL lub BULK_LOGGED dziennik nie będzie wyczyszczony, dopóki nie zostanie wykonana jego kopia zapasowa (szczegóły tego, co znaczy czyszczenie dziennika, we wcześniejszym artykule), więc trzeba wykonywać regularne kopie zapasowe dziennika, aby zapobiegać niekontrolowanemu rozrostowi pliku dziennika. Jeśli dziennik nie może być wyczyszczony, będzie rósł aż do wyczerpania miejsca. Wobec tego, jeśli nie chcemy wykonywać przywracania sytuacji z danego punktu w czasie za pomocą kopii zapasowych dziennika, najprostszą opcją jest przełączenie się do modelu odzyskiwania SIMPLE, zamiast użycia modeli FULL lub BULK_LOGGED. Omawiam to bardziej szczegółowo na moim blogu, w poście „Importance of proper transaction log size management".

Jest specjalny przypadek rejestrowania, który poprawia wydajność, pozwalając niektórym operacjom działać jako operacje z minimalnym rejestrowaniem, w których rejestrowane są tylko alokacje stron, a nie rzeczywiste wstawianie danych. Może to poprawić wydajność operacji, takich jak masowe ładowanie i przebudowa indeksu. W takich przypadkach nie wszystkie informacje dotyczące operacji są rejestrowane, więc zarchiwizowane rekordy dziennika nie zawierają dostatecznej informacji do pełnego powtórzenia operacji. Jak w takim przypadku może działać przywracanie i odzyskiwanie, jeśli nie ma dostatecznej informacji?

Odpowiedź jest taka, że pierwsza kopia zapasowa następująca po minimalnie rejestrowanej operacji zawiera także trochę danych. Tak jak w przypadku różnicowych map bitowych, o których wspomniałem wcześniej, istnieje inna mapa bitowa nazywana mapą z minimalną rejestracją (czasami nazywaną mapą zmian masowych). Ta mapa bitowa śledzi, które ekstensje plików danych zmieniły się na skutek operacji z minimalną rejestracją.

Kopia zapasowa dziennika następująca po operacji z minimalną rejestracją przeszuka te mapy bitowe, a także zarchiwizuje ekstensje danych, które są zaznaczone jako zmienione. Mapy bitowe są czyszczone po ich przeszukaniu. To oznacza, że kopia zapasowa dziennika ma dość informacji do pełnego powtórzenia efektów minimalnie rejestrowanej operacji w bazie danych, kiedy kopia zapasowa dziennika będzie odzyskiwana. Jest tu jednak haczyk: nie ma nic w tej kopii zapasowej dziennika, co mówi, kiedy określona ekstensja danych została zmieniona. Więc kopia zapasowa dziennika, która zawiera także dane z operacji minimalnie rejestrowanych, nie może być przywracana do żadnego punktu w czasie poza końcem okresu, który obejmuje (lub poza nim, jeśli kopia zapasowa dziennika jest częścią łańcucha kopii zapasowych, z którego dokonujemy przywrócenia). Zatem, chociaż, przełączając się na model odzyskiwania BULK_LOGGED, można uzyskać poprawę wydajności, trzeba traktować tę zmianę modelu jako operację tymczasową – tylko po to, by ulepszyć proces wsadowy, a gdy proces wsadowy będzie zakończony, należy przełączyć się z powrotem na FULL i wykonać kopię zapasową dziennika tak szybko, jak to możliwe.

Istnieje także specjalny przypadek kopii zapasowej dziennika, który pozwala archiwizować dziennik po awarii, która zniszczyła pliki danych. Nosi ona nazwę kopii zapasowej typu tail-of-the-log (lub tail-log), w której pliki danych mogą być uszkodzone lub zniszczone, lecz cały dziennik transakcji prowadzający do punktu awarii może być zarchiwizowany. Dzięki temu strata pracy jest minimalna (jest to określane jako odzyskiwanie do co minuty), kiedy baza danych jest później przywracana; jednak jest to obsługiwane tylko wtedy, gdy baza danych działa w modelu odzyskiwania FULL. Więcej informacji na ten temat oraz o ograniczeniach dotyczących operacji z minimalną rejestracją można znaleźć w Books Online, pod tematem „Tail-Log Backups." Na pierwszym zrzucie ekranu, dołączonym do tego artykułu, pokazuję kopie zapasowe typu tail-of-the-log.

W wersjach SQL Server wcześniejszych niż SQL Server 2005 kopie zapasowe dziennika transakcji nie mogły być wykonywane jednocześnie z pełnymi lub różnicowymi kopiami zapasowymi – były blokowane aż do zakończenia tworzenia kopii na poziomie bazy danych. Kopie zapasowe pliku i grupy plików nie powodowały blokady kopii dziennika. Chociaż komplikowało to proces odzyskiwania kopii zapasowych plików i grup plików, miało zaletę w postaci nieblokowania kopii zapasowych dziennika. W SQL Server 2005 wszystkie pełne i różnicowe kopie zapasowe (niezależnie od komponentu) działają w taki sam sposób. Postępowanie jest teraz takie, że są wykonywane równoczesne kopie zapasowe dziennika, lecz dziennik transakcji nie jest czyszczony, dopóki nie zostanie także zakończona pełna lub różnicowa kopia zapasowa (która wymaga dziennika).

 Do początku strony

Planowanie strategii archiwizacji

Teraz, gdy znane są już trzy typy kopii zapasowych i sposób ich działania, pokażę, jak można je połączyć w strategię archiwizacji.

Zwykle jestem pytany, jak zacząć myśleć o strategii archiwizacji. Zawsze lubię mówić, że nie należy projektować strategii archiwizacji. Trzeba tworzyć strategię przywracania – która sprawia, że w przypadku awarii trzeba odzyskiwać możliwie mało, tak aby przestój był jak najmniejszy, a jednocześnie dane były nadal chronione. Kiedy to zostanie opracowane, wtedy trzeba popracować nad tym, jakie kopie zapasowe są potrzebne, aby można było wykonać potrzebne operacje odzyskiwania. Innymi słowy, strategia archiwizacji powinna spełniać wymagania parametrów RTO (Recovery Time Objective – docelowy czas odzyskiwania) oraz RPO (Recovery Point Objective, docelowy punkt odzyskiwania).

Przy strategii, która obejmuje tylko pełne kopie zapasowe, jesteśmy nieco ograniczeni w tym, co możemy zrobić z przywracaniem. Zasadniczo można tylko dokonywać przywracania na czas wykonania każdej pełnej kopii zapasowej, jak na rysunku 2. Jeśli awaria dotyka nas w sobotę o 23:59, tuż przed następną zaplanowaną kopią zapasową, wtedy cała praca od ostatniej pełnej kopii zapasowej może być utracona. Z tego powodu, jeśli trzeba uniknąć utraty danych, a dane nie mogą być ponownie utworzone, dodaje się także kopie zapasowe dziennika, jak pokazano na rysunku 3.

Rysunek 2: Strategia archiwizacji tylko z pełnymi kopiami zapasowymi (Time – Czas, primary – główna, secondary filegroup – drugorzędna grupa plików, File – plik, Log – Dziennik, Sunday – Niedziela; Full backup – Pełna kopia zapasowa).

Rysunek 3: Strategia archiwizacji z pełnymi kopiami zapasowymi i kopiami zapasowymi dziennika.

Dziennik transakcji (T log)

Wyobraźmy sobie, że kopie zapasowe dziennika są tworzone co 30 minut. Dopóki wszystkie kopie zapasowe są dostępne, oznacza to, że baza danych może być przywrócona do dowolnego punktu w czasie. Nadal jednak może to nie być najlepsza strategia. Co będzie, jeśli przy tak wdrożonej strategii, awaria dotknie nas w sobotę o 23:59? Pierwszą rzeczą byłoby zrobienie kopii zapasowej typu tail-of-the-log, a następnie uruchomienie przywracania.

Przywrócić bazę danych aż do punktu awarii będzie oznaczać przywrócenie pełnej kopii zapasowej z niedzieli oraz 336 kopii zapasowych dziennika (to jest sześć dni po 48 kopii dziennika dziennie, plus 47 w sobotę plus kopia zapasowa tail-of-the-log). Zależnie od tego, ile migracji było w bazie danych przez cały tydzień, rozmiar dziennika transakcji może być ogromny i powtórzenie go zajmie bardzo dużo czasu. Nie jest to oczywiście optymalna strategia przywracania – lecz jest typowa, jak widzę w swojej pracy. Przy takiej strategii trzeba mieć praktykę w dziedzinie przywracania danych i wiedzieć, czy można spełnić wymagania RTO w przypadku awarii.

Aby złagodzić ten problem, w niektórych strategiach stosowane są częstsze pełne kopie zapasowe – lecz może być zbyt wielkie zadanie do wykonywania codziennie. Alternatywą jest zastosowanie różnicowych kopii zapasowych, które zawierają tylko dane zmienione od poprzedniej pełnej kopii zapasowej. Kontynuując ten przykład, taka strategia jest pokazana na rysunku 4.

Rysunek 4: Strategia archiwizacji z pełnymi i różnicowymi kopiami zapasowymi oraz kopiami dziennika.

Przy tej strategii przywracanie po awarii w sobotę o 23:59 jest dużo szybsze. Trzeba pamiętać, że różnicowa kopia zapasowa jest kumulacyjna – więc strategią przywracania jest pełna kopia zapasowa w sobotę, różnicowa kopia zapasowa w sobotę o godzinie 00:00 plus wszystkie kopie zapasowe dzienników z soboty. Posiadanie różnicowej kopii zapasowej z godziny 00:00 z soboty oznacza, że wszystkie kopie zapasowe dziennika przed nią mogą być pominięte, ponieważ różnicowa kopia zapasowa zawiera to samo co wynik netto przywracania wszystkich tych kopii zapasowych dziennika.

To całkiem prosty i naciągany przykład, lecz wyraźnie pokazuje zalety każdego typu kopii zapasowej. Po zaprojektowaniu swojej strategii archiwizacji trzeba ją przetestować, aby mieć pewność, że pozwoli ona wykonać pożądane operacje przywracania.

Oto przykładowa sytuacja, w obliczu której stanął mój klient kilka lat temu. Klient miał uszkodzoną bazę danych i chciał odzyskać ją bez utraty danych. Nie chcieli skorzystać z kopii zapasowych i próbowali uruchomić naprawę na kopii bazy danych, lecz prowadziło to do usunięcia danych, co zmusiło ich do użycia kopii zapasowych. Okazało się, że mieli pełną kopię zapasową ze stycznia plus kopie zapasowe dziennika co pół godziny aż do kwietnia – razem ponad 5 000 kopii zapasowych, a wszystkie zapisane na taśmie! Jestem pewien, że czytając to przewracacie oczami i myślicie „Założę się, że to nie zadziałało", lecz w rzeczywistości podziałało; jednak zrobienie tego zajęło trzy dni! Klient myślał, że ma świetną strategię archiwizacji – model odzyskiwania FULL (pełna kopia) i kopie zapasowe dziennika – lecz ta strategia nie pozwalała na dokonanie przywracania tak, jak chcieli.

 Do początku strony

Integralność kopii zapasowej

Nie ma sensu tworzenie kopii zapasowych, które okażą się uszkodzone, gdy próbujemy przywrócić z nich dane. Oczywiście najlepszą metodą sprawdzenia poprawności swoich kopii zapasowych jest przywrócenie ich na innym serwerze, lecz w SQL Server 2005 została wprowadzona nowa funkcja, która umożliwia sprawdzenie integralności kopii zapasowych bez konieczności rzeczywistego ich przywracania. Przy tworzeniu kopii zapasowej można użyć opcji WITH CHECKSUM (w różnych wariantach).

Powoduje to utworzenie sumy kontrolnej w całym strumieniu kopii zapasowych, która jest przechowywana w samej kopii zapasowej. Jeśli kopia zapasowa jest pełna lub różnicowa, a baza danych ma dostępną stronę sum kontrolnych, wtedy ta opcja będzie także powodować, że wszystkie sumy kontrolne istniejących stron będą testowane podczas czytania stron przez proces archiwizacji. Jeśli zostanie znaleziona zła suma kontrolna strony, operacja tworzenia kopii zapasowej nie powiedzie się. To daje świetną ochronę przed przypadkową archiwizacją bazy danych, która już została w jakiś sposób uszkodzona. (Więcej informacji o sumach kontrolnych strony można znaleźć w artykule „Top Tips for Effective Database Maintenance" z sierpnia 2008).

Po wykonaniu kopii zapasowej można ją zweryfikować, korzystając z poniższego polecenia:

RESTORE VERIFYONLY FROM <urządzenie kopii zapasowej> WITH CHECKSUM

Spowoduje to ponowne obliczenie sumy kontrolnej w całym strumieniu kopii zapasowej i porównanie jej do przechowywanej w kopii zapasowej. Dla pełnych i różnicowych kopii zapasowych zostanie także przetestowana każda suma kontrolna na stronach w kopii zapasowej. Jeśli zostaną znalezione jakieś problemy, wtedy wiemy, że kopia zapasowa została w jakiś sposób uszkodzona.

Naturalnie istnieją wyjątki od tej reguły, gdy chcemy utworzyć kopię zapasową uszkodzonej bazy danych (jeśli jest to jedyna kopia bazy danych, jaką mamy i chcemy na przykład uruchomić naprawę). W tym przypadku można narzucić zakończenie kopii zapasowej za pomocą opcji WITH CONTINUE_AFTER_ERROR.

Więcej informacji na temat sprawdzania poprawności kopii zapasowej można znaleźć na moim blogu, a na drugim zrzucie ekranu towarzyszącym temu artykułowi przedstawiam niektóre aspekty sprawdzania kopii zapasowych.

Podsumowanie

Jak przy każdym skomplikowanym temacie, istnieje dużo obszarów kopii zapasowych, na opis których zabrakło miejsca, lecz teraz po poznaniu podstaw bardziej szczegółowe informacje można znaleźć w łączach do Books Online oraz bloga. Najlepszym miejscem, od którego można zacząć czytanie Books Online, jest temat „Backup Overview (SQL Server)". Na moim blogu można zacząć od Backup/Restore category.

Obszarem, którego brak może zwracać uwagę, jest kompresja kopii zapasowej. Jest to celowe, ponieważ temat ten będzie później omówiony w artykule na temat nowych technologii kompresji w SQL Server 2008. Tymczasem można sprawdzić w Books Online temat „Backup Compression (SQL Server)", a także mój blog.

Gdybym miał podsumować ten artykuł w trzech punktach, byłyby to:

• Sprawdź, czy masz kopie zapasowe.
• Sprawdź, czy masz poprawne kopie zapasowe.
• Sprawdź, czy masz właściwe kopie zapasowe.

Innymi słowy, trzeba robić kopie zapasowe, aby być w stanie przywrócić swoje bazy danych, zrobić coś, aby przekonać się, czy te kopie będą działać w razie potrzeby, i upewnić się, że można je przywrócić z kopii zapasowych oraz spełnić wymagania RTO i RPO.

W następnym artykule wyjaśnię cały temat przywracania z kopii zapasowej, w tym różne rodzaje operacji przywracania i sposób ich działania, przywracanie z wielu kopii zapasowych oraz częściową dostępność bazy danych.

Tymczasem, jak zwykle, wszelkie opinie i pytania można wysyłać do mnie na adres Paul@SQLskills.com.

O autorze

Paul S. Randal jest dyrektorem zarządzającym w SQLskills.com, ma tytuł MVP w obszarze SQL Server oraz jest dyrektorem regionalnym w firmie Microsoft. W latach 1999-2007 pracował w zespole SQL Server Storage Engine w firmie Microsoft. Paul pisał DBCC CHECKDB/repair dla SQL Server 2005 i był odpowiedzialny za Core Storage Engine w czasie projektowania SQL Server 2008. Jest ekspertem od przywracania po awarii, wysokiej dostępności i utrzymania bazy danych, a także jest regularnym prezenterem na konferencjach na całym świecie. Pisze bloga pod adresem SQLskills.com/blogs/paul.

Do początku strony

---