Popularne relacyjne bazy danych Postgres to obok Oracle Database i Microsoft SQL Server najchętniej wybierane narzędzie do zarządzania danymi w firmie. Warto zadbać o odpowiednie bezpieczeństwo swoich informacji firmowych. Powinniśmy zastanowić się, czy zrzut bazy danych to dobry pomysł. O tym opowiadam w poniższym artykule, sprawdzając, na czym polega kopia zapasowa i przywracanie bazy danych PostgreSQL.
Kopia zapasowa i przywracanie bazy danych PostgreSQL – o co chodzi?
W przypadku systemów zarządzania bazami danych, kopie zapasowe często tworzy się na podstawie sugestii administratora bazy. Okazuje się jednak, że wielokrotnie brakuje odpowiedniej strategii tworzenia kopii. Tymczasem to właśnie dzięki umiejętnemu planowaniu można zapewnić sobie najwyższej klasy bezpieczeństwo danych w bazie.
Oprogramowanie bazodanowe PostgreSQL zostało zaprojektowane w taki sposób, by admin mógł zaplanować eksport oraz import wersji bazy. Mając to na uwadze, możemy przejść do dalszej części, gdzie zajmiemy się omówieniem praktyki kopiowania i odtwarzania danych.
Dziennik logów WAL i opóźnione repliki baz
Istnieje sporo firm, gdzie polityka bezpieczeństwa przekłada się na comiesięczne tworzenie backupu. Co dzieje się w przypadku, gdy ostatnia kopia powstała 29 dni temu, a w bazie nastąpił błąd? Jeżeli nastąpi utrata danych, należy wówczas przywrócić najbliższą czasowo kopię. Co ciekawe, utracone tabele można spróbować odzyskać dzięki skopiowanym plikom dziennika logów Write Ahead Logs (WAL).
Pliki WAL to dosłownie dzienniki zapisu z wyprzedzeniem. Oznacza to, że można przejść wprzód z miejsca, gdzie wykonano backup. Posiadając skopiowane pliki WAL nawet po utracie tabeli można odzyskać część utraconych informacji.
Nawet, jeżeli masz już spory zbiór kopii danych w bazie, warto utrzymywać strategię backupu według planu. W związku z tym, warto sprawdzić, jak działa konfiguracja PostgreSQL pod kątem backupów.
Jak skonfigurować bazę Postgres pod kątem WAL?
Trzeba przyznać, że PostgreSQL to świetnie zaprojektowany jeśli mówimy o implementacji logów transakcyjnych i architekturę procesów. Pliki WAL są tutaj jednym z najważniejszych elementów całego ekosystemu. Zapisuje się je w katalogach pg_xlog / pg_wal.
Wszelkie zmiany, jakie wykonuje się w obrębie pracy bazy, są zapisywane w obszarze WAL. PostgreSQL zapisuje wektory zmian cyklicznie po plikach WAL. Gdy zapisze każdy z nich, zaczyna ponownie nadpisując pierwszy plik WAL.
Pliki te mają ogromne znaczenie w przypadku późniejszego odtwarzania bazy z kopii. Dlatego też warto dokonywać ich archiwizacji. Parametry potrzebne do tego zmienić można w pliku postgresql.conf, zaś archive_mode posiada tylko trzy wartości:
- On (włącz)
- Off (wyłącz)
- Always (zawsze)
Pomiędzy wartościami „on” i „always” nie ma dużej różnicy – ta pierwsza archiwizuje pliki tylko, gdy serwer jest włączony. Z kolei druga opcja jest za to dodatkowo archiwizuje gdy PostgreSQL jest w trybie odtworzenia.
Jak to wszystko ma się do odzyskiwania bazy w przypadku błędu i utraty danych? Przywracanie bazy danych PostgreSQL jest bezpośrednio połączone z faktem przechowywania plików WAL. Gdy uruchamiamy bazę po odtworzeniu z pełnego backup, dążyć ona będzie do uzyskania stanu spójności. Robi to pobierając informacje na temat zmian, właśnie z archiwizowanych plików WAL.
Przywracanie bazy danych PostgreSQL z punktu w czasie
Istnieje również inny sposób, jak przywrócić bazę danych PostgreSQL, lecz tym razem dotyczy odczytu z punktu w czasie. Point in Time Recovery (PITR) wykorzystuje pojęcie parametru recovery_target_time, który odnosi się do konkretnego czasu sprzed awarii bazy. Korzystając z tej techniki, można odzyskać więcej danych, jeżeli również archiwa WAL funkcjonują od momentu bazowego backupu.
Jeszcze raz warto przypomnieć o plikach WAL, które także w tym przypadku stanowią podstawę tworzenia kopii zapasowych i przywracania baz. Stąd też należy przechowywać folder plików pg_xlog/pg_wal i nie usuwać manualnie żadnych elementów w nim się znajdujących, by odzyskać przestrzeń dyskową.
System operacyjny pozwala wykonać kopię zapasową na kilka sposobów. Można tego dokonać w sposób logiczny lub fizyczny, a dostępne opcje prezentują się następująco:
- Backup logiczny:
- pg_dump
- pg_dumpall
- Backup fizyczny:
- Zrzuty systemu plików
- pg_basebackup
- Ręczna kopia zapasowa bazy
Jeżeli chcesz poznać PostgreSQL w praktyce i rozszerzyć swoje kompetencje w IT, sprawdź Kurs PostgreSQL! Ponad 600 zadowolonych studentów!
Strategie przywracania bazy danych
Czas backupu zależy od wybranej przez admina metody zapisu kopii, a także jej rozmiaru. Warto również zwrócić uwagę na fakt, iż fizyczny backup zajmuje więcej przestrzeni, niż jego logiczny odpowiednik. Z punktu w czasie można odtworzyć następujące elementy:
- Pojedyncza tabela – najszybszą metodą odzyskania informacji będzie użycie pg_dump lub pg_dumpall. Odtwarzanie tabel działa sprawnie i szybko, a także daje większą elastyczność w wyszukiwaniu konkretnych rekordów.
- Pojedyncza baza danych – w tym przypadku również warto wykorzystać pg_dump albo pg_dumpall. Przywracanie obejmuje pojedyncze pliki SQL uruchamiające polecenie COPY w back-endzie. Można też zastosować techniki dostrajania zapytań, aby zmaksymalizować wydajność.
- Cały klaster – można również odtworzyć cały klaster, który składa się z wielu baz i rozszerzeń. Przydatnym okaże się wówczas wykorzystanie backupu fizycznego. Wystarczy wtedy wskazać odpowiedni katalog danych i nie trzeba wykonywać dodatkowej pracy manualnej.
Należy jednak nadmienić, że backup logiczny musi za wczasu zostać zrobiony w odpowiednim punkcie w czasie. Jest to nic innego jak zrzut danych z bazy „na daną chwile”. Backup fizyczny w połączeniu z archiwalnymi plikami WAL, pozwala dowolnie wybierać sobie datę i godzinę do których chcemy się odtworzyć.
Zarządzanie tworzeniem kopii i przywracaniem bazy danych PostgreSQL
Jeśli jeszcze tego nie robiłeś, powinieneś zdecydować się utworzyć kopię zapasową swojej relacyjnej bazy danych PSQL. Często powtarza się, że warto przechowywać wiele backup PostgreSQL. Dla przykładu przy backup wykonywanym co tydzień, warto trzymać kopie zapasowe na kilka miesięcy wstecz. Zarządzanie wieloma kopiami pozwala na łatwiejsze przywrócenie danych, które najbardziej nas interesują.
Problem z kopiami może pojawić się, gdy zobaczymy rozmiar tabel i danych do skopiowania. Dlatego na koniec warto rzucić nieco światła na obsługę różnych wielkości backupów:
- Rozmiar bazy do 100 GB: mniejsze bazy potrzebują znacznie krótszego czasu, by stworzyć backup i go odzyskać. Dlatego też warto wykorzystać zarówno logiczne, jak i fizyczne metody zapisu. Dzięki temu uzyskasz większą swobodę decyzji i sprawniej odtworzysz pożądaną wersję bazy.
- Rozmiar bazy między 100 a 500 GB: wciąż warto skorzystać z obu opcji. Jeżeli jednak musisz wybierać, wtedy lepiej sięgnąć po fizyczną kopię. Da Ci to nieco więcej elastyczności w kontekście przywrócenia dowolnych tabel i baz danych sprzed awarii, przy zachowaniu lepszej wydajności operacji backup/restore.
- Rozmiar bazy powyżej 500 GB: w tym momencie korzystanie z logicznej kopii staje się nieco bardziej skomplikowane. W związku z tym lepiej będzie skorzystać z fizycznego zapisu backupu, co pozwala na szybsze odzyskiwanie bazy w przypadku awarii.
Pamiętaj, że backup nie musi być domyślny, więc masz większą swobodę wyboru najlepszej metody zapisu kopii. Zaplanuj odpowiednią strategię backupu serwera bazy danych, by ułatwić sobie późniejsze przywracanie bazy danych PostgreSQL. Jeśli chcesz wiedzieć więcej, zapisz się już dziś na kurs Postgres!