Postgres jest domyślnie instalowany z zestawem narzędzi, wśród których znajduje się między innymi pg_basebackup oraz pg_dump. Oba służą do wykonania kopii klastra. Różnica między nimi polega na tym, że pg_basebackup wykonuje fizyczną kopię, kopiując wszystkie pliki z klastra źródłowego do nowej lokacji, kopia jest identyczna oraz posiada spójne dane z momentu wywołania polecenia. Pg_dump to kopia logiczna, zawierająca instrukcje potrzebne do stworzenia struktury obiektów z klastra źródłowego oraz wszystkie dane zawarte w tabeli w momencie wywołania polecenia. Obie kopie posiadają spójne dane i teoretycznie można z nich odtworzyć taką samą bazę, ale tylko jedna z tych metod może być nazwana kopią zapasową.

Pg_dump to tak naprawdę tylko "obraz" danych z pewnego momentu w czasie. Może mieć wiele zastosowań, ale kopią zapasową nie jest, ponieważ nie umożliwia odtworzenia bazy do wybranego momentu w czasie. Jeżeli w naszych wymaganiach biznesowych mamy zadane jakieś RPO (Recovery Point Objective), a pg_dumpa wykonujemy codziennie, to nasze RPO jest równe 24 godziny. Czyli w najgorszym wypadku możemy stracić cały dzień danych.

Za pomocą pg_basebackup, możemy już stworzyć prawdziwe kopie zapasowe oraz wykonać odtworzenie do wybranego punktu w czasie, jeżeli mamy odpowiednio skonfigurowane parametry archive_command, archive_timeout oraz restore_command. Pozwala nam to osiągnąć RPO na poziomie 1 minuty. Sam proces wymaga też sporo ręcznej pracy, modyfikacji parametrów, kopiowania, etc. Jest sporo miejsca na popełnienie drobnego błędu, który może spowodować, że odtwarzanie bazy nie powiedzie się lub nawet zepsujemy swoją kopię zapasową. Dlatego popularną alternatywą są narzędzia do wykonywania kopii zapasowych, które potrafią wszystkie te operacje wykonać za użytkownika, wydając mu tylko jedno polecenie.

Przyjrzyjmy się teraz bliżej dwóm najpopularniejszym bezpłatnym narzędziom z otwartym źródłem do wykonywania kopii zapasowych dla Postgresa, PgBackRest oraz Barman.

Osobiście preferuję pgBackRest ze względu na możliwość wykonywania kopii przyrostowych oraz różnicowych, szyfrowania plików w repozytorium, współbieżnego archiwizowania plików WAL, backupów z serwerów standby z automatyczną detekcją, które serwery pełnią jaką rolę, co jest bardzo istotne dla Patroni i delta restore na podstawie sum kontrolnych plików, co również przydaje się podczas korzystania z Patroni, oraz możliwość odyskania tylko wybranych baz z klastra, co w przypadku potrzeby odzyskania jednej tabeli z klastra, w którym mamy więcej niż jedną dużą bazę, może bardzo przyspieszyć cały proces.

Barman ma jednak przewagę, kiedy RPO (Recovery Point Objective) jest dla nas bardzo istotne lub kiedy nie mamy możliwości instalacji dodatkowego oprogramowania na serwerze z Postgresem. Umożliwia on konfigurację archiwizacji oraz backupów "strumieniowanych" bez potrzeby instalacji dodatkowego oprogramowania na serwerze bazodanowym. A archiwizacja poprzez strumieniowanie, dzięki temu, że archiwizuje każdy wpis WAL w ten sam sposób jak przy replikacji fizycznej, umożliwia uzyskanie RPO bliskiego zeru.