PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

I migliori strumenti di backup per PostgreSQL

PostgreSQL ha la reputazione di essere solido come una roccia sin dai suoi inizi e nel corso degli anni ha accumulato una serie di funzionalità impressionanti. Tuttavia, la tranquillità che i tuoi dati su disco sono compatibili con ACID, se non integrata da una strategia di backup equivalente ben ponderata, può essere facilmente infranta.

Tipi di backup

Prima di approfondire gli strumenti disponibili, diamo un'occhiata ai tipi di backup PostgreSQL disponibili e quali sono le loro caratteristiche:

Dump SQL (o logici)

  • Non blocca lettori o scrittori.
  • Orientato verso piccoli set di dati a causa dell'impatto negativo sul carico del sistema e del lungo tempo richiesto per le operazioni di backup e ripristino. Le prestazioni possono essere aumentate con il flag –no-sync, ma fare riferimento alla pagina man per i rischi associati alla disabilitazione dell'attesa per le scritture.
  • È necessaria un'ANALISI post-ripristino per ottimizzare le statistiche.
  • È possibile eseguire il backup di oggetti globali come ruoli e tablespace solo utilizzando l'utilità pg_dumpall. Nota che le directory tablespace devono essere create manualmente prima di avviare il ripristino.
  • Supporta il parallelismo a scapito di un maggiore carico di sistema. Leggi man pg_dump per i suoi avvertimenti e requisiti speciali, ad es. istantanee sincronizzate.
  • I dump possono essere caricati in versioni più recenti di PostgreSQL, o anche in un'altra architettura di macchina, tuttavia non è garantito che siano compatibili con le versioni precedenti tra le versioni principali, quindi potrebbe essere necessaria una modifica manuale del file di dump.

Filesystem (o fisico)

  • Richiede la chiusura del database.
  • Più veloce dei backup logici.
  • Include i dati del cluster.
  • Può essere ripristinato solo sulla stessa versione principale di PostgreSQL.

Archiviazione continua (o Point In Time Recovery o PITR)

  • Adatto per database molto grandi in cui i backup logici o fisici richiederebbero troppo tempo.
  • Alcune directory all'interno della directory dei dati possono essere escluse per velocizzare il processo.

Istantanee

  • Richiede il supporto del sistema operativo, ad esempio LVM funziona abbastanza bene, il che è confermato anche da NetBackup per PostgreSQL Agent.
  • Adatto per applicazioni in cui sia la directory dei dati che il database devono essere sincronizzati, ad es. applicazioni LAMP, a condizione che le due istantanee siano sincronizzate.
  • Non consigliato quando i file di database sono archiviati su più filesystem (è necessario eseguire lo snapshot di tutti i filesystem contemporaneamente).

Nuvola

Tutti i fornitori di servizi cloud implementano i backup nella loro offerta PostgreSQL. I backup logici possono essere eseguiti come di consueto, mentre i backup fisici e PITR sono disponibili tramite le offerte di servizi cloud poiché l'accesso al datastore non è disponibile (vedi ad esempio Amazon Aurora per PostgreSQL). Pertanto, il backup di PostgreSQL nel cloud dovrà essere un argomento per un altro blog.

Base agenti

  • Richiede un agente installato sulle destinazioni.
  • Può eseguire backup a livello di blocco, ad es. COMMVAULT (installazione supportata solo su Windows).

Caratteristiche

Sebbene PostgreSQL fornisca immediatamente gli strumenti necessari per eseguire backup logici, fisici e PITR, le applicazioni di backup specializzate si basano su PostgreSQL nativo e sugli strumenti del sistema operativo per soddisfare la necessità di implementare una strategia di backup che affronti i seguenti punti:

  • automazione
  • frequenza
  • periodo di conservazione
  • integrità
  • facilità d'uso

Inoltre, gli strumenti di backup di PostgreSQL tentano di fornire funzionalità comuni agli strumenti di backup generici come:

  • backup incrementali per risparmiare spazio di archiviazione
  • backup dei cataloghi
  • possibilità di archiviare i backup in sede o nel cloud
  • avvisi e notifiche
  • Rapporti completi
  • controllo accessi
  • crittografia
  • Interfaccia grafica e dashboard
  • backup di host remoti
  • throughput adattivo per ridurre al minimo il carico sui target
  • gestione di più host in parallelo
  • orchestrazione di backup, ad es. concatenamento di lavori
  • API REST

Impostazione laboratorio

Per questo esercizio ho impostato un host di comando e controllo su cui installerò gli strumenti di backup, che esegue anche due istanze PostgreSQL, 9.6 e 10, installate dai repository 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

Ho anche configurato due istanze PostgreSQL remote che eseguono le stesse versioni 9.6 e rispettivamente 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

Quindi, usa pgbench per creare un set di dati:

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)

Strumenti

Un elenco di strumenti di backup comuni può essere trovato nella sezione Wiki di PostgreSQL — Backup. Ho ampliato l'elenco con i prodotti che ho trovato nel corso degli anni e da una recente ricerca su Internet.

Amanda

Amanda è basato su agenti, open source e supporta PostgreSQL immediatamente tramite l'API ampgsql. Al momento della stesura di questo articolo, la versione 3.5.1 non supporta i tablespace (vedi man ampgsql).

Zmanda fornisce una versione enterprise anch'essa open source, ma non direttamente disponibile per il download come prova.

Amanda richiede un host di backup dedicato poiché i pacchetti server e client si escludono a vicenda:

[[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

Segui la guida alla configurazione di base per configurare il server e il client, quindi configura l'API PostgreSQL.

Ecco un git diff dal mio laboratorio:

  • Server:

    • aumentare lo spazio di backup del server:

      --- 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
				}

      • definire la destinazione PostgreSQL (e disabilitare il backup di esempio):

        --- 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

  • Cliente:

    • configurazione:

      --- /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"

      • file di autenticazione:

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

    • autorizzare il 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

    • Autenticazione 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

    • Configurazione 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

Una volta completata la configurazione di cui sopra, esegui il backup:

[[email protected] ~]$ amdump omiday

E verifica:

[[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)

Il ripristino dal backup prevede più passaggi manuali, come spiegato nella sezione di ripristino.

Secondo le FAQ di Amanda Enterprise, il seguente miglioramento si applicherebbe al nostro esempio PostgreSQL:

  • console di gestione per l'automazione di backup, criteri di conservazione e pianificazioni
  • backup su cloud storage Amazon S3

Barista

Barman è una soluzione di ripristino di emergenza per PostgreSQL gestita da 2ndQuadrant. È progettato per gestire i backup per più database e ha la capacità di ripristinare un punto temporale precedente utilizzando la funzionalità PITR di PostgreSQL.

Le caratteristiche di Barman in sintesi:

  • gestisce più target
  • supporto per diverse versioni di PostgreSQL
  • zero perdita di dati
  • streaming e/o archiviazione standard di WAL
  • Ripristino locale o remoto
  • recupero point-in-time semplificato

Come indicato nel Manuale Barman, il supporto per backup incrementali, lavori paralleli, deduplicazione dei dati e compressione di rete è disponibile solo quando si utilizza l'opzione rsync. Inoltre, lo streaming di WAL da uno standby utilizzando archive_command non è attualmente supportato.

Dopo aver seguito le istruzioni nel manuale per la configurazione dell'ambiente possiamo verificare:

-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

Tutto è a posto, quindi possiamo testare eseguendo il backup dei due host:

-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

Elenca il catalogo di backup:

-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

Visualizzazione dei contenuti per un particolare backup:

-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

Quando Barman è stato configurato per lo streaming WAL sincrono possiamo verificare lo stato della replica:

-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)

Ulteriori miglioramenti possono essere aggiunti utilizzando gli hook script forniti.

Infine, per gli amanti della riga di comando, Barman viene fornito con il completamento completo della TAB.

Strumento di backup e ripristino EDB (BART)

EDB BART è un'applicazione proprietaria closed source fornita da EnterpriseDB. Combina il backup a livello di filesystem nativo di PostgreSQL e PITR in uno strumento facile da usare che fornisce le seguenti caratteristiche:

  • politiche di conservazione
  • backup incrementali
  • backup fisici completi, a caldo, di più server di database Postgres Plus Advanced Server e PostgreSQL
  • gestione del backup e ripristino dei server di database su host locali o remoti
  • Catalogo centralizzato per il backup dei dati
  • Memorizza i dati di backup in formato compresso
  • verifica del checksum

Mentre la versione di prova per l'ultima versione v2.1 può essere ottenuta solo tramite una richiesta di yum repo, l'articolo Backup dei dati reso facile e la guida alla documentazione del prodotto offrono alcune informazioni per chi è curioso di saperne di più.

Scarica il whitepaper oggi Gestione e automazione di PostgreSQL con ClusterControlScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare PostgreSQLScarica il whitepaper

pgBackRest

pgBackRest implementa un backup completo del sistema che non si basa sugli strumenti comuni tar e rsync. Attualmente è ospitato e reso disponibile da CrunchyData con una licenza MIT. Vedi Riconoscimento per i dettagli sulle sue origini.

Offre tutte le funzionalità che ci si aspetterebbe da uno strumento incentrato su PostgreSQL:

  • elevata velocità effettiva di backup/ripristino
  • backup completi, incrementali e differenziali
  • politiche di conservazione
  • verifica dell'integrità del backup e del ripristino tramite checksum dei file e integrazione con i checksum delle pagine di PostgreSQL.
  • possibilità di riprendere i backup
  • compressione in streaming e checksum
  • Supporto per l'archiviazione su cloud di Amazon S3
  • Crittografia

..e altro ancora. Fare riferimento alla pagina del progetto per i dettagli.

L'installazione richiede un sistema Linux/Unix a 64 bit ed è descritta nella guida per l'utente. La guida introduce anche il lettore ai concetti principali, molto utili per chi è nuovo a PostgreSQL o alla tecnologia di archiviazione.

Sebbene la guida utilizzi esempi di comandi per Debian/Ubuntu, pgBackRest è disponibile nel repository PGDG yum e il programma di installazione inserirà tutte le dipendenze:

Installazione:

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

Impostiamo due cluster, pg96 e pg10, ciascuno con un nodo:

  • nodo di controllo ("repository" nella guida):

    [[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

  • gruppo n. 1:

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

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

  • gruppo n. 2:

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

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

Quindi, esegui i backup e visualizza il catalogo dei backup:

-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 supporta la parallelizzazione di backup e ripristino:seguendo l'esempio nella guida, eseguiamo il backup con una CPU e quindi aggiorniamo la configurazione per utilizzare 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

Il risultato:

-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

Con 2 CPU il backup è stato eseguito quasi il 20% più velocemente, il che può fare una grande differenza durante l'esecuzione su un set di dati di grandi dimensioni.

Conclusione

Gli strumenti di backup incentrati su PostgreSQL offrono, come previsto, più opzioni rispetto agli strumenti generici. La maggior parte degli strumenti di backup PostgreSQL offre le stesse funzionalità di base, ma la loro implementazione introduce limitazioni che possono essere scoperte solo seguendo attentamente la documentazione per testare il prodotto.

Inoltre, ClusterControl offre una serie di funzioni di backup e ripristino che puoi utilizzare come parte della configurazione della gestione del database.