PostgreSQL má od svých začátků pověst skálopevné a v průběhu let nashromáždil řadu působivých funkcí. Nicméně klid na duši, že vaše data na disku jsou kompatibilní s ACID – pokud nejsou doplněny ekvivalentní promyšlenou strategií zálohování – lze snadno rozbít.
Typy zálohování
Než se ponoříme do dostupných nástrojů, podívejme se na dostupné typy záloh PostgreSQL a jaké jsou jejich vlastnosti:
SQL výpisy (nebo logické)
- Neblokuje čtenáře ani autory.
- Zaměřeno na malé sady dat kvůli negativnímu dopadu na zatížení systému a dlouhé době potřebné pro operace zálohování i obnovy. Výkon lze zvýšit příznakem –no-sync, ale podívejte se na manuálovou stránku, kde najdete rizika spojená s deaktivací čekání na zápisy.
- Aby bylo možné optimalizovat statistiky, je nutné provést po obnovení ANALYZE.
- Globální objekty, jako jsou role a tabulkové prostory, lze zálohovat pouze pomocí nástroje pg_dumpall. Všimněte si, že adresáře tabulkového prostoru musí být vytvořeny ručně před zahájením obnovy.
- Podporuje paralelismus na úkor zvýšeného zatížení systému. Přečtěte si man pg_dump pro jeho upozornění a speciální požadavky, např. synchronizované snímky.
- Výpisy lze načíst v novějších verzích PostgreSQL nebo dokonce v jiné architektuře počítače, není však zaručeno, že budou zpětně kompatibilní mezi hlavními verzemi, takže může být vyžadována ruční úprava souboru výpisu.
Systém souborů (nebo fyzický)
- Vyžaduje vypnutí databáze.
- Rychlejší než logické zálohy.
- Zahrnuje data clusteru.
- Lze obnovit pouze na stejné hlavní verzi PostgreSQL.
Nepřetržitá archivace (nebo Point In Time Recovery nebo PITR)
- Vhodné pro velmi velké databáze, kde by logické nebo fyzické zálohování trvalo příliš dlouho.
- Některé adresáře v datovém adresáři lze vyloučit, aby se proces urychlil.
Snímky
- Vyžaduje podporu operačního systému — například LVM funguje docela dobře, což potvrzuje i NetBackup for PostgreSQL Agent.
- Vhodné pro aplikace, kde musí být datový adresář i databáze synchronizovány, např. aplikace LAMP za předpokladu, že jsou oba snímky synchronizovány.
- Nedoporučuje se, pokud jsou databázové soubory uloženy ve více souborových systémech (musí snímat všechny systémy souborů současně).
Cloud
Všichni poskytovatelé cloudu implementují zálohy do své nabídky PostgreSQL. Logické zálohy lze provádět jako obvykle, zatímco fyzické zálohy a PITR jsou dostupné prostřednictvím nabídky cloudových služeb, protože přístup k datovému úložišti není dostupný (viz například Amazon Aurora pro PostgreSQL). Zálohování PostgreSQL v cloudu proto bude muset být tématem pro jiný blog.
Agentská základna
- Vyžaduje agenta nainstalovaného na cílech.
- Umí provádět zálohy na úrovni bloku, např. COMMVAULT (instalace podporována pouze v systému Windows).
Funkce
Zatímco PostgreSQL poskytuje nástroje potřebné k provádění logických, fyzických a PITR záloh, specializované zálohovací aplikace spoléhají na nativní PostgreSQL a nástroje operačního systému, aby splnily potřebu implementace strategie zálohování, která řeší následující body:
- automatizace
- frekvenci
- doba uchování
- integrita
- snadné použití
Zálohovací nástroje PostgreSQL se navíc pokoušejí poskytovat funkce společné obecným zálohovacím nástrojům, jako jsou:
- přírůstkové zálohy pro úsporu úložného prostoru
- záložní katalogy
- možnost ukládat zálohy na místě nebo v cloudu
- upozornění a upozornění
- komplexní přehledy
- řízení přístupu
- šifrování
- grafické rozhraní a řídicí panely
- zálohy vzdálených hostitelů
- Adaptivní propustnost za účelem minimalizace zatížení cílů
- zvládání více hostitelů paralelně
- záložní orchestrace, např. řetězení pracovních míst
- Rozhraní REST API
Nastavení laboratoře
Pro toto cvičení jsem nastavil hostitele pro příkazy a ovládání, kam budu instalovat nástroje pro zálohování, který také spouští dvě instance PostgreSQL – 9.6 a 10 – nainstalované z repozitářů 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
Také jsem nastavil dvě vzdálené instance PostgreSQL se stejnými verzemi 9.6 a 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
Dále použijte pgbench k vytvoření datové sady:
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)
Nástroje
Seznam běžných zálohovacích nástrojů lze nalézt v PostgreSQL Wiki — Zálohování. Seznam jsem rozšířil o produkty, na které jsem v průběhu let narazil, a z nedávného vyhledávání na internetu.
Amanda
Amanda je založená na agentech, open source a podporuje PostgreSQL přímo z krabice prostřednictvím ampgsql API. V době psaní tohoto článku verze 3.5.1 nepodporuje tabulkové prostory (viz man ampgsql).
Zmanda poskytuje podnikovou verzi, která je také open source, ale není přímo dostupná ke stažení jako zkušební verze.
Amanda vyžaduje vyhrazeného záložního hostitele, protože serverové a klientské balíčky se navzájem vylučují:
[[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
Podle průvodce základní konfigurací nastavte server a klienta a poté nakonfigurujte PostgreSQL API.
Zde je git rozdíl z mé laboratoře:
-
Server:
-
zvětšit zálohovací prostor serveru:
--- 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 }
-
definovat cíl PostgreSQL (a zakázat zálohování vzorku):
--- 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:
-
config:
--- /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"
-
ověřovací soubor:
--- /dev/null +++ b/etc/amanda/pg_passfile @@ -0,0 +1 @@ +/tmp:*:*:amandabackup:pass
-
-
autorizovat server:
--- 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
-
PostgreSQL autentizace:
--- 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
-
Konfigurace 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 dokončení výše uvedené konfigurace spusťte zálohu:
[[email protected] ~]$ amdump omiday
A ověřte:
[[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)
Obnova ze zálohy zahrnuje více ručních kroků, jak je vysvětleno v části obnovení.
Podle Amanda Enterprise FAQ by se na náš příklad PostgreSQL vztahovalo následující vylepšení:
- konzole pro správu pro automatizaci zálohování, zásad uchovávání a plánů
- zálohování do cloudového úložiště Amazon S3
Barman
Barman je řešení pro obnovu po havárii pro PostgreSQL spravované společností 2ndQuadrant. Je navržen pro správu záloh pro více databází a má schopnost obnovit do předchozího bodu v čase pomocí funkce PITR PostgreSQL.
Barmanovy funkce ve zkratce:
- zvládá více cílů
- podpora různých verzí PostgreSQL
- nulová ztráta dat
- streamování a/nebo standardní archivace WAL
- místní nebo vzdálené obnovení
- zjednodušené časové zotavení
Jak je uvedeno v Barman Manual, podpora přírůstkových záloh, paralelních úloh, deduplikace dat a síťové komprese je dostupná pouze při použití možnosti rsync. V současné době také není podporováno streamování WAL z pohotovostního režimu pomocí příkazu archive_command.
Po dodržení pokynů v manuálu pro nastavení prostředí můžeme ověřit:
-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
Vše je v pořádku, takže můžeme testovat zálohováním dvou hostitelů:
-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
Vypište katalog záloh:
-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
Zobrazení obsahu pro konkrétní zálohu:
-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
Když byl Barman nakonfigurován pro synchronní streamování WAL, můžeme ověřit stav replikace:
-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)
Další vylepšení lze přidat pomocí poskytnutých skriptů háku.
A konečně, pro milovníky příkazového řádku přichází Barman s úplným dokončením TAB.
EDB Backup and Recovery Tool (BART)
EDB BART je uzavřená proprietární aplikace poskytovaná EnterpriseDB. Kombinuje PostgreSQL nativní zálohování na úrovni souborového systému a PITR do snadno použitelného nástroje, který poskytuje následující funkce:
- zásady uchovávání
- přírůstkové zálohy
- úplné, horké, fyzické zálohy více serverů Postgres Plus Advanced Server a PostgreSQL databázových serverů
- správa zálohování a obnovy databázových serverů na místních nebo vzdálených hostitelích
- centralizovaný katalog pro zálohování dat
- ukládat zálohovaná data v komprimovaném formátu
- ověření kontrolního součtu
Zatímco zkušební verzi pro nejnovější verzi v2.1 lze získat pouze prostřednictvím požadavku yum repo, článek Zálohování dat je snadné a průvodce dokumentací k produktu nabízí některé informace pro ty, kteří se chtějí dozvědět více.
Stáhněte si Whitepaper Today Správa a automatizace PostgreSQL s ClusterControlZjistěte, co potřebujete vědět k nasazení, monitorování, správě a škálování PostgreSQLStáhněte si WhitepaperpgBackRest
pgBackRest implementuje úplnou zálohu systému, která se nespoléhá na běžné nástroje tar a rsync. V současné době je hostován a zpřístupněn společností CrunchyData pod licencí MIT. Podrobnosti o jeho původu naleznete v části Rozpoznávání.
Nabízí všechny funkce, které lze očekávat od nástroje zaměřeného na PostgreSQL:
- vysoká propustnost zálohování/obnovy
- úplné, přírůstkové a rozdílové zálohy
- zásady uchovávání
- zálohování a obnovení ověření integrity prostřednictvím kontrolních součtů souborů a integrace s kontrolními součty stránek PostgreSQL.
- možnost obnovení zálohování
- komprese streamování a kontrolní součty
- Podpora cloudového úložiště Amazon S3
- Šifrování
..a mnohem víc. Podrobnosti najdete na stránce projektu.
Instalace vyžaduje 64bitový systém Linux/Unix a je popsána v uživatelské příručce. Průvodce také seznamuje čtenáře s hlavními koncepty, které jsou velmi užitečné pro ty, kdo začínají s PostgreSQL nebo technologií úložiště.
Přestože příručka používá příklady příkazů pro Debian/Ubuntu, pgBackRest je k dispozici v úložišti PGDG yum a instalační program stáhne všechny závislosti:
Instalace:
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
Pojďme nastavit dva clustery, pg96 a pg10, z nichž každý má jeden uzel:
-
řídicí uzel („úložiště“ v průvodci):
[[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
-
cluster #1:
[[email protected] ~]# cat /etc/pgbackrest.conf [global] log-level-file=detail repo1-host=repository [pg96] pg1-path=/var/lib/pgsql/9.6/data
-
cluster #2:
[[email protected] ~]# cat /etc/pgbackrest.conf [global] log-level-file=detail repo1-host=repository [pg10] pg1-path=/var/lib/pgsql/10/data
Dále spusťte zálohy a zobrazte katalog záloh:
-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 podporuje paralelizaci zálohování a obnovy — podle příkladu v průvodci zálohujeme s jedním CPU a poté aktualizujeme konfiguraci, aby používala 2 CPU:
--- 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
Výsledek:
-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
Se 2 procesory zálohování běželo téměř o 20 % rychleji, což může znamenat velký rozdíl při běhu proti velkému souboru dat.
Závěr
Centrální zálohovací nástroje PostgreSQL nabízejí podle očekávání více možností než nástroje pro obecné použití. Většina zálohovacích nástrojů PostgreSQL nabízí stejnou základní funkcionalitu, ale jejich implementace přináší omezení, která lze zjistit pouze pečlivým sledováním dokumentace za účelem testování produktu.
ClusterControl navíc nabízí řadu funkcí zálohování a obnovy, které můžete použít jako součást nastavení správy databáze.