Archiwizacja WAL i backupy przyrostowe

Spis treści

1. Co to jest backup przyrostowy?
2. Co to są logi WAL?
3. Archiwizacja WAL
4. Jak łączyć backupy pełne i archiwizację WAL?
5. Odtwarzanie bazy danych z backupu i WAL
6. Zalety backupów przyrostowych z WAL
7. Przykład planu backupu
8. Jak działa polecenie archive_command

Backupy przyrostowe i archiwizacja logów WAL (Write-Ahead Logging) to kluczowe elementy strategii ochrony danych w PostgreSQL. Poniżej wyjaśnię, jak to działa i dlaczego jest to ważne.

1. Co to jest backup przyrostowy?

Backup przyrostowy polega na zapisywaniu tylko zmian danych od ostatniego backupu (pełnego lub przyrostowego), zamiast kopiowania całej bazy danych.
Dzięki temu backupy są mniejsze i szybsze, co pozwala na ich częstsze wykonywanie.

2. Co to są logi WAL?

PostgreSQL używa mechanizmu Write-Ahead Logging (WAL), aby zapewnić trwałość danych i możliwość ich odzyskania po awarii.
Logi WAL zapisują wszystkie operacje modyfikujące dane (INSERT, UPDATE, DELETE) zanim faktyczne zmiany trafią na dysk. Specyfika logów WAL:
- Logi zawierają dane na poziomie niskopoziomowych operacji (np. zmiany stron bazy danych) zamiast operacji SQL.
- Dzięki nim można odtworzyć bazę danych do stanu sprzed awarii, odtwarzając wszystkie zapisane transakcje.

3. Archiwizacja WAL

Archiwizacja logów WAL polega na przenoszeniu ich w bezpieczne miejsce, aby można było je później wykorzystać do przywracania danych.

3.1 Dlaczego archiwizacja logów WAL jest ważna?

Logi WAL pozwalają odtworzyć wszystkie zmiany, które zaszły w bazie danych po wykonaniu ostatniego backupu pełnego.
W przypadku awarii można przywrócić bazę z pełnego backupu i „dograć” zmiany z logów WAL, odtwarzając bazę danych do dowolnego punktu w czasie.

3.2 Jak działa archiwizacja WAL w PostgreSQL?

3.2.1 Włączenie archiwizacji w pliku konfiguracyjnym `postgresql.conf`

archive_mode = on
archive_command = 'cp %p /ścieżka/do/archiwum/%f'

archive_mode = on: Włącza archiwizację.
archive_command: Określa polecenie, które PostgreSQL użyje do kopiowania logów WAL (np. do katalogu lokalnego lub na zdalny serwer).

3.2.2 Rotacja logów WAL

PostgreSQL tworzy nowe pliki WAL w regularnych odstępach czasu lub po zapisaniu określonej ilości danych (domyślnie 16 MB na plik WAL). Te pliki powinny być kopiowane do archiwum w procesie ciągłym.

3.2.3 Częstotliwość archiwizacji

Logi WAL są generowane w czasie rzeczywistym podczas zapisywania transakcji. Kopiowanie logów do archiwum odbywa się automatycznie po zakończeniu zapisu każdego pliku WAL.

4. Jak łączyć backupy pełne i archiwizację WAL?

Strategia backupu:

4.1 Backup pełny

Wykonuj co pewien czas (np. raz dziennie).Tworzy pełną kopię całej bazy danych, która jest punktem odniesienia dla późniejszych odtworzeń.
Przykład polecenia:

pg_basebackup -D /ścieżka/do/backupu -Ft -z -P

-D: Ścieżka docelowa backupu.
-Ft: Format tar.
-z: Kompresja.

4.2 Backupy przyrostowe (WAL)

Archiwizuj logi WAL co 15–30 minut. To pozwala na zminimalizowanie utraty danych w przypadku awarii.

5. Odtwarzanie bazy danych z backupu i WAL

Kroki odtwarzania

5.1 Przywróć pełny backup

tar -xvf full_backup.tar -C /var/lib/postgresql/data

5.2 Skonfiguruj plik `recovery.conf`

W pliku wskaż, gdzie znajdują się logi WAL:

restore_command = 'cp /ścieżka/do/archiwum/%f %p'
recovery_target_time = 'YYYY-MM-DD HH:MM:SS'

restore_command: Określa, jak PostgreSQL ma odczytywać logi WAL z archiwum.
recovery_target_time: Możesz wskazać konkretny punkt w czasie, do którego chcesz odtworzyć bazę.

5.3 Uruchom bazę w trybie odzyskiwania

Po uruchomieniu PostgreSQL odtworzy dane z backupu pełnego i zastosuje zmiany z logów WAL.

6. Zalety backupów przyrostowych z WAL

Minimalna utrata danych:
- Dzięki częstej archiwizacji logów WAL można odtworzyć dane prawie do chwili awarii.
Niskie obciążenie systemu:
- Archiwizacja logów WAL jest mniej zasobożerna niż częste pełne backupy.
Możliwość odzyskania do konkretnego punktu w czasie:
- Dzięki logom WAL można „przewijać” zmiany w bazie i przywrócić ją do dowolnego momentu.

7. Przykład planu backupu

7.1 Backup pełny

Codziennie o godzinie 02:00.

7.2 Kopiowanie backupu do innej lokalizacji

O godzinie 3:00 kopiuj pliki backupowe z serwera do innej lokalizacji.

7.3 Archiwizacja WAL

Co 15 minut przy użyciu archive_command wykonuj archiwizacje plików WAL na dysku

7.4 Kopiowanie plików WAL do innej lokalizacji

Co 2 godziny kopiuj pliki WAL z archiwum na serwerze do innej lokalizacji.

7.6 Minimalizacja utraty danych

Archiwizacja i kopiowanie logów WAL pozwala na tworzenie backupów przyrostowych, które są kluczowe dla minimalizowania utraty danych w PostgreSQL. W połączeniu z regularnymi pełnymi backupami, archiwizacja WAL daje pełną kontrolę nad przywracaniem bazy danych, nawet w przypadku poważnych awarii.

8. Jak działa polecenie `archive_command`

Wyjaśnienie, co w pliku posgresql.conf robi polecenie:

archive_command = 'test ! -f /pgarch/%f && cp %p /pgarch/%f'

To polecenie w pliku konfiguracyjnym PostgreSQL (postgresql.conf) odnosi się do archiwizacji plików WAL (Write-Ahead Log), która jest kluczowym elementem strategii backupu i odzyskiwania danych.

8.1 Składnia i działanie polecenia

test ! -f /pgarch/%f

Sprawdza, czy plik o nazwie %f nie istnieje w katalogu /pgarch/.
test ! -f zwraca sukces (0), jeśli plik nie istnieje.
Jeśli plik już istnieje, dalsza część polecenia nie zostanie wykonana.

&&

Jest to operator logiczny „AND” w powłoce systemowej. Wykonuje drugie polecenie tylko wtedy, gdy pierwsze zakończy się sukcesem.

cp %p /pgarch/%f

Kopiuje plik WAL z bieżącej lokalizacji %p do katalogu /pgarch/ pod nazwą %f.
%p – Pełna ścieżka do pliku WAL generowanego przez PostgreSQL.
%f – Sama nazwa pliku WAL.
Parametry %p i %f są zmiennymi specjalnymi, które PostgreSQL zamienia podczas wykonywania polecenia.

8.2 Podsumowanie działania polecenia

PostgreSQL sprawdza, czy plik WAL o nazwie %f nie istnieje w katalogu /pgarch/.
Jeśli plik nie istnieje, plik WAL jest kopiowany z lokalizacji %p do /pgarch/%f.
Jeśli plik już istnieje, operacja kopii nie jest wykonywana, aby uniknąć nadpisania pliku.

8.3 Cel i zastosowanie

Bezpieczeństwo: Zapobiega nadpisaniu istniejących plików archiwalnych w katalogu /pgarch/.
Archiwizacja WAL: Pozwala na zarchiwizowanie plików WAL, które są niezbędne do przywracania bazy danych do konkretnego punktu w czasie (Point-In-Time Recovery – PITR).
Automatyzacja: archive_command jest częścią funkcji archiwizacji ciągłej PostgreSQL, która automatycznie wykonuje kopię plików WAL.

8.4 Przykład zastosowania polecenia

Plik WAL o nazwie 000000010000000A0000000B zostaje wygenerowany w lokalizacji /var/lib/pgsql/data/pg_wal
PostgreSQL wykonuje:

  test ! -f /var/lib/pgsql/data/pg_wal/000000010000000A0000000B && cp /pgarch/000000010000000A0000000B

Jeśli plik 000000010000000A0000000B nie istnieje w /var/lib/pgsql/data/pg_wal/, jest kopiowany do /pgarch/
Jeśli istnieje, nic się nie dzieje.

8.5 Uwagi

Polecenie cp może być zastąpione innymi metodami przesyłania plików, np. rsync lub scp, jeśli archiwizacja ma odbywać się na innym serwerze.

Katalog /pgarch/ powinien być regularnie monitorowany, aby nie zabrakło miejsca na nowe pliki WAL.

W przypadku problemów z archive_command PostgreSQL może przerwać działanie w trybie archiwizacji, aby nie stracić plików WAL.