Blog

Istnieje starsze od węgla porzekadło, że ludzie dzielą się na tych, którzy robią kopie zapasowe i tych, którzy takie kopie będą robić. Dlatego na wstępie darujemy sobie truizmy.

Aby dobrze zrozumieć zasady właściwego backupu bazy danych, zaczniemy od kwestii trudniejszej, czyli odtwarzania bazy danych z kopii. I tutaj już na wstępie pojawia się szereg komplikacji. Zwykle baza danych odzwierciedla logikę biznesową i jako taka posiada stan. W aplikacjach kluczowych z punktu widzenia biznesu zwykle nie jest możliwe przywrócenie bazy do stanu z minionego punktu w czasie. Komplikacje z tym związane, a także katastrofalny cios w PR nie dopuszczają backupu jako rozwiązania zapewniającego ciągłość biznesową. Dlatego też w tym celu stosujemy repliki, zwykle dedykowane tylko do tego celu. Czy oznacza to, że nie należy wykonywać kopii zapasowych baz danych?

Zdecydowanie należy. Wyobraźmy sobie sytuację, w której baza uległa uszkodzeniu na skutek:

1. Błędu w aplikacji – niewyłapanego dostatecznie wczesnie, który zmienił lub usunął część danych.
2. Błędu ludzkiego – w trakcie prac administracyjnych (przypadek z życia wzięty) – pominięcie WHERE w UPDATE w trakcie prac interwencyjnych na dużej bazie danych.
3. Działania zewnętrznego czynnika – na skutek szeroko pojętej kompromitacji bazy danych, czy to za pomocą SQL Injection bądź innych podatności samej aplikacji, czy też poprzez dostęp do systemu operacyjnego serwera bazodanowego lub wskutek ataku MitM.
4. Świadomego działania osoby z wewnątrz – i takie przypadki się zdarzają, zwykle dotyczą jednak pobrania, a nie usunięcia danych.

W części z tych przypadków (takich, które zostały szybko wykryte) możemy posłużyć się mechanizmem kolejnej repliki, która aplikuje zmiany z zadanym opóźnieniem. Opóźnienie to zwykle przyjmuje racjonalne wartości, więc nie obsłuży przypadku, kiedy chcielibyśmy się cofnąć do stanu bazy sprzed 12 godzin lub 3 dni. W tym momencie z pomocą przychodzą kopie zapasowe.

Na wstępie należy zaznaczyć, że w dalszych dywagacjach nie odnosimy się do logicznego zrzutu zawartości baz danych (potocznie dump), niezależnie od jego formatu. Taki zrzut z uwagi na fakt, że jest logiczny, posiada wielokrotnie większą złożoność procesu odtwarzania i z tego powodu nie nadaje się do wykorzystania jako mechanizm wykonywania wiarygodnych kopii zapasowych.

Zatem, jak powstają rzetelne, spójne i skuteczne kopie bazy danych?

Odpowiedzią na powyższe pytanie jest fizyczna kopia zapasowa. Polega ona w bardzo dużym uproszczeniu na powiadomieniu silnika, że będzie backupowany (celem utrzymania konsystencji danych), a następnie fizycznym (stąd nazwa) skopiowaniu plików bazy danych. Taka kopia (jeżeli nie mamy zamiaru jej przewijać – o tym dalej) może zostać uruchomiona natychmiast. Celem odwzorowania zmian pomiędzy stanem bazy z momentu wykonania kopii jej plików a stanem obecnym (lub docelowym), pełna kopia fizyczna musi zostać wzbogacona o logi WAL. Jeżeli zatem mamy pełen obraz bazy danych z soboty, z godziny 12:00 i do tego poprawnie skonfigurowaną archiwizację plików WAL to celem odtworzenia bazy do stanu z poniedziałku z godziny 12:00, odtwarzamy bazę z pełnego backupu i dodatkowo „odtwarzamy” wymagane pliki WAL.

W tym momencie należy uzmysłowić sobie, że zbyt rzadkie pełne backupy owocują bardzo dużą ilością plików WAL do odtworzenia, co z kolei wydłuża proces i może uczynić proces backupu nieskutecznym. Zbyt częste tworzenie pełnych kopii zapasowych nadmiernie obciąża środowisko źródłowe, środowisko kopii zapasowych i infrastrukturę sieciową (wszystkie bloki muszą zostać odczytane po jednej stronie i zapisane po drugiej).

Równie częstym zjawiskiem, aczkolwiek niezależnym od częstotliwości wykonywania pełnych kopii zapasowych, jest brak możliwości wykonania takiej kopii w zadanym czasie (oknie backupowym). W części systemów bazodanowych nie istnieje możliwość jednoznacznego wydzielenia okna serwisowego, dodatkowo komplikuje zagadnienie pełnych kopii fizycznych.

W EuroDB będącym implementacją silnika PostgreSQL, zadania związane z kopiami zapasowymi zostały przeniesione do osobnego modułu odpowiedzialnego za całościowe wykonywanie kopii zapasowych. Szczególnie istotna z punktu widzenia użytkownika jest dostępna funkcja wykonywania przyrostowych kopii zapasowych. Jeżeli baza nie wykazuje się dużą zmiennością (zmienność na poziomie kilku procent w skali 7 dni jest często spotykanym zjawiskiem), to każda pełna kopia w rozwiązaniu tradycyjnym będzie wiązała się z koniecznością zablokowania pełnej ilości przestrzeni dyskowej wykorzystywanej przez instancję, podczas gdy faktyczna ilość unikalnych danych to zaledwie kilka procent całości. W takim przypadku przyrostowe kopie zapasowe pozwalają na zaoszczędzenie miejsca (lub podniesienie ilości pełnych kopii w ramach już zaalokowanej przestrzeni).

Dodatkowo w mocno obciążonych systemach możemy wykonywać dalszą optymalizację backupu poprzez wykonywanie go z repliki (lub archiwum). Możliwe jest również wykorzystanie replikacji logicznej do replikacji części danych i wykonywania kopii zapasowych tego pomniejszonego zbioru danych. Możliwy jest również scenariusz agregacji tabel z różnych baz danych do jednej repliki zagregowanej i wykonywanie kopii zapasowych tylko tej repliki. Aby dowiedzieć się o wszystkich opcjach wydajnego i bezpiecznego mechanizmu backupu lub potrzebujesz wsparcia w tym zakresie, skontaktuj się z nami.