Las copias de seguridad de la base de datos juegan un papel imperativo en el diseño de una estrategia eficaz de recuperación ante desastres para las bases de datos de producción. Los administradores y arquitectos de bases de datos deben trabajar continuamente para diseñar una estrategia de respaldo óptima y efectiva para bases de datos de misión crítica en tiempo real y garantizar que se cumplan los SLA de recuperación ante desastres. Según mi experiencia, esto no es fácil y puede llevar de días a semanas lograr una estrategia de copia de seguridad impecable. Simplemente no está escribiendo un buen script para hacer una copia de seguridad de las bases de datos y asegurarse de que funcione. Hay varios factores a considerar, echemos un vistazo a ellos:
- Tamaño de la base de datos: El tamaño de la base de datos juega un papel importante al diseñar estrategias de copia de seguridad. De hecho, este es uno de los factores centrales que define a
- Tiempo que tarda la copia de seguridad
- La carga en los componentes de la infraestructura como disco, red, CPU, etc.
- Cantidad de almacenamiento de respaldo requerido y los costos involucrados
- Si las bases de datos están alojadas en la nube, los costos de almacenamiento de respaldo dependen de la cantidad de almacenamiento requerida
- Además, el tamaño de la base de datos afecta el RTO
- Infraestructura: La estrategia de copia de seguridad depende en gran medida de la infraestructura de las bases de datos. El procedimiento de copia de seguridad sería diferente para las bases de datos alojadas en un servidor físico en un centro de datos local en comparación con las alojadas en la nube.
- Ubicación de copia de seguridad: ¿Adónde van las copias de seguridad? Por lo general, las copias de seguridad se colocarán en una ubicación remota, por ejemplo, en cinta o almacenamiento específico en la nube como AWS S3.
- Herramienta de copia de seguridad: Identifique una herramienta óptima para realizar una copia de seguridad de la base de datos en línea que potencialmente garantice que se ha realizado una copia de seguridad coherente.
Una buena estrategia de copia de seguridad de la base de datos debe garantizar que se cumplan el RTO (objetivo de tiempo de recuperación) y el RPO (objetivo de punto de recuperación), lo que a su vez ayuda a lograr el objetivo de recuperación ante desastres. Las copias de seguridad a nivel del sistema de archivos se pueden realizar en bases de datos PostgreSQL de varias maneras. En este blog, mi atención se centrará en una herramienta llamada Barman, que se usa popularmente para realizar copias de seguridad de bases de datos de PostgreSQL.
Barman (administrador de respaldo y recuperación) es una herramienta de código abierto basada en Python desarrollada por desarrolladores en 2nd Quadrant. Esta herramienta está desarrollada para lograr una estrategia de respaldo de base de datos de nivel empresarial para bases de datos de producción PostgreSQL de misión crítica. Sus funciones y características se asemejan a las de RMAN de Oracle. En mi opinión, barman es una de las mejores opciones para las bases de datos PostgreSQL y puede brindar varios beneficios desde la perspectiva de las operaciones a los DBA e ingenieros de infraestructura.
Veamos algunas capacidades de Barman:
Comenzaré con la descripción general de la configuración y luego enumeraré qué tipo de copias de seguridad se pueden realizar
Técnicamente, barman-cli es una herramienta basada en Python y tiene que manejar dos archivos de configuración diferentes. Un archivo que es la configuración real para la copia de seguridad de la base de datos reside en los nombres "/etc/barman.d" como
El contenido de ejemplo del archivo /etc/barman.conf se muestra a continuación
[barman]
barman_user = barman ---------> barman user who performs backup/recovery of database
configuration_files_directory = /etc/barman.d -----> location for DB configuration files
barman_home = /dbbackups/barman ---> barman home directory
log_file = /dbbackups/barman/logs/barman.log ---> barman log file location
log_level = INFO -----> level of logging for barman operations
compression = gzip -----> backups must be compressed
Instalación de Barman
Echemos un vistazo al procedimiento de instalación de barman -
Instalación desde la fuente
Descarga el barman desde https://www.pgbarman.org/
Descomprima / descomprima el instalador y ejecute el siguiente comando como usuario root -
[[email protected] barman-2.4]# ./setup.py install
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'setup_requires'
warnings.warn(msg)
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'install_requires'
warnings.warn(msg)
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'tests_require'
warnings.warn(msg)
running install
running build
running build_py
creating build
creating build/lib
creating build/lib/barman
copying barman/utils.py -> build/lib/barman
copying barman/fs.py -> build/lib/barman
copying barman/retention_policies.py -> build/lib/barman
copying barman/diagnose.py -> build/lib/barman
copying barman/backup.py -> build/lib/barman
copying barman/recovery_executor.py -> build/lib/barman
copying barman/backup_executor.py -> build/lib/barman
copying barman/config.py -> build/lib/barman
copying barman/process.py -> build/lib/barman
copying barman/output.py -> build/lib/barman
copying barman/__init__.py -> build/lib/barman
copying barman/remote_status.py -> build/lib/barman
copying barman/xlog.py -> build/lib/barman
copying barman/lockfile.py -> build/lib/barman
copying barman/postgres.py -> build/lib/barman
copying barman/server.py -> build/lib/barman
copying barman/cli.py -> build/lib/barman
copying barman/version.py -> build/lib/barman
copying barman/compression.py -> build/lib/barman
copying barman/wal_archiver.py -> build/lib/barman
copying barman/infofile.py -> build/lib/barman
copying barman/exceptions.py -> build/lib/barman
copying barman/hooks.py -> build/lib/barman
copying barman/copy_controller.py -> build/lib/barman
copying barman/command_wrappers.py -> build/lib/barman
running build_scripts
creating build/scripts-2.7
copying and adjusting bin/barman -> build/scripts-2.7
changing mode of build/scripts-2.7/barman from 644 to 755
running install_lib
creating /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/utils.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/fs.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/retention_policies.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/diagnose.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/backup.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/recovery_executor.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/backup_executor.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/config.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/process.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/output.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/__init__.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/remote_status.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/xlog.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/lockfile.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/postgres.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/server.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/cli.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/version.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/compression.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/wal_archiver.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/infofile.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/exceptions.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/hooks.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/copy_controller.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/command_wrappers.py -> /usr/lib/python2.7/site-packages/barman
byte-compiling /usr/lib/python2.7/site-packages/barman/utils.py to utils.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/fs.py to fs.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/retention_policies.py to retention_policies.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/diagnose.py to diagnose.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/backup.py to backup.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/recovery_executor.py to recovery_executor.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/backup_executor.py to backup_executor.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/config.py to config.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/process.py to process.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/output.py to output.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/__init__.py to __init__.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/remote_status.py to remote_status.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/xlog.py to xlog.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/lockfile.py to lockfile.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/postgres.py to postgres.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/server.py to server.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/cli.py to cli.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/version.py to version.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/compression.py to compression.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/wal_archiver.py to wal_archiver.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/infofile.py to infofile.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/exceptions.py to exceptions.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/hooks.py to hooks.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/copy_controller.py to copy_controller.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/command_wrappers.py to command_wrappers.pyc
running install_scripts
copying build/scripts-2.7/barman -> /usr/bin
changing mode of /usr/bin/barman to 755
running install_data
copying doc/barman.1 -> /usr/share/man/man1
copying doc/barman.5 -> /usr/share/man/man5
running install_egg_info
Writing /usr/lib/python2.7/site-packages/barman-2.4-py2.7.egg-info
Instalación desde el repositorio
La instalación también se puede realizar a través de yum de la siguiente manera
[[email protected]~]$ yum install barman
Echemos un vistazo a los diferentes tipos de copias de seguridad compatibles con Barman
Copias de seguridad activas físicas
Barman admite copias de seguridad activas físicas, lo que significa copias de seguridad en línea de archivos de datos físicos y archivos de registro de transacciones de la base de datos utilizando la metodología rsync, que también puede estar en forma comprimida.
Echemos un vistazo a los pasos y comandos para realizar una copia de seguridad RSYNC usando barman
#1 Archivo de configuración de base de datos PostgreSQL para barman
[pgdb]
description="Main PostgreSQL server"
conninfo=host=pgserver user=postgres dbname=postgres
ssh_command=ssh [email protected]
archiver=on
backup_method = rsync
“pgdb” es el identificador de la base de datos de Postgres para barman y el nombre del archivo de configuración debe ser
El parámetro backup_method define el tipo de copia de seguridad que se realizará. En este caso, el método_respaldo es rsync.
Nota:Para que el comando de copia de seguridad de barman sea exitoso, se debe configurar la autenticación ssh sin contraseña entre los servidores barman y postgres.
#2 parámetros del archivo postgresql.conf
wal_level=replica
archive_mode=on
archive_command=’rsync to <ARCHIVE LOCATION>’
Comando de respaldo de Barman
#3 Comprobar si el barman está listo para realizar copias de seguridad
[[email protected] pgdb]$ barman check pgdb
Server pgdb:
PostgreSQL: OK
is_superuser: OK
wal_level: 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 4 backups, expected at least 0)
ssh: OK (PostgreSQL server)
not in recovery: OK
archive_mode: OK
archive_command: OK
continuous archiving: OK
archiver errors: OK
El resultado anterior dice que todo está "bien" para continuar con la copia de seguridad, lo que significa que está listo para realizar una copia de seguridad.
Por ejemplo, el siguiente resultado dice que no se puede realizar una copia de seguridad porque, según el barman, SSH no funciona -
[[email protected] ~]$ barman check pgdb
Server pgdb:
PostgreSQL: OK
is_superuser: OK
wal_level: 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)
ssh: FAILED (Connection failed using '[email protected] -o BatchMode=yes -o StrictHostKeyChecking=no' return code 127)
not in recovery: OK
archive_mode: OK
archive_command: OK
continuous archiving: OK
archiver errors: OK
#4 Realizar copia de seguridad de la base de datos
[[email protected] ~]$ barman backup pgdb
Starting backup using rsync-exclusive method for server pgdb in /dbbackup/barman_backups/pgdb/base/20180816T153846
Backup start at LSN: 0/1C000028 (00000001000000000000001C, 00000028)
This is the first backup for server pgdb
WAL segments preceding the current backup have been found:
00000001000000000000000B from server pgdb has been removed
00000001000000000000000C from server pgdb has been removed
00000001000000000000000D from server pgdb has been removed
00000001000000000000000E from server pgdb has been removed
00000001000000000000000F from server pgdb has been removed
000000010000000000000010 from server pgdb has been removed
000000010000000000000011 from server pgdb has been removed
000000010000000000000012 from server pgdb has been removed
000000010000000000000013 from server pgdb has been removed
000000010000000000000014 from server pgdb has been removed
000000010000000000000015 from server pgdb has been removed
000000010000000000000016 from server pgdb has been removed
Starting backup copy via rsync/SSH for 20180816T153846
Copy done (time: 1 second)
This is the first backup for server pgdb
Asking PostgreSQL server to finalize the backup.
Backup size: 21.8 MiB
Backup end at LSN: 0/1C0000F8 (00000001000000000000001C, 000000F8)
Backup completed (start time: 2018-08-16 15:38:46.668492, elapsed time: 1 second)
Processing xlog segments from file archival for pgdb
000000010000000000000016
000000010000000000000017
000000010000000000000018
000000010000000000000019
00000001000000000000001A
00000001000000000000001B
00000001000000000000001C
00000001000000000000001C.00000028.backup
Para comprender si el comando de copia de seguridad de barman tendrá éxito, el siguiente comando ayuda:
Copias de seguridad incrementales
Otra gran capacidad de Barman es la posibilidad de realizar copias de seguridad incrementales. Esto significa que solo se pueden realizar copias de seguridad de los bloques modificados desde la última copia de seguridad completa de la base de datos. Para las bases de datos que experimentan menos cambios de datos, la copia de seguridad incremental puede reducir el uso de recursos.
Depende en gran medida de rsync y enlaces duros. A continuación se muestran los beneficios de las copias de seguridad incrementales:
- Reduce significativamente el tiempo de respaldo diario
- El volumen de datos que se respalda se reduce, ya que solo se respaldarán los bloques de datos modificados, lo que, a su vez, reduce el uso de recursos de infraestructura como ancho de banda de red, espacio en disco, E/S, etc.
- Si busca lograr un muy buen RTO, esta es la característica que estaría buscando
Los comandos para la copia de seguridad incremental son prácticamente los mismos. Cualquier copia de seguridad posterior a la primera realizada con la opción backup_method=rsync serán copias de seguridad incrementales y barman extrae las WAL usando la utilidad pg_recievexlog.
Copias de seguridad y recuperación de bases de datos remotas
En mi opinión, esta capacidad de Barman es muy beneficiosa para los administradores de bases de datos. Lo primero que buscarían los DBA es evitar estresar los recursos del servidor de la base de datos de producción tanto como sea posible durante las copias de seguridad y hacerlo de forma remota sería la mejor opción. Barman aprovecha pg_basebackup, lo que facilita mucho la creación de secuencias de comandos y la automatización.
En general, las opciones tradicionalmente disponibles para las copias de seguridad automáticas serán -
- pg_basebackup
- copia tar
Las dos opciones anteriores implican una gran cantidad de desarrollo y pruebas para garantizar que se implemente una estrategia de copia de seguridad efectiva para satisfacer las demandas de los acuerdos de nivel de servicio y pueden plantear desafíos para grandes bases de datos con múltiples espacios de tabla.
Con Barman, es bastante simple. Otra capacidad excepcional de barman es la transmisión WAL continua. Echemos un vistazo a eso con un poco más de detalle.
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écnicoStreaming Backup con streaming WAL continuo
Esto hace que Barman se destaque en comparación con otras herramientas en el mercado. Los archivos WAL en vivo se pueden transmitir continuamente a una ubicación de copia de seguridad remota utilizando Barman. Esta es LA CARACTERÍSTICA que los DBA estarían emocionados de conocer. Estaba emocionado de saber sobre esto. Es extremadamente difícil o casi imposible lograr esto con scripts creados manualmente o con una combinación de herramientas como pg_basebackup y pg_receivewal. Con la transmisión continua de WAL, se puede lograr un mejor RPO. Si la estrategia de copia de seguridad se diseña meticulosamente, no sería exagerado decir que se puede lograr un RPO de casi 0.
Veamos los pasos, comandos para realizar una copia de seguridad de streaming barman
#1 cambios en el parámetro postgresql.conf
Siguientes configuraciones a realizar en el postgresql.conf
wal_level=replica
max_wal_senders = 2
max_replication_slots = 2
synchronous_standby_names = 'barman_receive_wal'
archive_mode=on
archive_command = 'rsync -a %p [email protected]:INCOMING_WAL_DIRECTORY/%f'
archive_timeout=3600 (should not be 0 or disabled)
#2 Crear ranura de replicación usando barman
La ranura de replicación es importante para la transmisión de copias de seguridad. En caso de que la transmisión continua de WAL falle por algún motivo, todas las WAL no transmitidas se pueden conservar en la base de datos de postgres sin eliminarlas.
[[email protected] ~]$ barman receive-wal --create-slot pgdb
Creating physical replication slot 'barman' on server 'pgdb'
Replication slot 'barman' created
#3 Configure el archivo de configuración del servidor de base de datos para barman
El identificador de la base de datos para barman es "pgdb". Se debe crear un archivo de configuración llamado pgdb.conf en la ubicación /etc/barman.d/ con el siguiente contenido
[pgdb]
description="Main PostgreSQL server"
conninfo=host=pgserver user=postgres dbname=postgres
streaming_conninfo=host=pgserver user=barman
backup_method=postgres
archiver=on
incoming_wals_directory=/dbbackups/barman_backups/pgdb/incoming
streaming_archiver=on
slot_name=barman
streaming_conninfo es el parámetro a configurar para que barman realice copias de seguridad de transmisión
backup_method debe configurarse en "postgres" cuando se realice una copia de seguridad de la transmisión
streaming_archiver debe configurarse como "activado"
slot_name=barman Este parámetro debe configurarse cuando necesite que Barman use las ranuras de replicación. En este caso, el nombre de la ranura de replicación es barman
Una vez finalizada la configuración, realice una verificación de barman para asegurarse de que las copias de seguridad de transmisión se ejecuten correctamente.
#4 Comprobar si barman receive-wal se está ejecutando correctamente
En general, para el primer barman, receive-wal no funciona inmediatamente después de los cambios de configuración, puede fallar y el comando barman check puede mostrar lo siguiente:
[[email protected] archive_status]$ barman check pgdb
Server pgdb:
PostgreSQL: OK
is_superuser: OK
PostgreSQL streaming: OK
wal_level: 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: FAILED (See the Barman log file for more details)
archiver errors: OK
Cuando ejecuta barman receive-wal, es posible que se cuelgue. Para hacer que receive-wal funcione correctamente por primera vez, se debe ejecutar el siguiente comando.
[[email protected] arch_logs]$ barman cron
Starting WAL archiving for server pgdb
Starting streaming archiver for server pgdb
Ahora, haz una revisión de barman nuevamente, debería estar bien ahora.
[[email protected] arch_logs]$ barman check pgdb
Server pgdb:
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 2 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
Si puede ver, el estado de receivexlog muestra que está bien. Este es uno de los problemas que enfrenté.
#5 Comprobar si el barman está listo para realizar copias de seguridad
[[email protected] ~]$ barman check pgdb
Server pgdb:
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 4 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
#6 Verifica el estado de la transmisión usando barman
[[email protected] pgdb]$ barman replication-status pgdb
Status of streaming clients for server 'pgdb':
Current LSN on master: 0/250008A8
Number of streaming clients: 1
1. #1 Sync WAL streamer
Application name: barman_receive_wal
Sync stage : 3/3 Remote write
Communication : TCP/IP
IP Address : 192.168.1.10 / Port: 52602 / Host: -
User name : barman
Current state : streaming (sync)
Replication slot: barman
WAL sender PID : 26592
Started at : 2018-08-16 16:03:21.422430+10:00
Sent LSN : 0/250008A8 (diff: 0 B)
Write LSN : 0/250008A8 (diff: 0 B)
Flush LSN : 0/250008A8 (diff: 0 B)
El estado anterior significa que el barman está listo para realizar una copia de seguridad de la transmisión. Realice la copia de seguridad como se muestra a continuación -
[[email protected] arch_logs]$ barman backup pgdb
Starting backup using postgres method for server pgdb in /dbbackup/barman_backups/pgdb/base/20180816T160710
Backup start at LSN: 0/1F000528 (00000001000000000000001F, 00000528)
Starting backup copy via pg_basebackup for 20180816T160710
Copy done (time: 1 second)
Finalising the backup.
Backup size: 21.9 MiB
Backup end at LSN: 0/21000000 (000000010000000000000020, 00000000)
Backup completed (start time: 2018-08-16 16:07:10.401526, elapsed time: 1 second)
Processing xlog segments from file archival for pgdb
00000001000000000000001F
000000010000000000000020
000000010000000000000020.00000028.backup
000000010000000000000021
Processing xlog segments from streaming for pgdb
00000001000000000000001F
000000010000000000000020
Copias de seguridad centralizadas y catalogadas
Es muy beneficioso para entornos que ejecutan varias bases de datos en varios servidores en un entorno de red. Esta es una de las características excepcionales de Barman. He trabajado en entornos en tiempo real en los que tuve que gestionar, administrar cientos de bases de datos y siempre sentí la necesidad de realizar copias de seguridad de bases de datos centralizadas y es por eso que Oracle RMAN se hizo popular para la estrategia de copia de seguridad de bases de datos de Oracle y ahora Barman está llenando eso. espacio para PostgreSQL. Con Barman, los ingenieros de DBA y DevOps pueden trabajar para crear un servidor de copia de seguridad centralizado en el que se mantengan y validen las copias de seguridad de la base de datos para todas las bases de datos.
Copias de seguridad catalogadas, lo que significa que barman mantiene un repositorio centralizado donde se mantienen los estados de todas las copias de seguridad. Puede verificar las copias de seguridad disponibles para una base de datos en particular como se muestra a continuación -
[[email protected] ~]$ barman list-backup pgdb
pgdb 20180816T160924 - Thu Aug 16 16:09:25 2018 - Size: 22.0 MiB - WAL Size: 135.7 KiB
pgdb 20180816T160710 - Thu Aug 16 16:07:11 2018 - Size: 21.9 MiB - WAL Size: 105.8 KiB
pgdb 20180816T153913 - Thu Aug 16 15:39:15 2018 - Size: 21.9 MiB - WAL Size: 54.2 KiB
pgdb 20180816T153846 - Thu Aug 16 15:38:48 2018 - Size: 21.9 MiB - WAL Size: 53.0 KiB
Política de retención de copias de seguridad
Políticas de retención se puede definir para las copias de seguridad de la base de datos. Las copias de seguridad pueden volverse obsoletas después de un cierto período y las copias de seguridad obsoletas se pueden eliminar de vez en cuando.
Hay opciones en el archivo de configuración para garantizar que las copias de seguridad se conserven y queden obsoletas cuando el período de retención exceda -
El primer parámetro a configurar es minimum_redundancy . Configure siempre la redundancia mínima en>0 para asegurarse de que las copias de seguridad no se eliminen accidentalmente.
Ejemplo:redundancia_mínima =1
- política_de_retención El parámetro determinará durante cuánto tiempo se deben conservar las copias de seguridad base para garantizar que se cumplan los SLA de recuperación ante desastres.
- política_de_retención_wal El parámetro determinará durante cuánto tiempo se deben conservar las copias de seguridad de wal. Esto garantiza que se cumpla el RPO esperado.
Las políticas de retención y redundancia existentes para un servidor de base de datos se pueden verificar usando el comando barman check de la siguiente manera
[[email protected] ~]$ barman check pgdb
Server pgdb:
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 4 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
Copias de seguridad y recuperaciones en paralelo se puede realizar utilizando múltiples CPU, lo que realmente hace que las copias de seguridad y las recuperaciones se completen más rápido. Esta característica es beneficiosa para bases de datos muy grandes con un tamaño de hasta TeraBytes.
Para ejecutar copias de seguridad en paralelo, agregue la siguiente opción en el archivo de configuración del servidor de la base de datos (que es el archivo /etc/barman.d/pgdb.conf)-
parallel_jobs = 1
Puedo concluir diciendo que barman es una herramienta de nivel empresarial que potencialmente puede ayudar a los administradores de bases de datos a diseñar una estrategia eficaz de recuperación ante desastres.
Recursos relacionados ClusterControl para PostgreSQLMás información Uso de pg_dump y pg_dumpall para realizar copias de seguridad de PostgreSQLLea el blog Herramientas principales de copia de seguridad para PostgreSQLLea el blog Conviértase en un DBA de PostgreSQL:copias de seguridad lógicas y físicas de PostgreSQLLea el blog