🥇Przewodnik po tworzeniu kopii zapasowych baz danych

– O, żadne schronienie nie wytrzyma uderzenia meteorytu. Ale jak każdy, macie zapas, więc nie musicie się martwić.
Stanisław Lem, „Dzienniki gwiazdowe Ijona Tichnego”

Kopie zapasowe to zapisanie kopii danych w miejscu innym niż główne miejsce ich przechowywania.

Głównym celem tworzenia kopii zapasowych jest przywracanie danych po ich utracie. W związku z tym często słychać, że posiadanie repliki bazy danych pozwala zawsze na odzyskanie danych i kopie zapasowe są niepotrzebne. W rzeczywistości kopie zapasowe pozwalają rozwiązać co najmniej trzy problemy, które nie mogą być rozwiązane za pomocą repliki, a samą replikę bez kopii zapasowej nie można zainicjować.

Po pierwsze, kopia zapasowa umożliwia przywrócenie danych po błędzie logicznym. Na przykład, księgowy usunął grupę zapisów lub administrator bazy danych zlikwidował przestrzeń tabeli. Obie operacje są absolutnie legitymne z punktu widzenia bazy danych, a proces replikacji powieli je w bazie-repliki.

Po drugie, nowoczesne systemy zarządzania bazami danych to bardzo niezawodne pakiety oprogramowania, jednak czasami dochodzi do uszkodzenia wewnętrznych struktur bazy danych, po którym dostęp do danych zostaje utracony. Co gorsza, takie uszkodzenie zazwyczaj występuje przy dużym obciążeniu lub przy instalacji jakiejś aktualizacji. Ale zarówno duże obciążenie, jak i regularne aktualizacje świadczą, że baza danych jest z pewnością używana, a przechowywane w niej dane są cenne.

Ostatecznie trzecim problemem, którego rozwiązanie wymaga posiadania kopii zapasowej, jest klonowanie bazy, na przykład w celach testowych.

Kopie zapasowe baz danych w mniejszym lub większym stopniu opierają się na jednej z dwóch zasad:

Wyodrębnienie danych z późniejszym zapisaniem w dowolnym formacie;
Zrzut stanu plików bazy danych i zachowanie dzienników.

Przyjrzyjmy się tym zasadom i narzędziom je realizującym bardziej szczegółowo.

Eksport danych

W zestawie narzędzi towarzyszących każdemu systemowi zarządzania bazą danych znajdują się narzędzia do eksportu i importu danych. Dane są zapisywane w formacie tekstowym lub w formacie binarnym, specyficznym dla danego systemu zarządzania bazą danych. W poniższej tabeli znajduje się lista takich narzędzi:

Format binarny
Format tekstowy

Oracle
DataPump Export/DataPump Import
Eksport/Import
SQL*Plus/SQL*Loader

PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql

Microsoft SQL Server
bcp
bcp

DB2
wyładunek/ładowanie
wyładunek/ładowanie

MySQL

mysqldump, mysqlpump/mysql, mysqlimport

MongoDB
mongodump/mongorestore
mongoexport/mongoimport

Cassandra
nodetool snapshot/sstableloader
cqlsh

Format tekstowy ma tę zaletę, że można go edytować lub tworzyć za pomocą zewnętrznych programów, a format binarny z kolei jest dobry, ponieważ pozwala szybciej eksportować i importować dane dzięki oszczędności zasobów na konwersję formatów.

Mimo prostoty i oczywistości idei exportu danych, w przypadku zapełnionych przemysłowych baz danych taki sposób rzadko jest stosowany. Oto powody, dla których eksport nie nadaje się do pełnoprawnego tworzenia kopii zapasowych:

proces wyładunku generuje znaczne obciążenie systemu źródłowego;
eksport zajmuje dużo czasu – w momencie ukończenia eksportu, dane mogą stać się już nieaktualne;
wykonanie spójnego eksportu całej bazy danych przy dużym obciążeniu jest praktycznie niemożliwe, ponieważ SGBD musi zachować migawkę swojego stanu w momencie rozpoczęcia eksportu. Im więcej transakcji zostało wykonanych od momentu rozpoczęcia eksportu, tym większy wolumen migawki (nieaktualnych kopii danych w PostgreSQL, przestrzeni undo w Oracle, tempdb w Microsoft SQL Server itp.);
eksport zachowuje logiczną strukturę danych, ale nie zachowuje ich fizycznej struktury – parametry fizycznego przechowywania tabel, indeksy i inne.

Niemniej jednak, eksport ma także swoje zalety:

wysoka selektywność: można wyeksportować pojedyncze tabele, pojedyncze pola, a nawet pojedyncze wiersze;
wyeksportowane dane można załadować do bazy danych innej wersji, a jeśli eksport odbył się w formacie tekstowym, to również do innej bazy danych.

W ten sposób eksport jest głównie stosowany w takich zadaniach jak tworzenie kopii zapasowych małych tabel (na przykład słowników) lub dystrybucja zestawów danych z kolejną wersją aplikacji.

Najczęściej stosowaną metodą tworzenia kopii zapasowych baz danych jest kopiowanie plików bazy.

«Zimne» zapisywanie plików bazy danych

Oczywista idea – zatrzymać bazę danych i skopiować wszystkie jej pliki. Taka kopia zapasowa nazywana jest «zimną». Metoda ta jest niezwykle niezawodna i prosta, ale ma dwa oczywiste wady:

Z "zimnej" kopii zapasowej można przywrócić jedynie to, co było w bazie danych w momencie zatrzymania; transakcje wykonane po ponownym uruchomieniu bazy nie będą uwzględnione w "zimnej" kopii zapasowej;
Nie każda baza danych ma okno technologiczne, w którym można ją zatrzymać.

Jeśli jednak "zimna" kopia zapasowa Ci odpowiada, musisz pamiętać, że

"zimna" kopia czasami powinna obejmować również dzienniki. Metody określania dzienników, które powinny trafić do "zimnej" kopii, są indywidualne dla każdej SGBD. Na przykład w Oracle należy skopiować tzw. online redo, czyli określoną liczbę plików dziennika w specjalnym katalogu, nawet gdy baza jest poprawnie zatrzymana. W PostgreSQL należy zachować wszystkie dzienniki począwszy od dziennika zawierającego ostatni punkt kontrolny, który jest zawarty w pliku sterującym.
Katalog bazy danych może zawierać dość duże pliki tymczasowych przestrzeni tabel, które nie muszą być uwzględniane w kopii zapasowej. Nawiasem mówiąc, to spostrzeżenie jest też prawdziwe w przypadku "gorącego" tworzenia kopii zapasowych.

"Gorące" zapisywanie plików

Większość kopii zapasowych nowoczesnych baz danych wykonywana jest poprzez kopiowanie plików bazy danych bez zatrzymywania bazy. W tym przypadku pojawia się kilka problemów:

W momencie rozpoczęcia kopiowania zawartość bazy danych może nie zgadzać się z zawartością plików, ponieważ część informacji znajduje się w pamięci podręcznej i jeszcze nie została zapisana na dysku.
Podczas kopiowania zawartość bazy może się zmieniać. Jeśli używane są zmieniane struktury danych, zawartość plików się zmienia, a przy użyciu niezmiennych struktur zmienia się zestaw plików: nowe pliki się pojawiają, a stare są usuwane.
Ponieważ zapis danych w bazie i odczyt plików bazy danych nie są w żaden sposób zsynchronizowane, program tworzący kopię zapasową może odczytać niepoprawną stronę, w której połowa będzie pochodzić ze starej wersji strony, a druga połowa – z nowej.

Aby kopia zapasowa okazała się spójna, każda SGBD ma polecenie, które informuje, że rozpoczęto proces tworzenia kopii zapasowej. Składniowo to polecenie może wyglądać różnie:

W Oracle to osobne polecenie ALTER DATABASE/TABLESPACE BEGIN BACKUP;
W PostgreSQL – funkcja pg_start_backup();
W Microsoft SQL Server i DB2 przygotowanie do tworzenia kopii zapasowej odbywa się niejawnie podczas wykonywania polecenia BACKUP DATABASE;
W MySQL Enterprise, Cassandra i MongoDB przygotowanie odbywa się niejawnie za pomocą zewnętrznych narzędzi – mysqlbackup, OpsCenter i Ops Manager odpowiednio.

Mimo różnic w składni, proces przygotowania do tworzenia kopii zapasowej wygląda identycznie.

Oto jak wygląda przygotowanie do tworzenia kopii zapasowej w systemach DBMS z zmiennymi strukturami dyskowymi, tzn. we wszystkich tradycyjnych relacyjnych systemach dyskowych:

Zapisywany jest moment rozpoczęcia tworzenia kopii zapasowej; kopia zapasowa będzie zawierać dzienniki bazy danych zaczynając od tego momentu.
Wykonywana jest kontrolna punktacja, co oznacza, że wszystkie zmiany, które zaszły w stronach danych przed zapamiętanym momentem, są zapisywane na dysku. To gwarantuje, że dzienniki do momentu rozpoczęcia tworzenia kopii zapasowej nie będą potrzebne przy odzyskiwaniu.
Włączany jest szczególny tryb rejestrowania: jeśli strona danych zmienia się po raz pierwszy po załadowaniu z dysku, zamiast zapisywać w dzienniku zmiany strony, baza zapisuje tam całą stronę. Podczas wykonywania procedury przygotowawczej wszystkie strony są wypychane na dysk, więc przy pierwszej zmianie blok zawsze zostanie zapisany w dzienniku w całości. Ale jeśli podczas tworzenia kopii zapasowej strona zostanie ponownie wypchnięta na dysk, to następująca jej zmiana również spowoduje pojawienie się w dzienniku pełnej kopii strony. To gwarantuje, że jeśli podczas kopiowania pliku z danymi strona stanie się nieprawidłowa, zastosowanie dziennika przywróci ją do poprawności.
Blokowane są zmiany w nagłówkach plików danych, co oznacza, że ta część, której zmiany nie są odzwierciedlane w dziennikach, nie podlega modyfikacji. To zapewnia, że nagłówek będzie poprawnie skopiowany, a później do pliku danych prawidłowo zastosowane będą dzienniki.

Po wykonaniu wszystkich wymienionych powyżej procedur można kopiować pliki danych z wykorzystaniem systemu operacyjnego – cp, rsync i innych. Włączenie trybu tworzenia kopii zapasowej obniża wydajność bazy danych: po pierwsze, zwiększa się objętość dzienników, a po drugie, jeśli wystąpi awaria podczas tworzenia kopii zapasowej, przywracanie zajmie więcej czasu, ponieważ nagłówki plików danych nie są aktualizowane. Im szybciej zakończy się tworzenie kopii zapasowej, tym lepiej dla bazy danych, dlatego stosowanie takich narzędzi jak zrzut (snapshot) systemu plików lub przerwanie lustra (BCV) w macierzy dyskowej jest uzasadnione. Niektóre systemy baz danych (Oracle, PostgreSQL) dają administratorowi możliwość samodzielnego wyboru metody kopiowania, inne (Microsoft SQL Server) oferują interfejs do integracji własnych narzędzi do tworzenia kopii zapasowych z mechanizmami systemów plików lub macierzy dyskowych.

Po zakończeniu tworzenia kopii zapasowej należy przywrócić bazę danych do normalnego stanu. W Oracle robi się to poleceniem ALTER DATABASE/TABLESPACE END BACKUP, w PostgreSQL – wywołując funkcję pg_stop_backup(), a w innych bazach – wewnętrznymi podprogramami odpowiednich poleceń lub zewnętrznych usług.

Oto jak wygląda tymczasowa diagram procesu tworzenia kopii zapasowej:

Przygotowanie do tworzenia kopii zapasowej (begin backup) zajmuje czas, czasami znaczny. Nawet jeśli używane są lustrzane wolumeny lub systemy plików z możliwością tworzenia zrzutów, proces tworzenia kopii zapasowej nie będzie natychmiastowy.
Wraz z plikami danych należy zachować dzienniki, zaczynając od momentu rozpoczęcia przygotowań do tworzenia kopii zapasowej i kończąc w momencie przywracania bazy do normalnego stanu.
Można przywrócić się z tej kopii zapasowej w momencie przywracania bazy do normalnego stanu. Przywrócenie do wcześniejszego momentu nie jest możliwe.

W przypadku baz danych wykorzystujących niezmienne struktury danych (zrzuty pamięci, drzewa LSM) sytuacja jest prostsza. Przygotowanie do tworzenia kopii zapasowej składa się z następujących kroków:

Dane z pamięci są zapisywane na dysku.
Zostaje zarejestrowana lista plików, które trafiają do kopii zapasowej. Dopóki proces tworzenia kopii zapasowej nie zostanie zakończony, bazie zabrania się usuwania tych plików, nawet jeśli stają się niepotrzebne.

Po sygnale o zakończeniu tworzenia kopii zapasowej, baza z niezmiennymi strukturami może ponownie usunąć zbędne pliki.

Przywracanie do punktu

Tworzenie kopii zapasowej umożliwia przywrócenie stanu bazy danych do momentu, w którym zakończono polecenie powrotu z trybu kopii zapasowej. Jednak awaria, po której może być konieczne przywrócenie, może zdarzyć się w dowolnym momencie. Zadanie przywracania stanu bazy danych do dowolnego momentu nazywa się „przywracaniem do punktu” (point-in-time recovery).

Aby zapewnić taką możliwość, należy zachować dzienniki bazy danych od momentu zakończenia tworzenia kopii zapasowej, a w trakcie przywracania kontynuować stosowanie dzienników do przywróconej kopii. Po tym, jak baza danych zostanie przywrócona z kopii do momentu zakończenia kopiowania, stan bazy (plików i pamięci podręcznej) jest gwarantowane poprawny, dlatego specjalny tryb dziennikowania nie jest potrzebny. Stosując dzienniki do odpowiedniego momentu, można uzyskać stan bazy danych na dowolny punkt w czasie.

Jeśli szybkość przywracania kopii zapasowej jest ograniczona jedynie przepustowością dysku, to szybkość stosowania dzienników jest zazwyczaj ograniczona wydajnością procesora. Jeśli w głównej bazie danych zmiany zachodzą równolegle, to podczas przywracania wszystkie zmiany są wykonywane sekwencyjnie - w kolejności odczytu z dziennika. W ten sposób czas przywracania jest liniowo zależny od tego, jak daleko punkt przywracania jest od punktu zakończenia tworzenia kopii zapasowej. Z tego powodu trzeba dość często robić pełne kopie zapasowe - przynajmniej raz w tygodniu dla baz z niewielkim obciążeniem transakcyjnym i do codziennego kopiowania dla baz o wysokim obciążeniu.

Przyrostowe tworzenie kopii zapasowych

Aby przyspieszyć przywracanie do punktu, chciałoby się mieć możliwość wykonywania tworzenia kopii zapasowych jak najczęściej, ale jednocześnie nie zajmować zbyt dużo miejsca na dyskach i nie obciążać bazy zadaniami tworzenia kopii zapasowych.

Rozwiązaniem problemu jest przyrostowe tworzenie kopii zapasowych, czyli kopiowanie tylko tych stron danych, które zmieniły się od ostatniego tworzenia kopii zapasowej.
Kopie przyrostowe są sensowne tylko dla baz danych, które używają zmiennych struktur danych.

Przyrost może być liczony zarówno od pełnej kopii zapasowej (kopii skumulowanej), jak i od dowolnej poprzedniej kopii (kopii różnicowej).

Niestety, nie ma jednolitej terminologii, a różni producenci używają różnych terminów:

Różnicowa
Skumulowana

Oracle
Różnicowa
Skumulowana

PostgresPro
Przyrostowa
—

Microsoft SQL Server
—
Różnicowa

IBM DB2
Delta
Przyrostowa

W przypadku posiadania kopii przyrostowych proces przywracania do punktu wygląda następująco:

przywracana jest ostatnia pełna kopia zapasowa, wykonana przed momentem przywracania;
na pełnej kopii przywracane są kopie przyrostowe;
nakładane są dzienniki od momentu rozpoczęcia tworzenia kopii zapasowej do punktu przywracania.

Posiadanie kopii skumulowanej przyspiesza proces przywracania. Na przykład, aby przywrócić stan bazy do punktu między T3 a T4, należy przywrócić dwie kopie przyrostowe, a aby przywrócić do punktu po T4 – tylko jedną.
Oczywiście objętość jednej kopii skumulowanej jest mniejsza niż objętość kilku kopii różnicowych, ponieważ niektóre strony zmieniły się wielokrotnie, a każda kopia przyrostowa zawiera swoją wersję strony.

Istnieją trzy sposoby tworzenia kopii przyrostowej:

tworzenie pełnej kopii i obliczanie różnicy z poprzednią pełną kopią;
analiza dzienników, tworzenie listy zmienionych stron i rezerwowanie stron, które zostały uwzględnione w liście;
zapytanie o zmienione strony w bazie danych.

Pierwszy sposób oszczędza miejsce na dysku, ale nie rozwiązuje problemu zmniejszenia obciążenia bazy danych. Co więcej, jeśli mamy pełną kopię zapasową, to przekształcanie jej w kopię przyrostową jest bezsensowne, ponieważ przywrócenie pełnej kopii jest szybsze niż przywracanie poprzedniej pełnej kopii i przyrostów. Problem oszczędności miejsca na dysku lepiej przekazać specjalnym komponentom z wbudowanymi mechanizmami deduplikacji. Mogą to być zarówno specjalne systemy pamięci masowej (EMC DataDomain, HPE StorageWorks VLS, cała linia NetApp), jak i produkty programowe (ZFS, Veritas NetBackup PureFile, deduplikacja danych systemu Windows Server).

Drugi i trzeci sposób różnią się mechanizmem określania listy zmienionych stron. Analiza dzienników jest bardziej zasobożerna, a ponadto do jej realizacji należy znać strukturę plików dziennika. Najprościej jest zapytać samą bazę danych, które strony się zmieniły, ale do tego jądro DBMS musi mieć funkcjonalność śledzenia zmienionych bloków (block change tracking).

Funkcjonalność inkrementalnego tworzenia kopii zapasowych została po raz pierwszy wprowadzona w oprogramowaniu Oracle Recovery Manager (RMAN), które pojawiło się w wersji Oracle 8i. Oracle od razu zaimplementował śledzenie zmienionych bloków, więc nie ma potrzeby analizy dzienników.

PostgreSQL nie śledzi zmienionych bloków, dlatego narzędzie pg_probackup, opracowane przez rosyjską firmę Postgres Professional, określa zmienione strony poprzez analizę dziennika. Jednak firma dostarcza również DBMS PostgresPro, która zawiera rozszerzenie ptrack śledzące zmiany stron. Przy użyciu pg_probackup z DBMS PostgresPro narzędzie pyta o zmienione strony samą bazę – dokładnie tak, jak RMAN.

Microsoft SQL Server, podobnie jak Oracle, śledzi zmienione strony, ale polecenie BACKUP pozwala na tworzenie tylko pełnych i kumulacyjnych kopii zapasowych.

W DB2 istnieje możliwość śledzenia zmienionych stron, ale domyślnie jest ona wyłączona. Po włączeniu DB2 umożliwia tworzenie pełnych, różnicowych i kumulacyjnych kopii zapasowych.

Waźną różnicą między opisanymi w tej sekcji narzędziami (z wyjątkiem pg_probackup) a plikowymi narzędziami tworzenia kopii zapasowych jest to, że pytają one o obrazy stron bezpośrednio z bazy danych, a nie odczytują danych z dysku samodzielnie. Wadą takiego podejścia jest niewielkie obciążenie bazy danych. Jednak ta wada jest w pełni rekompensowana tym, że przeczytana strona zawsze jest poprawna, dlatego nie ma potrzeby włączania specjalnego trybu dziennika podczas tworzenia kopii zapasowej.

Jeszcze raz zwracamy uwagę, że obecność inkrementalnych kopii zapasowych nie zwalnia z wymogu posiadania dzienników do przywracania do dowolnego momentu w czasie. Dlatego w systemach baz danych dzienniki są stale zapisywane na zewnętrznych nośnikach, a kopie zapasowe, pełne i/lub inkrementalne, są tworzone zgodnie z harmonogramem.

Najlepszą realizacją idei inkrementalnego tworzenia kopii zapasowych jest kompleks sprzętowo-programowy (w terminologii Oracle – engineered system) Zero Data Loss Recovery Appliance – specjalistyczne rozwiązanie Oracle do tworzenia kopii zapasowych własnej bazy danych. Kompleks stanowi klaster serwerów z dużym wolumenem dysków, na które zainstalowana jest zmodyfikowana wersja oprogramowania Recovery Manager i może pracować zarówno z innymi kompleksami sprzętowo-programowymi Oracle (Database Appliance, Exadata, SPARC Supercluster), jak i z bazami Oracle w tradycyjnej infrastrukturze. W przeciwieństwie do „zwykłego” RMAN, w ZDLRA wdrożona jest koncepcja „wiecznego inkrementu” (incremental forever). System tworzy jednokrotnie pełną kopię bazy danych, a następnie wykonuje jedynie kopie inkrementalne. Dodatkowe moduły RMAN umożliwiają łączenie kopii, tworząc nowe pełne kopie z inkrementalnych.

Na cześć rosyjskich programistów należy zauważyć, że pg_probackup również potrafi łączyć kopie inkrementalne.

W przeciwieństwie do wielu podobnych pytań, pytanie „jaka metoda tworzenia kopii zapasowych jest najlepsza” ma jednoznaczną odpowiedź – najlepiej używana jest natywna dla danej bazy danych narzędzie, które zapewnia możliwość tworzenia kopii inkrementalnych.

Dla administratora bazy danych znacznie ważniejsze są kwestie wyboru strategii tworzenia kopii zapasowych oraz integracja narzędzi do tworzenia kopii zapasowych z infrastrukturą korporacyjną. Jednak te pytania wykraczają poza ramy tego artykułu.

Źródło: habr.com