Celem artykułu jest dogłębne przedstawienie strategii tworzenia i odtwarzania kopii zapasowych wszystkich edycji serwera SQL. W pierwszej części przyjrzymy się kwestiom zapewnienia ciągłej dostępności serwera SQL i jej wpływu na strategie odtwarzania kopii zapasowych. Następnie przeanalizujemy działanie plików danych oraz dzienników transakcyjnych serwera SQL i poznamy zalecenia dotyczące pracy z tymi plikami – to ich nieznajomość jest główną przyczyną błędów popełnianych podczas rozmieszczania danych w plikach i tworzenia kopii zapasowych.
Pierwszą część artykułu kończy obszerny punkt poświęcony tworzeniu kopii zapasowych – dowiesz się z niego nie tylko o tym, w jaki sposób serwer SQL wykonuje kopie zapasowe, ale również jak zaplanować i wdrożyć strategię tworzenia i odtwarzania kopii zapasowych, która zagwarantuje Ci możliwość odtworzenia utraconych danych.
Druga część artykułu, którą opublikujemy wkrótce, poświęcona została metodom automatycznego tworzenia kopii zapasowych, sprawdzania spójności danych, strategiom odtwarzania kopii zapasowych baz danych oraz odtwarzania i przenoszenia serwerów SQL.
Zapewnienie ciągłości pracy serwera SQL
Jedną z wyjątkowych cech serwera SQL firmy Microsoft jest jego uniwersalność. Najprostsza, darmowa edycja SQL Express jest powszechnie używana jako serwer niewielkich aplikacji WWW oraz dołączana do wielu programów firmy Microsoft (w tym do różnych wersji Visual Studio, serwerów Windows Server Update Services czy SharePoint Services) i firm trzecich. Edycja ta jest tak popularna, że działa w prawie każdej firmie, a wiele małych podmiotów przechowuje w niej kluczowe dla swojego działania dane, w tym dane księgowe, magazynowe, historię operacji, dane klientów czy deklaracje ubezpieczeniowe.
Płatne edycje SQL, przede wszystkim edycje Standard i Enterprise, są używane w średnich i dużych przedsiębiorstwach w roli serwerów operacyjnych baz danych (np. w systemach obsługi sprzedaży) oraz jako serwery hurtowni danych i serwery baz analitycznych.
Chociaż serwery SQL firmy Microsoft działają w dużym stopniu automatycznie, to ich administratorzy powinni dbać o zapewnienie ich ciągłej dostępności. W najprostszych wypadkach zadanie to sprowadza się do:
- Zapobiegania awariom, np. poprzez sprawdzanie działania i aktualizowanie zarówno sprzętu, jak i oprogramowania.
- Usuwania skutków ewentualnych awarii, np. poprzez wymianę uszkodzonych podzespołów komputera czy odtworzenie kopii zapasowych baz danych.
- Monitorowania obciążenia i wydajności serwera SQL w zakresie pozwalającym z odpowiednim wyprzedzeniem wykryć i rozwiązać (np. poprzez dołożenie nowego dysku czy rozszerzenie pamięci) problemy, które uniemożliwiłyby użytkownikom pracę z tym serwerem.
Technologie zapewnienia ciągłej dostępności
Dostępność oznacza możliwość skorzystania z usługi zgodnie z jej przeznaczeniem i oczekiwaniami użytkowników, na przykład osoba pracująca z korzystającym z serwera SQL programem Płatnik ma prawo oczekiwać, iż wprowadzone przez nią dane zostaną bezpiecznie zapisane w bazie i że będzie mogła je następnie odczytać. Natomiast ciągła dostępność oznacza, że daną usługą chroniona chroni się przez odpowiednie technologie, np. iż:
- baza danych programu Płatnik jest automatycznie replikowana na zapasowy serwer SQL, czyli że zastosowana została redundancja danych,
- serwer SQL, na którym znajduje się baza danych programu Płatnik, działa na klastrze wysokiej dostępności, a zatem że zastosowana została redundancja usługi.
Technologie zapewnienia ciągłej dostępności, HA (High Availability), choć ściśle powiązane z technologiami usuwania skutków awarii, DR (Disaster Recovery), realizują inne zadania: celem rozwiązań HA jest ochrona przed niedostępnością usługi, rozwiązania DR pozwalają udostępnić usługę po ewentualnej awarii.
Zapewnienie ciągłej dostępności nie sprowadza się do wdrożenia technologii X, ale wymaga ocenienia ryzyka dotyczącego danej usługi, a więc wiedzy biznesowej. Decyzja o zapewnieniu wysokiej dostępności usługi nie może jednak zostać podjęta samodzielnie przez użytkowników biznesowych, czyli przez osoby nieposiadające specjalistycznej, technicznej wiedzy – użytkownicy zawsze chcieliby, żeby wszystkie usługi, z których korzystają, były dostępne przez 100% czasu. Decyzja ta musi więc zostać podjęta wspólnie, przez użytkowników biznesowych i dział IT.
Kontraktem, który gwarantuje użytkownikom ciągłą dostępność usług, jest umowa SLA (Service Level Agreement). Umowa ta jest zawierana pomiędzy usługodawcą (np. działem IT) a usługobiorcą, czyli użytkownikami biznesowymi. Skoro to my odpowiadamy za dotrzymanie warunków umowy SLA, powinniśmy zapewnić sobie możliwość realizacji jej zobowiązań. Dwoma najważniejszymi zobowiązaniami umowy SLA są:
- Nieprzekroczenie maksymalnego czasu niedostępności usługi, RTO (Recovery Time Objective). Najczęściej zobowiązanie RTO przyjmuje formę „liczby dziewiątek”:
a) RTO na poziomie pięciu dziewiątek oznacza, że gwarantujemy dostępność usługi przez 99,999% czasu (w wypadku usługi świadczonej przez 7 dni w tygodniu, 24 godziny na dobę daje to maksymalny czas niedostępności przez 5 minut w ciągu roku),
b) RTO na poziomie czterech dziewiątek oznacza, iż zapewniamy dostępność usługi przez 99,99% czasu (w wypadku usługi świadczonej przez 7 dni w tygodniu, 24 godziny na dobę daje to maksymalny czas niedostępności przez 52 i pół minuty w ciągu roku),
c) RTO na poziomie trzech dziewiątek oznacza, że gwarantujemy dostępność usługi przez 99,9% czasu (w wypadku usługi świadczonej przez 7 dni w tygodniu, 24 godziny na dobę daje to maksymalny czas niedostępności przez 8 godzin i 45 minut w ciągu roku),
d) RTO na poziomie dwóch dziewiątek oznacza, że gwarantujemy dostępność usługi przez 99% czasu (w wypadku usługi świadczonej przez 7 dni w tygodniu, 24 godziny na dobę daje to maksymalny czas niedostępności przez 3 i pół dnia w ciągu roku). - Nieprzekroczenie maksymalnej ilości utraconych w wyniku awarii danych, RPO (Recovery Point Objective). Ilość utraconych danych mierzona jest albo liczbą transakcji, albo czasem, z którego dane mogą zostać utracone (np. RPO może gwarantować, że utracone zostaną co najwyżej dane z 5 minut przed awarią). W wielu przypadkach umowy SLA gwarantują zerowe RPO – zagwarantowanie zerowej utraty danych w wyniku awarii jest znacznie łatwiejsze niż zapewnienie dostępności usługi na poziomie czterech dziewiątek. Co więcej, serwer SQL firmy Microsoft pozwala osiągnąć RPO na poziomie kilkunastu minut bez ponoszenia dodatkowych kosztów.
Wybierając technologie zapewniające ciągłą dostępność, należy kierować się nie tylko kosztem i czasem ich wdrożenia oraz zgodnością z chronioną usługą, ale przede wszystkim możliwością wypełnienia zobowiązań umowy SLA. Ciągła dostępność serwerów SQL firmy Microsoft najczęściej jest zapewniana za pomocą macierzy umożliwiających wykonywanie kopii migawkowych plików, usługi klastrów wysokiej dostępności serwerów Windows i SQL, mechanizmu podwajania bazy danych (Database Mirroring), mechanizmu przesyłania kopii dziennika transakcyjnego (Log Shipping) lub replikacji danych. Omówienie tych technologii wykracza poza zakres artykułu, zainteresowane nimi osoby odsyłam do witryny http://technet.microsoft.com oraz na strony WWW producentów macierzy.
Wdrożone rozwiązania należy następnie przetestować, nie tylko w środowisku testowym, ale również produkcyjnym – awaria może zdarzyć się, gdy w pracy nie będzie doświadczonego administratora, a więc nawet najmniej doświadczona osoba musi być w stanie odpowiednio na nią zareagować. Jednym z błędów, które powszechnie występują w firmach jest nie przeniesienie na serwer zapasowy wszystkich składników usługi (np. znajdujących się w bazie master procedur składowanych, loginów czy zapisanych poza bazą danych plików). O ile doświadczony administrator jest w stanie w krótkim czasie po przełączeniu usługi na zapasowy serwer naprawić taki błąd i udostępnić użytkownikom usługę, to mniej doświadczonej osobie może zająć to kilka godzin, w trakcie których usługa, mimo że chroniona za pomocą odpowiedniej technologii, będzie niedostępna.
Podsumowując: zapewnienie ciągłej dostępności polega na zidentyfikowaniu i wyeliminowaniu (przy użyciu odpowiednich technologii, takich jak replikacja czy klastry) konkretnych zagrożeń związanych z niedostępnością usługi. Takimi zagrożeniami może być awaria serwera aplikacyjnego (np. awaria serwera WWW), awaria serwera SQL, uszkodzenia bazy danych lub utrata danych (np. w wyniku przypadkowego usunięcia tabeli przez administratora lub skasowania danych przez użytkownika).
Strategia tworzenia i odtwarzania kopii zapasowych musi odzwierciedlać ustalone w ramach umowy SLA gwarancje RTO i RPO – zasada ta dotyczy również serwerów SQL niechronionych przez technologie zapewniające ciągłą dostępność. W ich wypadku RTO ustala się najczęściej jako maksymalny czas przywrócenia systemu po awarii, np. RTO równe 2 godziny oznacza, że czas odtwarzania bazy X nie może przekroczyć 2 godzin.
