Najlepsze narzędzia do tworzenia kopii zapasowych dla PostgreSQL

PostgreSQL od samego początku cieszy się opinią solidnego jak skała, a przez lata zgromadził zestaw imponujących funkcji. Jednak spokój ducha, że Twoje dane na dysku są zgodne z kwasem ACID — jeśli nie zostaną uzupełnione równoważną, dobrze przemyślaną strategią tworzenia kopii zapasowych — można łatwo zniszczyć.

Typy kopii zapasowych

Zanim zagłębimy się w dostępne narzędzia, przyjrzyjmy się dostępnym typom kopii zapasowych PostgreSQL i ich cechom:

Zrzuty SQL (lub logiczne)

Nie blokuje czytelników ani pisarzy.
Nastawiony na małe zestawy danych ze względu na negatywny wpływ na obciążenie systemu i długi czas wymagany zarówno do wykonywania operacji tworzenia kopii zapasowych, jak i przywracania. Wydajność można zwiększyć za pomocą flagi –no-sync, ale zapoznaj się ze stroną podręcznika, aby dowiedzieć się o zagrożeniach związanych z wyłączeniem oczekiwania na zapisy.
Analiza po przywróceniu jest wymagana w celu optymalizacji statystyk.
Globalne obiekty, takie jak role i obszary tabel, można tworzyć tylko za pomocą narzędzia pg_dumpall. Pamiętaj, że katalogi obszaru tabel muszą być tworzone ręcznie przed rozpoczęciem przywracania.
Obsługuje równoległość kosztem zwiększonego obciążenia systemu. Przeczytaj man pg_dump, aby poznać jego zastrzeżenia i specjalne wymagania, np. zsynchronizowane migawki.
Zrzuty mogą być ładowane w nowszych wersjach PostgreSQL, a nawet w innej architekturze maszyny, jednak nie ma gwarancji, że będą one kompatybilne wstecz między głównymi wersjami, więc może być wymagana ręczna edycja pliku zrzutu.

System plików (lub fizyczny)

Wymaga zamknięcia bazy danych.
Szybsze niż logiczne kopie zapasowe.
Zawiera dane klastra.
Może być przywrócony tylko w tej samej głównej wersji PostgreSQL.

Ciągła archiwizacja (lub odzyskiwanie punktu w czasie lub PITR)

Nadaje się do bardzo dużych baz danych, w których logiczne lub fizyczne tworzenie kopii zapasowych zajęłoby zbyt dużo czasu.
Niektóre katalogi w katalogu danych można wykluczyć, aby przyspieszyć ten proces.

Migawki

Wymaga obsługi systemu operacyjnego — na przykład LVM działa całkiem dobrze, co potwierdza również NetBackup dla agenta PostgreSQL.
Nadaje się do zastosowań, w których zarówno katalog danych, jak i baza danych muszą być zsynchronizowane, np. Aplikacje LAMP, pod warunkiem, że obie migawki są zsynchronizowane.
Niezalecane, gdy pliki bazy danych są przechowywane w wielu systemach plików (należy wykonać jednocześnie migawkę wszystkich systemów plików).

Chmura

Wszyscy dostawcy usług w chmurze wdrażają kopie zapasowe w swojej ofercie PostgreSQL. Logiczne kopie zapasowe można wykonywać jak zwykle, podczas gdy fizyczne kopie zapasowe i PITR są dostępne za pośrednictwem usług w chmurze, ponieważ dostęp do magazynu danych nie jest dostępny (patrz na przykład Amazon Aurora dla PostgreSQL). Dlatego tworzenie kopii zapasowej PostgreSQL w chmurze będzie musiało być tematem na innym blogu.

Baza agentów

Wymaga agenta zainstalowanego na celach.
Może wykonywać kopie zapasowe na poziomie bloków, np. COMMVAULT (instalacja obsługiwana tylko w systemie Windows).

Funkcje

Podczas gdy PostgreSQL zapewnia gotowe narzędzia wymagane do wykonywania kopii zapasowych logicznych, fizycznych i PITR, wyspecjalizowane aplikacje do tworzenia kopii zapasowych polegają na natywnym PostgreSQL i narzędziach systemu operacyjnego, aby zaspokoić potrzebę wdrożenia strategii tworzenia kopii zapasowych, która uwzględnia następujące punkty:

automatyzacja
częstotliwość
okres przechowywania
uczciwość
łatwość użytkowania

Ponadto narzędzia do tworzenia kopii zapasowych PostgreSQL próbują zapewnić funkcje wspólne dla ogólnych narzędzi do tworzenia kopii zapasowych, takie jak:

przyrostowe kopie zapasowe w celu zaoszczędzenia miejsca
katalogi kopii zapasowych
możliwość przechowywania kopii zapasowych lokalnie lub w chmurze
powiadomienia i powiadomienia
kompleksowe raportowanie
kontrola dostępu
szyfrowanie
interfejs graficzny i pulpity nawigacyjne
kopie zapasowe zdalnych hostów
adaptacyjna przepustowość w celu zminimalizowania obciążenia celów
obsługa wielu hostów równolegle
zapasowa orkiestracja, np. łączenie zadań
Interfejsy API REST

Konfiguracja laboratorium

W tym ćwiczeniu skonfigurowałem hosta dowodzenia i kontroli, na którym będę instalować narzędzia do tworzenia kopii zapasowych, który obsługuje również dwie instancje PostgreSQL — 9.6 i 10 — zainstalowane z repozytoriów PGDG:

[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres  4535     1 /usr/pgsql-10/bin/postmaster -D /var/lib/pgsql/10/data/
postgres  4538  4535  \_ postgres: logger process
postgres  4540  4535  \_ postgres: checkpointer process
postgres  4541  4535  \_ postgres: writer process
postgres  4542  4535  \_ postgres: wal writer process
postgres  4543  4535  \_ postgres: autovacuum launcher process
postgres  4544  4535  \_ postgres: stats collector process
postgres  4545  4535  \_ postgres: bgworker: logical replication launcher
postgres  4481     1 /usr/pgsql-9.6/bin/postmaster -D /var/lib/pgsql/9.6/data/
postgres  4483  4481  \_ postgres: logger process
postgres  4485  4481  \_ postgres: checkpointer process
postgres  4486  4481  \_ postgres: writer process
postgres  4487  4481  \_ postgres: wal writer process
postgres  4488  4481  \_ postgres: autovacuum launcher process
postgres  4489  4481  \_ postgres: stats collector process

[[email protected] ~]# netstat -npeelt | grep :543
tcp   0  0  127.0.0.1:5432  0.0.0.0:*  LISTEN  26  79972  4481/postmaster
tcp   0  0  127.0.0.1:5433  0.0.0.0:*  LISTEN  26  81801  4535/postmaster
tcp6  0  0  ::1:5432        :::*       LISTEN  26  79971  4481/postmaster
tcp6  0  0  ::1:5433        :::*       LISTEN  26  81800  4535/postmaster

Skonfigurowałem również dwie zdalne instancje PostgreSQL z tymi samymi wersjami 9.6 i odpowiednio 10:

[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres 10972     1 /usr/pgsql-9.6/bin/postmaster -D /var/lib/pgsql/9.6/data/
postgres 10975 10972  \_ postgres: logger process
postgres 10977 10972  \_ postgres: checkpointer process
postgres 10978 10972  \_ postgres: writer process
postgres 10979 10972  \_ postgres: wal writer process
postgres 10980 10972  \_ postgres: autovacuum launcher process
postgres 10981 10972  \_ postgres: stats collector process

[[email protected] ~]# netstat -npeelt | grep :5432
tcp   0  0  0.0.0.0:5432  0.0.0.0:*  LISTEN  26  34864  10972/postmaster
tcp6  0  0  :::5432       :::*       LISTEN  26  34865  10972/postmaster


[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres 10829     1 /usr/pgsql-10/bin/postmaster -D /var/lib/pgsql/10/data/
postgres 10831 10829  \_ postgres: logger process
postgres 10833 10829  \_ postgres: checkpointer process
postgres 10834 10829  \_ postgres: writer process
postgres 10835 10829  \_ postgres: wal writer process
postgres 10836 10829  \_ postgres: autovacuum launcher process
postgres 10837 10829  \_ postgres: stats collector process
postgres 10838 10829  \_ postgres: bgworker: logical replication launcher

[[email protected] ~]# netstat -npeelt | grep :5432
tcp   0  0  0.0.0.0:5432  0.0.0.0:*  LISTEN  26  34242  10829/postmaster
tcp6  0  0  :::5432       :::*       LISTEN  26  34243  10829/postmaster

Następnie użyj pgbench, aby utworzyć zestaw danych:

pgbench=# \dt+
                          List of relations
 Schema |       Name       | Type  |  Owner   |  Size   | Description
--------+------------------+-------+----------+---------+-------------
 public | pgbench_accounts | table | postgres | 128 MB  |
 public | pgbench_branches | table | postgres | 40 kB   |
 public | pgbench_history  | table | postgres | 0 bytes |
 public | pgbench_tellers  | table | postgres | 40 kB   |
(4 rows)

Narzędzia

Listę popularnych narzędzi do tworzenia kopii zapasowych można znaleźć w sekcji Wiki PostgreSQL — Kopia zapasowa. Rozszerzyłem listę o produkty, na które natknąłem się przez lata, a także z niedawnego wyszukiwania w Internecie.

Amanda

Amanda jest oparta na agencie, open source i obsługuje PostgreSQL od razu za pośrednictwem interfejsu API ampgsql. W chwili pisania tego tekstu wersja 3.5.1 nie obsługuje przestrzeni tabel (patrz man ampgsql).

Zmanda zapewnia wersję korporacyjną, która jest również open source, ale nie jest bezpośrednio dostępna do pobrania w wersji próbnej.

Amanda wymaga dedykowanego hosta kopii zapasowej, ponieważ pakiety serwera i klienta wykluczają się nawzajem:

[[email protected] ~]# rpm -qp --conflicts ./amanda-backup_client-3.5.1-1.rhel7.x86_64.rpm
amanda-backup_server
[[email protected] ~]# rpm -qp --conflicts ./amanda-backup_server-3.5.1-1.rhel7.x86_64.rpm
amanda-backup_client

Postępuj zgodnie z podstawowym przewodnikiem konfiguracji, aby skonfigurować serwer i klienta, a następnie skonfigurować API PostgreSQL.

Oto git diff z mojego laboratorium:

Serwer:

zwiększyć miejsce na kopie zapasowe serwera:

--- a/etc/amanda/omiday/amanda.conf
				+++ b/etc/amanda/omiday/amanda.conf
				@@ -13,7 +13,7 @@ amrecover_changer "changer"

				tapetype "TEST-TAPE"
				define tapetype TEST-TAPE {
				1.  length 100 mbytes
				2.  length 500 mbytes
					filemark 4 kbytes
				}

zdefiniuj cel PostgreSQL (i wyłącz przykładową kopię zapasową):

--- a/etc/amanda/omiday/disklist
+++ b/etc/amanda/omiday/disklist
@@ -1,3 +1,2 @@
-localhost /etc simple-gnutar-local
+#localhost /etc simple-gnutar-local
+10.1.9.243 /var/lib/pgsql/9.6/data dt_ampgsql

Klient:

konfiguracja:

--- /dev/null
+++ b/etc/amanda/omiday/amanda-client.conf
@@ -0,0 +1,5 @@
+property "PG-DATADIR" "/var/lib/pgsql/9.6/data"
+property "PG-ARCHIVEDIR" "/var/lib/pgsql/9.6/archive"
+property "PG-HOST" "/tmp"
+property "PG-USER" "amandabackup"
+property "PG-PASSFILE" "/etc/amanda/pg_passfile"

plik uwierzytelniający:

--- /dev/null
+++ b/etc/amanda/pg_passfile
@@ -0,0 +1 @@
+/tmp:*:*:amandabackup:pass

autoryzuj serwer:

--- a/var/lib/amanda/.amandahosts
+++ b/var/lib/amanda/.amandahosts
@@ -1,2 +1,3 @@
localhost amandabackup amdump
localhost.localdomain amandabackup amdump
+10.1.9.231 amandabackup amdump

Uwierzytelnianie PostgreSQL:

--- a/var/lib/pgsql/9.6/data/pg_hba.conf
+++ b/var/lib/pgsql/9.6/data/pg_hba.conf
@@ -79,7 +79,8 @@
# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
-host    all             all             127.0.0.1/32            ident
+host    all             all             127.0.0.1/32            trust
+host    all             amandabackup    10.1.9.243/32           trust
# IPv6 local connections:
host    all             all             ::1/128                 ident
# Allow replication connections from localhost, by a user with the

Konfiguracja PostgreSQL:

--- a/var/lib/pgsql/9.6/data/postgresql.conf
+++ b/var/lib/pgsql/9.6/data/postgresql.conf
@@ -178,6 +178,7 @@ dynamic_shared_memory_type = posix  # the default is the first option

#wal_level = minimal                   # minimal, replica, or logical
                                       # (change requires restart)
+wal_level = replica
#fsync = on                            # flush data to disk for crash safety
                                                # (turning this off can cause
                                                # unrecoverable data corruption)
@@ -215,10 +216,12 @@ dynamic_shared_memory_type = posix        # the default is the first option

#archive_mode = off            # enables archiving; off, on, or always
                              # (change requires restart)
+archive_mode = on
#archive_command = ''          # command to use to archive a logfile segment
                              # placeholders: %p = path of file to archive
                              #               %f = file name only
                              # e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
+archive_command = 'test ! -f /var/lib/pgsql/9.6/archive/%f && cp %p /var/lib/pgsql/9.6/archive/%f'
#archive_timeout = 0           # force a logfile segment switch after this
                              # number of seconds; 0 disables

Po zakończeniu powyższej konfiguracji uruchom kopię zapasową:

[[email protected] ~]$ amdump omiday

I zweryfikuj:

[[email protected] ~]$ amreport omiday
Hostname: cc
Org     : omiday
Config  : omiday
Date    : April 14, 2018

These dumps were to tape MyData01.
The next tape Amanda expects to use is: MyData02.


STATISTICS:
                        Total       Full      Incr.   Level:#
                        --------   --------   --------  --------
Estimate Time (hrs:min)     0:00
Run Time (hrs:min)          0:00
Dump Time (hrs:min)         0:00       0:00       0:00
Output Size (meg)            0.1        0.0        0.1
Original Size (meg)         16.0        0.0       16.0
Avg Compressed Size (%)      0.5        --         0.5
DLEs Dumped                    1          0          1  1:1
Avg Dump Rate (k/s)         33.7        --        33.7

Tape Time (hrs:min)         0:00       0:00       0:00
Tape Size (meg)              0.1        0.0        0.1
Tape Used (%)                0.0        0.0        0.0
DLEs Taped                     1          0          1  1:1
Parts Taped                    1          0          1  1:1
Avg Tp Write Rate (k/s)    830.0        --       830.0


USAGE BY TAPE:
Label                 Time         Size      %  DLEs Parts
MyData01              0:00          83K    0.0     1     1


NOTES:
planner: tapecycle (3) <= runspercycle (3)
planner: Last full dump of 10.1.9.243:/var/lib/pgsql/9.6/data on tape MyData04 overwritten in 3 runs.
taper: tape MyData01 kb 83 fm 1 [OK]


DUMP SUMMARY:
                                                               DUMPER STATS   TAPER STATS
HOSTNAME     DISK                    L ORIG-KB  OUT-KB  COMP%  MMM:SS   KB/s MMM:SS   KB/s
-------------------------------------- ---------------------- -------------- -------------
10.1.9.243   /var/lib/pgsql/9.6/data 1   16416      83    0.5    0:02   33.7   0:00  830.0

(brought to you by Amanda version 3.5.1)

Przywracanie z kopii zapasowej obejmuje więcej ręcznych czynności, jak wyjaśniono w sekcji przywracania.

Zgodnie z najczęściej zadawanymi pytaniami dotyczącymi Amanda Enterprise następujące ulepszenie miałoby zastosowanie do naszego przykładu PostgreSQL:

konsola zarządzania do automatyzacji tworzenia kopii zapasowych, zasad przechowywania i harmonogramów
kopia zapasowa w chmurze Amazon S3

Barman

Barman to rozwiązanie do odtwarzania po awarii dla PostgreSQL utrzymywane przez 2ndQuadrant. Jest przeznaczony do zarządzania kopiami zapasowymi wielu baz danych i ma możliwość przywracania do poprzedniego punktu w czasie za pomocą funkcji PITR PostgreSQL.

Funkcje Barmana w skrócie:

obsługuje wiele celów
obsługa różnych wersji PostgreSQL
zero utraty danych
przesyłanie strumieniowe i/lub standardowa archiwizacja WAL
odzyskiwanie lokalne lub zdalne
uproszczone odzyskiwanie punktu w czasie

Jak wspomniano w Podręczniku Barmana, obsługa przyrostowych kopii zapasowych, zadań równoległych, deduplikacji danych i kompresji sieci jest dostępna tylko w przypadku korzystania z opcji rsync. Ponadto strumieniowe przesyłanie plików WAL z trybu gotowości przy użyciu polecenia archive_command nie jest obecnie obsługiwane.

Po wykonaniu instrukcji w instrukcji konfiguracji środowiska możemy zweryfikować:

-bash-4.2$ barman list-server
db1 - master
db2 - replica

-bash-4.2$ barman check db1
Server db1:
      PostgreSQL: OK
      is_superuser: OK
      PostgreSQL streaming: OK
      wal_level: OK
      replication slot: OK
      directories: OK
      retention policy settings: OK
      backup maximum age: OK (no last_backup_maximum_age provided)
      compression settings: OK
      failed backups: OK (there are 0 failed backups)
      minimum redundancy requirements: OK (have 0 backups, expected at least 0)
      pg_basebackup: OK
      pg_basebackup compatible: OK
      pg_basebackup supports tablespaces mapping: OK
      archive_mode: OK
      archive_command: OK
      continuous archiving: OK
      pg_receivexlog: OK
      pg_receivexlog compatible: OK
      receive-wal running: OK
      archiver errors: OK

-bash-4.2$ barman check db2
Server db2:
      PostgreSQL: OK
      is_superuser: OK
      PostgreSQL streaming: OK
      wal_level: OK
      replication slot: OK
      directories: OK
      retention policy settings: OK
      backup maximum age: OK (no last_backup_maximum_age provided)
      compression settings: OK
      failed backups: OK (there are 0 failed backups)
      minimum redundancy requirements: OK (have 0 backups, expected at least 0)
      pg_basebackup: OK
      pg_basebackup compatible: OK
      pg_basebackup supports tablespaces mapping: OK
      archive_mode: OK
      archive_command: OK
      continuous archiving: OK
      pg_receivexlog: OK
      pg_receivexlog compatible: OK
      receive-wal running: OK
      archiver errors: OK

Wszystko jest w porządku, więc możemy przetestować, tworząc kopię zapasową dwóch hostów:

-bash-4.2$ barman backup db1
Starting backup using postgres method for server db1 in /var/lib/barman/db1/base/20180414T091155
Backup start at LSN: 0/240001B0 (000000010000000000000024, 000001B0)
Starting backup copy via pg_basebackup for 20180414T091155
Copy done (time: 2 seconds)
Finalising the backup.
This is the first backup for server db1
WAL segments preceding the current backup have been found:
      000000010000000000000023 from server db1 has been removed
Backup size: 201.9 MiB
Backup end at LSN: 0/26000000 (000000010000000000000025, 00000000)
Backup completed (start time: 2018-04-14 09:11:55.783708, elapsed time: 2 seconds)
Processing xlog segments from file archival for db1
      000000010000000000000023
      000000010000000000000024
      000000010000000000000025.00000028.backup
Processing xlog segments from streaming for db1
      000000010000000000000024

-bash-4.2$ barman backup db2
Starting backup using postgres method for server db2 in /var/lib/barman/db2/base/20180414T091225
Backup start at LSN: 0/B0000D0 (00000001000000000000000B, 000000D0)
Starting backup copy via pg_basebackup for 20180414T091225
Copy done (time: 3 seconds)
Finalising the backup.
This is the first backup for server db2
WAL segments preceding the current backup have been found:
      000000010000000000000009 from server db2 has been removed
      00000001000000000000000A from server db2 has been removed
Backup size: 196.8 MiB
Backup end at LSN: 0/D000000 (00000001000000000000000C, 00000000)
Backup completed (start time: 2018-04-14 09:12:25.619005, elapsed time: 3 seconds)
Processing xlog segments from file archival for db2
      00000001000000000000000B
      00000001000000000000000C.00000028.backup
Processing xlog segments from streaming for db2
      00000001000000000000000B

Wyświetl katalog kopii zapasowych:

-bash-4.2$ barman list-backup all
db1 20180414T091155 - Sat Apr 14 09:11:58 2018 - Size: 217.9 MiB - WAL Size: 0 B
db2 20180414T091225 - Sat Apr 14 09:12:28 2018 - Size: 212.8 MiB - WAL Size: 0 B

Wyświetlanie zawartości określonej kopii zapasowej:

-bash-4.2$ barman list-files db1 20180414T091155 | head
/var/lib/barman/db1/base/20180414T091155/backup.info
/var/lib/barman/db1/base/20180414T091155/data/backup_label
/var/lib/barman/db1/base/20180414T091155/data/PG_VERSION
/var/lib/barman/db1/base/20180414T091155/data/postgresql.auto.conf
/var/lib/barman/db1/base/20180414T091155/data/pg_ident.conf
/var/lib/barman/db1/base/20180414T091155/data/postgresql.conf
/var/lib/barman/db1/base/20180414T091155/data/pg_hba.conf

Gdy Barman został skonfigurowany do synchronicznego przesyłania strumieniowego WAL, możemy zweryfikować stan replikacji:

-bash-4.2$ barman replication-status db1
Status of streaming clients for server 'db1':
Current LSN on master: 0/26000528
Number of streaming clients: 1

1. Async WAL streamer
   Application name: barman_receive_wal
   Sync stage      : 3/3 Remote write
   Communication   : TCP/IP
   IP Address      : 10.1.9.231 / Port: 37278 / Host: -
   User name       : streaming_barman
   Current state   : streaming (async)
   Replication slot: barman
   WAL sender PID  : 2046
   Started at      : 2018-04-14 09:04:03.019323+00:00
   Sent LSN   : 0/26000528 (diff: 0 B)
   Write LSN  : 0/26000528 (diff: 0 B)
   Flush LSN  : 0/26000000 (diff: -1.3 KiB)

Dalsze ulepszenia można dodać za pomocą dostarczonych skryptów przechwytujących.

Wreszcie, dla miłośników linii poleceń, Barman oferuje pełne uzupełnianie TAB.

Narzędzie do tworzenia kopii zapasowych i odzyskiwania EDB (BART)

EDB BART to zastrzeżona aplikacja o zamkniętym kodzie źródłowym dostarczana przez EnterpriseDB. Łączy natywną kopię zapasową na poziomie systemu plików PostgreSQL i PITR w łatwe w użyciu narzędzie zapewniające następujące funkcje:

zasady przechowywania
przyrostowe kopie zapasowe
kompletne, gorące, fizyczne kopie zapasowe wielu serwerów baz danych Postgres Plus Advanced Server i PostgreSQL
zarządzanie kopiami zapasowymi i odzyskiwaniem serwerów baz danych na lokalnych lub zdalnych hostach
scentralizowany katalog danych kopii zapasowych
przechowuj dane kopii zapasowej w skompresowanym formacie
weryfikacja sumy kontrolnej

Chociaż wersję próbną najnowszej wersji v2.1 można uzyskać tylko za pośrednictwem żądania repozytorium yum, artykuł Data Backup Made Easy oraz przewodnik po dokumentacji produktu zawierają informacje dla tych, którzy chcą dowiedzieć się więcej.

Pobierz oficjalny dokument już dziś Zarządzanie i automatyzacja PostgreSQL za pomocą ClusterControlDowiedz się, co musisz wiedzieć, aby wdrażać, monitorować, zarządzać i skalować PostgreSQLPobierz oficjalny dokument

pgBackRest

pgBackRest implementuje pełną kopię zapasową systemu, która nie opiera się na popularnych narzędziach tar i rsync. Obecnie jest hostowany i udostępniany przez CrunchyData na licencji MIT. Zobacz Rozpoznawanie, aby uzyskać szczegółowe informacje na temat jego pochodzenia.

Oferuje wszystkie funkcje, których można oczekiwać od narzędzia zorientowanego na PostgreSQL:

wysoka przepustowość tworzenia kopii zapasowych/przywracania
pełne, przyrostowe i różnicowe kopie zapasowe
zasady przechowywania
Tworzenie kopii zapasowych i weryfikacja integralności przywracania poprzez sumy kontrolne plików i integrację z sumami kontrolnymi stron PostgreSQL.
możliwość wznawiania kopii zapasowych
kompresja strumieniowa i sumy kontrolne
Obsługa przechowywania w chmurze Amazon S3
Szyfrowanie

..i wiele więcej. Szczegółowe informacje można znaleźć na stronie projektu.

Instalacja wymaga 64-bitowego systemu Linux/Unix i jest to opisane w podręczniku użytkownika. Przewodnik wprowadza również czytelnika w główne koncepcje, bardzo przydatne dla nowych użytkowników PostgreSQL lub technologii pamięci masowej.

Chociaż przewodnik używa przykładów poleceń dla Debiana/Ubuntu, pgBackRest jest dostępny w repozytorium PGDG yum, a instalator pobierze wszystkie zależności:

Instalowanie:

pgbackrest       x86_64  2.01-1.rhel7     pgdg10  36k

Installing       for     dependencies:
perl-DBD-Pg      x86_64  2.19.3-4.el7     base    195k
perl-DBI         x86_64  1.627-4.el7      base    802k
perl-Digest-SHA  x86_64  1:5.85-4.el7     base    58k
perl-JSON-PP     noarch  2.27202-2.el7    base    55k
perl-Net-Daemon  noarch  0.48-5.el7       base    51k
perl-PlRPC       noarch  0.2020-14.el7    base    36k
perl-XML-LibXML  x86_64  1:2.0018-5.el7   base    373k
perl-version     x86_64  3:0.99.07-2.el7  base    84k

Skonfigurujmy dwa klastry, pg96 i pg10, z których każdy ma jeden węzeł:

węzeł kontrolny („repozytorium” w przewodniku):

[[email protected] ~]# cat /etc/pgbackrest.conf
[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y

[pg96]
pg1-path=/var/lib/pgsql/9.6/data
pg1-host=db1
pg1-host-user=postgres

[pg10]
pg1-path=/var/lib/pgsql/10/data
pg1-host=db2
pg1-host-user=postgres

klaster nr 1:

[[email protected] ~]# cat /etc/pgbackrest.conf
[global]
log-level-file=detail
repo1-host=repository

[pg96]
pg1-path=/var/lib/pgsql/9.6/data

klaster #2:

[[email protected] ~]# cat /etc/pgbackrest.conf
[global]
log-level-file=detail
repo1-host=repository

[pg10]
pg1-path=/var/lib/pgsql/10/data

Następnie uruchom kopie zapasowe i wyświetl katalog kopii zapasowych:

-bash-4.2$ pgbackrest --stanza=pg96 info
stanza: pg96
   status: ok

   db (current)
      wal archive min/max (9.6-1): 00000001000000000000003D / 00000001000000000000003D

      full backup: 20180414-120727F
            timestamp start/stop: 2018-04-14 12:07:27 / 2018-04-14 12:08:01
            wal start/stop: 00000001000000000000003D / 00000001000000000000003D
            database size: 185.6MB, backup size: 185.6MB
            repository size: 12.1MB, repository backup size: 12.1MB
-bash-4.2$ pgbackrest --stanza=pg10 info
stanza: pg10
   status: ok

   db (current)
      wal archive min/max (10-1): 000000010000000000000012 / 000000010000000000000012

      full backup: 20180414-120810F
            timestamp start/stop: 2018-04-14 12:08:10 / 2018-04-14 12:08:38
            wal start/stop: 000000010000000000000012 / 000000010000000000000012
            database size: 180.5MB, backup size: 180.5MB
            repository size: 11.6MB, repository backup size: 11.6MB

pgBackRest obsługuje równoległe tworzenie kopii zapasowych i przywracanie — zgodnie z przykładem w przewodniku, tworzymy kopię zapasową z jednym procesorem, a następnie aktualizujemy konfigurację, aby korzystać z dwóch procesorów:

--- a/etc/pgbackrest.conf
+++ b/etc/pgbackrest.conf
@@ -2,6 +2,7 @@
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y
+process-max=2

[pg96]
pg1-host=db1

Wynik:

-bash-4.2$ pgbackrest --stanza=pg96 info
stanza: pg96
    status: ok

    db (current)
        wal archive min/max (9.6-1): 00000001000000000000003D / 000000010000000000000041

        full backup: 20180414-120727F
            timestamp start/stop: 2018-04-14 12:07:27 / 2018-04-14 12:08:01
            wal start/stop: 00000001000000000000003D / 00000001000000000000003D
            database size: 185.6MB, backup size: 185.6MB
            repository size: 12.1MB, repository backup size: 12.1MB

        incr backup: 20180414-120727F_20180414-121434I
            timestamp start/stop: 2018-04-14 12:14:34 / 2018-04-14 12:14:52
            wal start/stop: 00000001000000000000003F / 00000001000000000000003F
            database size: 185.6MB, backup size: 8.2KB
            repository size: 12.1MB, repository backup size: 431B
            backup reference list: 20180414-120727F

        incr backup: 20180414-120727F_20180414-121853I
            timestamp start/stop: 2018-04-14 12:18:53 / 2018-04-14 12:19:08
            wal start/stop: 000000010000000000000041 / 000000010000000000000041
            database size: 185.6MB, backup size: 8.2KB
            repository size: 12.1MB, repository backup size: 429B
            backup reference list: 20180414-120727F

Przy dwóch procesorach kopia zapasowa działała prawie o 20% szybciej, co może mieć duże znaczenie podczas pracy z dużym zestawem danych.

Wniosek

Narzędzia do tworzenia kopii zapasowych zorientowane na PostgreSQL oferują, zgodnie z oczekiwaniami, więcej opcji niż narzędzia ogólnego przeznaczenia. Większość narzędzi do tworzenia kopii zapasowych PostgreSQL oferuje tę samą podstawową funkcjonalność, ale ich implementacja wprowadza ograniczenia, które można wykryć tylko poprzez uważne postępowanie zgodnie z dokumentacją w celu przetestowania produktu.

Ponadto ClusterControl oferuje szereg funkcji tworzenia kopii zapasowych i przywracania, których można używać w ramach konfiguracji zarządzania bazą danych.