sql >> Base de Datos >  >> RDS >> PostgreSQL

Principales herramientas de copia de seguridad para PostgreSQL

PostgreSQL tiene la reputación de ser sólido como una roca desde sus inicios y, a lo largo de los años, ha acumulado un conjunto de características impresionantes. Sin embargo, la tranquilidad de saber que sus datos en disco son compatibles con ACID, si no se complementa con una estrategia de copia de seguridad bien pensada equivalente, puede hacerse añicos fácilmente.

Tipos de copia de seguridad

Antes de sumergirnos en las herramientas disponibles, veamos los tipos de copias de seguridad de PostgreSQL disponibles y cuáles son sus características:

Volcados SQL (o lógicos)

  • No bloquea lectores ni escritores.
  • Dirigido a pequeños conjuntos de datos debido al impacto negativo en la carga del sistema y el largo tiempo requerido para las operaciones de copia de seguridad y restauración. El rendimiento se puede aumentar con el indicador –no-sync, pero consulte la página del manual para conocer los riesgos asociados con la desactivación de la espera de escritura.
  • Se requiere un ANÁLISIS posterior a la restauración para optimizar las estadísticas.
  • Los objetos globales, como funciones y espacios de tabla, solo se pueden respaldar mediante la utilidad pg_dumpall. Tenga en cuenta que los directorios de espacios de tabla deben crearse manualmente antes de iniciar la restauración.
  • Admite paralelismo a expensas de una mayor carga del sistema. Lea man pg_dump para conocer sus advertencias y requisitos especiales, p. instantáneas sincronizadas.
  • Los volcados se pueden cargar en versiones más recientes de PostgreSQL, o incluso en otra arquitectura de máquina, sin embargo, no se garantiza que sean compatibles con versiones anteriores, por lo que es posible que se requiera alguna edición manual del archivo de volcado.

Sistema de archivos (o físico)

  • Requiere que se cierre la base de datos.
  • Más rápido que las copias de seguridad lógicas.
  • Incluye datos de clúster.
  • Solo se puede restaurar en la misma versión principal de PostgreSQL.

Archivado continuo (o recuperación de un momento dado o PITR)

  • Adecuado para bases de datos muy grandes donde las copias de seguridad lógicas o físicas tomarían demasiado tiempo.
  • Algunos directorios dentro del directorio de datos se pueden excluir para acelerar el proceso.

Instantáneas

  • Requiere compatibilidad con el sistema operativo; por ejemplo, LVM funciona bastante bien, lo que también ha sido confirmado por NetBackup for PostgreSQL Agent.
  • Adecuado para aplicaciones en las que tanto el directorio de datos como la base de datos deben estar sincronizados, p. aplicaciones LAMP, siempre que las dos instantáneas estén sincronizadas.
  • No se recomienda cuando los archivos de la base de datos se almacenan en varios sistemas de archivos (deben tomar instantáneas de todos los sistemas de archivos simultáneamente).

Nube

Todos los proveedores de la nube implementan copias de seguridad en su oferta de PostgreSQL. Las copias de seguridad lógicas se pueden realizar como de costumbre, mientras que las copias de seguridad físicas y PITR están disponibles a través de las ofertas de servicios en la nube, ya que el acceso al almacén de datos no está disponible (consulte, por ejemplo, Amazon Aurora para PostgreSQL). Por lo tanto, la copia de seguridad de PostgreSQL en la nube deberá ser un tema para otro blog.

Base de agentes

  • Requiere un agente instalado en los destinos.
  • Puede hacer copias de seguridad a nivel de bloque, p. COMMVAULT (instalación admitida solo en Windows).

Características

Si bien PostgreSQL proporciona las herramientas listas para usar necesarias para realizar copias de seguridad lógicas, físicas y PITR, las aplicaciones de copia de seguridad especializadas se basan en las herramientas nativas de PostgreSQL y del sistema operativo para satisfacer la necesidad de implementar una estrategia de copia de seguridad que aborde los siguientes puntos:

  • automatización
  • frecuencia
  • período de retención
  • integridad
  • facilidad de uso

Además, las herramientas de copia de seguridad de PostgreSQL intentan proporcionar funciones comunes a las herramientas de copia de seguridad genéricas, como:

  • copias de seguridad incrementales para ahorrar espacio de almacenamiento
  • catálogos de respaldo
  • capacidad de almacenar copias de seguridad en las instalaciones o en la nube
  • alertas y notificaciones
  • informes completos
  • control de acceso
  • cifrado
  • interfaz gráfica y paneles
  • copias de seguridad de hosts remotos
  • rendimiento adaptativo para minimizar la carga en los objetivos
  • manejo de múltiples hosts en paralelo
  • orquestación de respaldo, p. encadenamiento de trabajos
  • API REST

Configuración de laboratorio

Para este ejercicio, configuré un host de comando y control donde instalaré las herramientas de copia de seguridad, que también ejecuta dos instancias de PostgreSQL, 9.6 y 10, instaladas desde los repositorios de 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

También configuré dos instancias remotas de PostgreSQL que ejecutan las mismas versiones 9.6 y 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

Luego, use pgbench para crear un conjunto de datos:

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)

Herramientas

Se puede encontrar una lista de herramientas de copia de seguridad comunes en la Wiki de PostgreSQL:sección Copia de seguridad. He aumentado la lista con productos que he encontrado a lo largo de los años y de una búsqueda reciente en Internet.

Amanda

Amanda está basada en agentes, es de código abierto y es compatible con PostgreSQL desde el primer momento a través de la API ampgsql. En el momento de escribir este artículo, la versión 3.5.1 no es compatible con espacios de tabla (ver man ampgsql).

Zmanda proporciona una versión empresarial que también es de código abierto, sin embargo, no está disponible directamente para su descarga como prueba.

Amanda requiere un host de respaldo dedicado ya que los paquetes de servidor y cliente se excluyen entre sí:

[[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 la guía de configuración básica para configurar el servidor y el cliente, luego configure la API de PostgreSQL.

Aquí hay una diferencia de git de mi laboratorio:

  • Servidor:

    • aumentar el espacio de copia de seguridad del 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 el objetivo de PostgreSQL (y deshabilite la copia de seguridad de muestra):

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

    • configuración:

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

      • archivo de autenticación:

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

    • autorizar el 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

    • Autenticación 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

    • Configuración de 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 vez completada la configuración anterior, ejecute la copia de seguridad:

[[email protected] ~]$ amdump omiday

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

La restauración desde una copia de seguridad implica más pasos manuales, como se explica en la sección de restauración.

Según las preguntas frecuentes de Amanda Enterprise, la siguiente mejora se aplicaría a nuestro ejemplo de PostgreSQL:

  • consola de administración para la automatización de copias de seguridad, políticas de retención y programaciones
  • copia de seguridad en el almacenamiento en la nube de Amazon S3

Camarero

Barman es una solución de recuperación ante desastres para PostgreSQL mantenida por 2ndQuadrant. Está diseñado para administrar copias de seguridad de varias bases de datos y tiene la capacidad de restaurar a un punto anterior en el tiempo mediante la función PITR de PostgreSQL.

Características de Barman de un vistazo:

  • maneja múltiples objetivos
  • soporte para diferentes versiones de PostgreSQL
  • cero pérdida de datos
  • transmisión y/o archivo estándar de WAL
  • recuperación local o remota
  • recuperación simplificada de un punto en el tiempo

Como se indica en el Manual de Barman, la compatibilidad con copias de seguridad incrementales, trabajos paralelos, deduplicación de datos y compresión de red está disponible solo cuando se usa la opción rsync. Además, actualmente no se admite la transmisión de WAL desde un modo de espera mediante archive_command.

Después de seguir las instrucciones del manual para configurar el entorno 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

Todo está bien, por lo que podemos probar haciendo una copia de seguridad de los dos 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

Enumere el catálogo de respaldo:

-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

Visualización del contenido de una copia de seguridad en particular:

-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

Cuando Barman se configuró para transmisión WAL síncrona, podemos verificar el estado de replicación:

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

Se pueden agregar más mejoras utilizando los scripts de enlace provistos.

Finalmente, para los amantes de la línea de comandos, Barman viene con TAB completo.

Herramienta de copia de seguridad y recuperación de EDB (BART)

EDB BART es una aplicación propietaria de código cerrado proporcionada por EnterpriseDB. Combina la copia de seguridad de nivel de sistema de archivos nativo de PostgreSQL y PITR en una herramienta fácil de usar que proporciona las siguientes funciones:

  • políticas de retención
  • copias de seguridad incrementales
  • copias de seguridad completas, activas y físicas de varios servidores de base de datos Postgres Plus Advanced Server y PostgreSQL
  • gestión de copias de seguridad y recuperación de los servidores de bases de datos en hosts locales o remotos
  • catálogo centralizado para datos de respaldo
  • almacenar datos de copia de seguridad en formato comprimido
  • verificación de suma de control

Si bien la versión de prueba de la última versión v2.1 solo se puede obtener a través de una solicitud de repositorio de yum, el artículo Copia de seguridad de datos fácil y la guía de documentación del producto ofrecen información para aquellos que deseen obtener más información.

Descargue el documento técnico hoy Gestión y automatización de PostgreSQL con ClusterControl Obtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnico

pgBackRest

pgBackRest implementa una copia de seguridad completa del sistema que no depende de las herramientas comunes tar y rsync. Actualmente está alojado y disponible por CrunchyData bajo una licencia MIT. Consulte Reconocimiento para obtener detalles sobre sus orígenes.

Ofrece todas las características que uno esperaría de una herramienta centrada en PostgreSQL:

  • alto rendimiento de copia de seguridad/restauración
  • copias de seguridad completas, incrementales y diferenciales
  • políticas de retención
  • verificación de integridad de copia de seguridad y restauración a través de sumas de verificación de archivos e integración con sumas de verificación de página de PostgreSQL.
  • capacidad para reanudar las copias de seguridad
  • compresión de transmisión y sumas de verificación
  • Compatibilidad con el almacenamiento en la nube de Amazon S3
  • Cifrado

..y mucho más. Consulte la página del proyecto para obtener más detalles.

La instalación requiere un sistema Linux/Unix de 64 bits y se describe en la guía del usuario. La guía también presenta al lector los conceptos principales, muy útiles para aquellos que son nuevos en PostgreSQL o la tecnología de almacenamiento.

Aunque la guía usa ejemplos de comandos para Debian/Ubuntu, pgBackRest está disponible en el repositorio PGDG yum, y el instalador extraerá todas las dependencias:

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

Configuremos dos clústeres, pg96 y pg10, cada uno con un nodo:

  • nodo de control ("repositorio" en la guía):

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

  • grupo #1:

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

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

  • grupo #2:

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

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

A continuación, ejecute copias de seguridad y muestre el catálogo de copias de seguridad:

-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 admite la paralelización de copias de seguridad y restauración:siguiendo el ejemplo de la guía, respaldamos con una CPU y luego actualizamos la configuración para usar 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

El 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

Con 2 CPU, la copia de seguridad se ejecutó casi un 20 % más rápido, lo que puede marcar una gran diferencia cuando se ejecuta en un gran conjunto de datos.

Conclusión

Las herramientas de copia de seguridad centradas en PostgreSQL ofrecen, como se esperaba, más opciones que las herramientas de propósito general. La mayoría de las herramientas de copia de seguridad de PostgreSQL ofrecen la misma funcionalidad principal, pero su implementación presenta limitaciones que solo se pueden descubrir siguiendo cuidadosamente la documentación para probar el producto.

Además, ClusterControl ofrece una variedad de funciones de copia de seguridad y restauración que puede usar como parte de la configuración de administración de su base de datos.