W dzisiejszych czasach, efektywne zarządzanie danymi i zapewnienie im bezpieczeństwa jest najważniejsze dla każdej organizacji. Backupy są fundamentem każdej strategii ochrony danych, oferując różne poziomy ochrony i efektywności. W kontekście baz danych PostgreSQL, narzędzie pgBackRest wyróżnia się jako potężne i wszechstronne rozwiązanie do tworzenia i zarządzania kopiami zapasowymi.
pgBackRest zapewnia zaawansowane funkcje, takie jak kompresja, szyfrowanie, replikacja i zarządzanie retencją, które są niezbędne do utrzymania integralności i dostępności danych. Jednym z najbardziej efektywnych sposobów przechowywania backupów jest wykorzystanie zewnętrznych woluminów podmontowanych do maszyny, co pozwala na elastyczne zarządzanie przestrzenią dyskową i ułatwia przenoszenie danych między różnymi środowiskami.
PostgreSQL Backup – krok po kroku
W tym artykule przeprowadzę krok po kroku proces konfiguracji pgBackRest do tworzenia backupów pełnych i różnicowych na zewnętrznym woluminie utworzonym w DigitalOcean. Omówię konfigurację narzędzia, proces montowania zewnętrznego woluminu oraz najlepsze praktyki związane z zarządzaniem kopiami zapasowymi. Dzięki temu przewodnikowi będziesz w stanie skutecznie zabezpieczyć swoje dane i zapewnić ciągłość działania swojej bazy danych PostgreSQL, niezależnie od ewentualnych awarii czy innych nieprzewidzianych zdarzeń.
PostgreSQL Backup – zewnętrzny wolumin
Domyślnie utworzony wolumin, który w panelu jest dołączony do danej instancji maszyny również automatycznie się podmontowuje w systemie plików. Woluminy dzięki konfiguracji systemd i udev są automatycznie zamontowane po restarcie maszyny i nie trzeba modyfikować w tym celu /etc/fstab. Dodatkowe informacje w dokumentacji.
Instalacja i konfiguracja pgBackRest oraz tworzenie PostgreSQL Backup
1. Instalacja pgbackrest:
2. Konfiguracja w pliku /etc/pgbackrest.conf:
process-max – liczba równoległych procesów tworzących backup. Główny cel – przyspieszenie tworzenia backupu. Dostosuj do liczby rdzeni procesora.
repo1-block – dane backupu są przechowywane jako seria bloków danych zamiast jako pełne pliki. Umożliwia to bardziej efektywne zarządzanie danymi, w tym deduplikację i przywracanie tylko zmienionych bloków danych.
repo1-bundle – pliki backupu są grupowane i pakowane razem. Może to poprawić wydajność operacji I/O, zwłaszcza w przypadku systemów plików, które lepiej radzą sobie z mniejszą liczbą większych plików niż z dużą liczbą małych plików.
repo1-path – ścieżka do katalogu, w którym będą przechowywane backupy, wymaga uprawnień 750 i postgres:postgres na katalog pg_backup
repo1-retention-full – przechowywanie danej ilości backupów pełnych
repo1-retention-diff – przechowywanie danej ilości backupów różnicowych
start-fast – nie czeka na utworzenie checkpointa tylko go wymusza i uruchamia backup. najważniejsze w środowiskach produkcyjnych, gdzie minimalizacja czasu wykonania backupu jest krytyczna dla utrzymania wysokiej dostępności systemu.
pg1-path – ścieżka do katalogu danych postgresa
compress-level – poziom kompresji archiwizacji
archive-timeout – ustawia maksymalny czas, w sekundach, oczekiwania na dotarcie każdego segmentu WAL do repozytorium archiwum pgBackRest. Domyślnie jest to 60s. Modyfikuj tylko wtedy, gdy widzisz timeout w pliku dziennika związanym z archiwizacją wal.
3. Konfiguracja w /etc/postgresql/12/main/postgresql.conf:
archive_command – polecenie wykonywane przez PostgreSQL do archiwizacji WAL. W tym przykładzie “%p” jest specjalnym tokenem używanym w PostgreSQL, który oznacza pełną ścieżkę do pliku WAL (Write-Ahead Log), który ma zostać zarchiwizowany.
archive_mode – włączenie trybu archiwizacji.
max_wal_senders – maksymalna liczba procesów wysyłających WAL.
wal_level – poziom zapisywanych danych WAL – minimum, logical, replica.
max_wal_size i min_wal_size – maksymalny i minimalny rozmiar segmentów WAL.
4. Restart klastra:
5. Inicjalizacja “stanzy” z poziomu użytkownika postgres i sprawdzenie konfiguracji:
6. Utwórz kopie zapasowe – użyj odpowiedniej kombinacji (w opisywanym przypadku wybrałem pełną i różnicową):
7. Sprawdzenie statusu backupów:
8. Utworzenie wpisu w tablicy crona na koncie użytkownika postgres:
9. Utworzenie plików backup_diff i backup_full wraz z odpowiednimi uprawnieniami:
PostgreSQL – Przywracanie danych
Tutaj na chwilę musimy się zatrzymać, ponieważ są trzy podejścia związane z odzyskiwaniem danych. Pierwsze z nich uwzględnia usunięcie danych z katalogu /var/lib/postgresql/12/main, a drugie nie. Trzecie to Point-in-Time Recovery lub PITR. Jaka jest różnica i którą opcję wybrać?
Pierwszy, klasyczny sposób wymaga pustego katalogu klastra przed uruchomieniem opcji odzyskiwania.
Drugi sposób to użycie parametru “- -delta”, który nie wymaga pustego katalogu klastra. Polega on na przywróceniu tylko tych plików, które zostały zmienione. Obliczana jest funkcja skrótu sha-1 dla wszystkich pliku w klastrze i jeżeli różni się ona od tej dla danego pliku w backupie, to wtedy taki plik jest przywracany. Jest to jasno napisane w dokumentacji w pkt. 10.2 “Delta option”.
Trzeci to Point in-time recovery. PITR umożliwia odtworzenie WAL z kopii zapasowej do określonego lsn, czasu, identyfikatora transakcji lub punktu odzyskiwania. W przypadku typowych scenariuszy odzyskiwania odzyskiwanie oparte na czasie jest prawdopodobnie najbardziej przydatne. Typowym scenariuszem odzyskiwania jest przywrócenie tabeli, która została przypadkowo usunięta lub danych, które zostały przypadkowo usunięte.
Dodatkowo warto użyć opcji process-max=X, gdzie za X można spróbować podstawić liczbę rdzeni procesora. W momencie odzyskiwania z backupu klaster postgresa jest wyłączony, więc maszyna ma dodatkowe zasoby. Poza tym zależy nam na jak najszybszym przywróceniem jego pełnej sprawności.
Pierwszy sposób: Usunięcie danych z katalogu /var/lib/postgresql/12/main
1. Zatrzymać klaster:
2. Skasować zawartość z katalogu z danymi:
3. Uruchomić polecenie do odzyskiwania:
4. Uruchomić klaster:
5. Weryfikacja działania klastra:
Drugi sposób: Użycie parametru “delta”
1. Zatrzymać klaster:
2. Uruchomić polecenie do odzyskiwania z parametrem “- -delta”:
4. Uruchomić klaster:
5. Weryfikacja działania klastra:
Trzeci sposób: PITR
1. Należy sprawdzić w logach postgresql, jaki jest czas wystąpienia awarii. Im dokładniejszy czas, tym lepiej.
2. Zatrzymaj klaster:
3. Uruchom polecenie, aby odzyskać dane:
type – określa typ przywracania. “time” oznacza, iż przywracanie zostanie wykonane do określonego punktu w czasie (timestamp).
target – określa dokładny punkt w czasie, do którego baza danych ma zostać przywrócona. Używany format z pliku loga postgresql.
target-action – określa akcję, która zostanie podjęta po osiągnięciu punktu przywracania. “promote” oznacza, iż po przywróceniu do określonego punktu w czasie, baza danych zostanie awansowana do roli podstawowej. To kończy proces przywracania i sprawia, iż baza danych jest gotowa do użycia.
4. Uruchomić klaster:
5. Weryfikacja działania klastra:
PostgreSQL Backup – Której opcji użyć?
Klasycznie “to zależy”. Na pewno należy zwrócić uwagę na kilka kwestii:
1. Mnogość zmian w danych
Jeśli katalog danych zawiera większość aktualnych danych i tylko niewielka część plików została zmieniona lub uszkodzona, użycie “delta” pozwoli na szybsze przywrócenie kopii, ponieważ zostaną przywrócone tylko zmienione pliki.
2. Wielkość bazy danych
Duża baza danych, np. kilkaset GB, może spowodować, iż usunięcie i pełne przywrócenie zajęłoby za dużo czasu.
3. Czas przestoju
Jeśli czas przestoju musi być zminimalizowany “delta” może skrócić czas potrzebny na przywracanie danych.
Natomiast każdy przypadek należy rozpatrywać indywidualnie i testować – jaka opcja będzie najlepsza.
Podsumowanie
W artykule zawarłem instrukcję, jak skonfigurować i użyć narzędzia pgbackrest, aby móc zadbać o zautomatyzowane sprawne tworzenie kopii zapasowej i przywracanie z niej bazy danych.
Więcej zdecydowanie ciekawych/użytecznych informacji w dokumentacji → https://pgbackrest.org/user-guide.html
Lista dostępnych poleceń narzędzia pgBackRest → https://pgbackrest.org/command.html
Informacje dotyczące konfiguracji w /etc/pgbackrest.conf → https://pgbackrest.org/configuration.html
Autor
Piotr Bracha — pracuje jako administrator systemów. Karierę zaczynał jako młodszy administrator systemów w call center, gdzie miał m.in. możliwość poznania administrowania systemem CentOS i centralą telefoniczną Asterisk. w tej chwili rozwija się w technologiach kontenerowych i chmurowych. Fan automatyzacji i porządku – w kodzie, ale też w środowisku pracy. Artykuły autorstwa Piotra w języku angielskim znajdziesz w serwisie medium.com.
