PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Principais ferramentas de backup para PostgreSQL


O PostgreSQL tem a reputação de ser sólido desde o início e, ao longo dos anos, acumulou um conjunto de recursos impressionantes. No entanto, a tranquilidade de saber que seus dados em disco são compatíveis com ACID — se não forem complementados por uma estratégia de backup bem pensada equivalente — pode ser facilmente destruída.

Tipos de backup


Antes de mergulhar nas ferramentas disponíveis, vejamos os tipos de backup do PostgreSQL disponíveis e quais são suas características:

Despejos SQL (ou lógicos)

  • Não bloqueia leitores ou escritores.
  • Destinado a pequenos conjuntos de dados devido ao impacto negativo na carga do sistema e ao longo tempo necessário para operações de backup e restauração. O desempenho pode ser aumentado com o sinalizador –no-sync, mas consulte a página de manual para os riscos associados à desativação da espera por gravações.
  • Uma análise pós-restauração é necessária para otimizar as estatísticas.
  • Objetos globais como funções e tablespaces só podem ser copiados usando o utilitário pg_dumpall. Observe que os diretórios de tablespace devem ser criados manualmente antes de iniciar a restauração.
  • Suporta paralelismo à custa do aumento da carga do sistema. Leia man pg_dump para suas advertências e requisitos especiais, por exemplo instantâneos sincronizados.
  • Os dumps podem ser carregados em versões mais recentes do PostgreSQL ou até mesmo em outra arquitetura de máquina, mas não há garantia de que sejam compatíveis com versões anteriores entre as versões principais, portanto, pode ser necessária alguma edição manual do arquivo de dump.

Sistema de arquivos (ou físico)

  • Requer que o banco de dados seja encerrado.
  • Mais rápido que backups lógicos.
  • Inclui dados de cluster.
  • Só pode ser restaurado na mesma versão principal do PostgreSQL.

Arquivamento contínuo (ou recuperação pontual ou PITR)

  • Adequado para bancos de dados muito grandes, onde backups lógicos ou físicos levariam muito tempo.
  • Alguns diretórios dentro do diretório de dados podem ser excluídos para acelerar o processo.

Fotos

  • Requer suporte ao sistema operacional — por exemplo, o LVM funciona muito bem, o que também é confirmado pelo NetBackup for PostgreSQL Agent.
  • Adequado para aplicativos em que o diretório de dados e o banco de dados devem estar sincronizados, por exemplo. Aplicativos LAMP, desde que os dois instantâneos sejam sincronizados.
  • Não recomendado quando os arquivos de banco de dados são armazenados em vários sistemas de arquivos (deve fazer o snapshot de todos os sistemas de arquivos simultaneamente).

Nuvem


Todos os provedores de nuvem implementam backups em sua oferta PostgreSQL. Backups lógicos podem ser executados normalmente, enquanto backups físicos e PITR estão disponíveis por meio das ofertas de serviços em nuvem, pois o acesso ao armazenamento de dados não está disponível (consulte, por exemplo, Amazon Aurora para PostgreSQL). Portanto, fazer backup do PostgreSQL na nuvem precisará ser um tópico para outro blog.

Base de agentes

  • Requer um agente instalado nos destinos.
  • Pode fazer backups em nível de bloco, por exemplo COMMVAULT (instalação suportada apenas no Windows).

Recursos


Enquanto o PostgreSQL fornece as ferramentas necessárias para realizar backups lógicos, físicos e PITR, aplicativos de backup especializados contam com as ferramentas nativas do PostgreSQL e do sistema operacional para preencher a necessidade de implementar uma estratégia de backup que aborde os seguintes pontos:
  • automação
  • frequência
  • período de retenção
  • integridade
  • facilidade de uso

Além disso, as ferramentas de backup do PostgreSQL tentam fornecer recursos comuns às ferramentas de backup genéricas, como:
  • backups incrementais para economizar espaço de armazenamento
  • catálogos de backup
  • capacidade de armazenar backups no local ou na nuvem
  • alerta e notificação
  • relatórios abrangentes
  • controle de acesso
  • criptografia
  • interface gráfica e painéis
  • backups de hosts remotos
  • taxa de transferência adaptável para minimizar a carga nos destinos
  • tratamento de vários hosts em paralelo
  • orquestração de backup, por exemplo encadeamento de tarefas
  • APIs REST

Configuração do laboratório


Para este exercício, configurei um host de comando e controle onde instalarei as ferramentas de backup, que também executa duas instâncias do PostgreSQL — 9.6 e 10 — instaladas a partir de repositórios 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

Também configurei duas instâncias remotas do PostgreSQL executando as mesmas versões 9.6 e 10, respectivamente:
[[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

Em seguida, use o pgbench para criar um conjunto de dados:
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)

Ferramentas


Uma lista de ferramentas de backup comuns pode ser encontrada na seção PostgreSQL Wiki — Backup. Aumentei a lista com produtos que encontrei ao longo dos anos e de uma pesquisa recente na Internet.

Amanda


O Amanda é baseado em agente, de código aberto e suporta PostgreSQL pronto para uso por meio da API ampgsql. Até o momento, a versão 3.5.1 não suporta tablespaces (veja man ampgsql).

O Zmanda fornece uma versão corporativa que também é de código aberto, mas não está disponível diretamente para download como teste.

Amanda requer um host de backup dedicado, pois os pacotes do servidor e do cliente se excluem:
[[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

Siga o guia de configuração básica para configurar o servidor e o cliente e, em seguida, configure a API do PostgreSQL.

Aqui está um git diff do meu laboratório:

  • Servidor:

    • aumentar o espaço de backup do servidor:
      --- 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
				}

      • defina o destino do PostgreSQL (e desative o backup de amostra):
        --- 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:

    • configuração:
      --- /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"

      • arquivo de autenticação:
        --- /dev/null
+++ b/etc/amanda/pg_passfile
@@ -0,0 +1 @@
+/tmp:*:*:amandabackup:pass

    • autorizar o servidor:
      --- 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

    • Autenticação 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

    • Configuração do 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

Depois de concluída a configuração acima, execute o backup:
[[email protected] ~]$ amdump omiday

E verifique:
[[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)

A restauração do backup envolve mais etapas manuais, conforme explicado na seção de restauração.

De acordo com o Amanda Enterprise FAQ, o seguinte aprimoramento se aplicaria ao nosso exemplo do PostgreSQL:
  • console de gerenciamento para automação de backup, políticas de retenção e agendamentos
  • backup para armazenamento em nuvem do Amazon S3

Barman


Barman é uma solução de recuperação de desastres para PostgreSQL mantida pelo 2ndQuadrant. Ele foi projetado para gerenciar backups de vários bancos de dados e tem a capacidade de restaurar para um ponto anterior no tempo usando o recurso PITR do PostgreSQL.

Características de Barman em resumo:
  • lida com vários destinos
  • suporte para diferentes versões do PostgreSQL
  • zero perda de dados
  • streaming e/ou arquivamento padrão de WALs
  • recuperação local ou remota
  • recuperação pontual simplificada

Conforme observado no Manual do Barman, o suporte para backups incrementais, tarefas paralelas, desduplicação de dados e compactação de rede está disponível apenas ao usar a opção rsync. Além disso, o streaming de WALs de um modo de espera usando o archive_command não é compatível no momento.

Após seguir as instruções do manual de configuração do ambiente podemos verificar:
-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

Tudo está correto, então podemos testar fazendo backup dos dois hosts:
-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

Liste o catálogo de 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

Exibindo o conteúdo de um backup específico:
-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 o Barman foi configurado para streaming WAL síncrono, podemos verificar o status da replicação:
-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)

Outras melhorias podem ser adicionadas usando os scripts de gancho fornecidos.

Finalmente, para os amantes da linha de comando, Barman vem com TAB completo.

Ferramenta de Backup e Recuperação EDB (BART)


EDB BART é um aplicativo proprietário de código fechado fornecido pelo EnterpriseDB. Ele combina o backup de nível de sistema de arquivos nativo do PostgreSQL e o PITR em uma ferramenta fácil de usar, fornecendo os seguintes recursos:
  • políticas de retenção
  • backups incrementais
  • backups completos, dinâmicos e físicos de vários servidores de banco de dados Postgres Plus Advanced Server e PostgreSQL
  • gerenciamento de backup e recuperação dos servidores de banco de dados em hosts locais ou remotos
  • catálogo centralizado para dados de backup
  • armazenar dados de backup em formato compactado
  • verificação de soma de verificação

Embora a versão de teste para a versão mais recente v2.1 só possa ser obtida por meio de uma solicitação de repositório do yum, o artigo Data Backup Made Easy e o guia de documentação do produto oferecem algumas informações para quem quiser saber mais.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper

pgBackRest


O pgBackRest implementa um backup completo do sistema que não depende das ferramentas comuns tar e rsync. Atualmente, está hospedado e disponibilizado pela CrunchyData sob uma licença do MIT. Veja Reconhecimento para detalhes sobre suas origens.

Ele oferece todos os recursos que se espera de uma ferramenta centrada no PostgreSQL:
  • alto rendimento de backup/restauração
  • backups completos, incrementais e diferenciais
  • políticas de retenção
  • verificação de integridade de backup e restauração por meio de checksums de arquivos e integração com checksums de página do PostgreSQL.
  • capacidade de retomar backups
  • compressão de streaming e somas de verificação
  • Suporte de armazenamento em nuvem Amazon S3
  • Criptografia

..e muito mais. Consulte a página do projeto para obter detalhes.

A instalação requer um sistema Linux/Unix de 64 bits e está descrita no guia do usuário. O guia também apresenta ao leitor os principais conceitos, muito úteis para quem está iniciando no PostgreSQL ou na tecnologia de armazenamento.

Embora o guia use exemplos de comandos para Debian/Ubuntu, o pgBackRest está disponível no repositório PGDG yum, e o instalador puxará todas as dependências:

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

Vamos configurar dois clusters, pg96 e pg10, cada um com um nó:

  • nó de controle (“repositório” no guia):
    [[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

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

  • agrupamento nº 2:
    [[email protected] ~]# cat /etc/pgbackrest.conf
[global]
log-level-file=detail
repo1-host=repository

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

Em seguida, execute os backups e exiba o catálogo de backups:
-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

O pgBackRest suporta paralelização de backup e restauração — seguindo o exemplo do guia, estamos fazendo backup com uma CPU e, em seguida, atualizamos a configuração para usar 2 CPUs:
--- 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

O resultado:
-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

Com 2 CPUs, o backup foi executado quase 20% mais rápido, o que pode fazer uma grande diferença quando executado em um grande conjunto de dados.

Conclusão


As ferramentas de backup centradas no PostgreSQL oferecem, como esperado, mais opções do que as ferramentas de uso geral. A maioria das ferramentas de backup do PostgreSQL oferece a mesma funcionalidade principal, mas sua implementação apresenta limitações que só podem ser descobertas seguindo cuidadosamente a documentação para testar o produto.

Além disso, o ClusterControl oferece uma variedade de recursos de backup e restauração que você pode usar como parte de sua configuração de gerenciamento de banco de dados.