Gracias a las nuevas utilidades barman-cloud-restore y barman-cloud-wal-restore introducido en Barman 2.11 , ahora es posible ejecutar la recuperación de una instancia de PostgreSQL usando una copia de seguridad completa ejecutada previamente usando barman-cloud-wal-archive y barman-cloud-backup comandos Descubramos juntos cómo implementar esto en el siguiente artículo.
Vale la pena señalar que en Barman 2.11, todas las utilidades de la nube para Barman están ahora en un paquete separado llamado barman-cli-cloud .
Requisitos
1. barman-cli-cloud paquete
2. Una instancia de PostgreSQL
3. Un depósito de AWS S3
4. Una segunda máquina virtual donde ejecutar la restauración
En este artículo, probaremos barman-cli-cloud funcionalidades en una máquina virtual con Debian Buster y PostgreSQL 12. Para seguir correctamente las instrucciones contenidas en este artículo, también asumimos que tiene:
- configuró Postgres para archivar archivos WAL en un depósito S3 existente usando
barman-cloud-wal-archive - ejecutó una copia de seguridad y la envió al mismo depósito S3 a través de
barman-cloud-backup
Puede lograrlo fácilmente siguiendo las instrucciones contenidas en estos artículos de blog anteriores:
- Barman Cloud - Parte 1:Archivo WAL
- Barman Cloud - Parte 2:Copia de seguridad en la nube
Configurar el servidor de recuperación
Como resultado, tenemos un depósito S3 en AWS llamado barman-s3-test que ya contiene los archivos WAL y la copia de seguridad archivada a través de barman-cloud-wal-archive y barman-cloud-backup herramientas, ahora necesitamos configurar correctamente un servidor que será el host para la recuperación de la instancia de PostgreSQL.
1. Instale PostgreSQL 12 desde el repositorio oficial de PGDG
2. Instale el repositorio público de 2ndQuadrant
3. Instala el barman-cli-cloud paquete:
[email protected]:~# apt update [email protected]:~# apt install barman-cli-cloud
4. Instale awscli paquete:
[email protected]:~# apt install awscli
5. Configure las credenciales de AWS con la herramienta awscli como usuario de postgres:
[email protected]:~$ aws configure --profile barman-cloud AWS Access Key ID [None]: AKI***************** AWS Secret Access Key [None]: **************************************** Default region name [None]: eu-west-1 Default output format [None]: json
Ejecutar el procedimiento de restauración
Ahora que el servidor de recuperación está configurado correctamente, estamos listos para iniciar el procedimiento de restauración.
Barman 2.11 presenta la barman-cloud-backup-list comando que permite recuperar información sobre las copias de seguridad realizadas con barman-cloud-backup :
[email protected]:~$ barman-cloud-backup-list \ --profile barman-cloud \ s3://barman-s3-test pg12 Backup ID End Time Begin Wal 20200713T120856 2020-07-13 12:09:05 00000001000000000000000C
Ahora estamos listos para ejecutar la restauración usando barman-cloud-restore comando:
[email protected]:~$ barman-cloud-restore \ --profile barman-cloud \ s3://barman-s3-test \ pg12 20200713T120856 \ /var/lib/postgresql/12/main/
Una vez que la restauración finaliza con éxito, podemos verificar el contenido del directorio PGDATA:
[email protected]:~$ ls /var/lib/postgresql/12/main/ PG_VERSION global pg_hba.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.conf backup_label pg_commit_ts pg_ident.conf pg_notify pg_snapshots pg_subtrans pg_wal postgresql.conf base pg_dynshmem pg_logical pg_replslot pg_stat pg_tblspc pg_xact
Ahora, para asegurarnos de que el proceso de restauración funcionó correctamente, debemos iniciar la instancia de PostgreSQL recuperada y verificar que todo funcione como se esperaba. Este proceso requiere algunos pasos adicionales.
Primero, dado que estamos en un sistema Debian, necesitamos copiar los archivos que contienen la configuración de PostgreSQL en /etc/postgresql/12/main/ directorio:
[email protected]:~$ cp /var/lib/postgresql/12/main/postgresql.conf /etc/postgresql/12/main/ [email protected]:~$ cp /var/lib/postgresql/12/main/pg_hba.conf /etc/postgresql/12/main/ [email protected]:~$ cp /var/lib/postgresql/12/main/pg_ident.conf /etc/postgresql/12/main/
En segundo lugar, cree el recovery.signal archivo:
[email protected]:~$ touch /var/lib/postgresql/12/main/recovery.signal
Luego, deshabilite el archive_command para evitar que la instancia recuperada escriba en el mismo depósito que la instancia original:
[email protected]:~$ echo \"archive_command = 'cd .'\" >> /etc/postgresql/12/main/postgresql.conf
Después de eso, debe configurar PostgreSQL para recuperar los archivos WAL de la última línea de tiempo disponible del depósito S3 mediante barman-cloud-wal-restore en el restore_command :
[email protected]:~$ echo \"restore_command = 'barman-cloud-wal-restore --profile barman-cloud s3://barman-s3-test pg12 %f %p'\" >> /etc/postgresql/12/main/postgresql.conf [email protected]:~$ echo \"recovery_target_timeline = 'latest'\" >> /etc/postgresql/12/main/postgresql.conf
IMPORTANTE :Antes de continuar, asegúrese de que la instancia de PostgreSQL no se esté ejecutando y de que el directorio de destino (el directorio de datos predeterminado de PostgreSQL) esté vacío.
Finalmente, estamos listos para iniciar la nueva instancia recuperada:
[email protected]:~# systemctl restart [email protected]
¡Estupendo! Como podemos ver en el registro de PostgreSQL, los archivos WAL se recuperaron del depósito S3 y la instancia se inició correctamente:
[email protected]:~$ less /var/log/postgresql/postgresql-12-main.log ... 2020-07-13 12:43:25.093 UTC [9458] LOG: starting PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit 2020-07-13 12:43:25.093 UTC [9458] LOG: listening on IPv4 address "127.0.0.1", port 5432 2020-07-13 12:43:25.095 UTC [9458] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2020-07-13 12:43:25.111 UTC [9459] LOG: database system was interrupted; last known up at 2020-07-13 12:08:56 UTC 2020-07-13 12:43:25.508 UTC [9459] LOG: starting archive recovery 2020-07-13 12:43:26.010 UTC [9459] LOG: restored log file "00000001000000000000000C" from archive 2020-07-13 12:43:26.052 UTC [9459] LOG: redo starts at 0/C000028 2020-07-13 12:43:26.054 UTC [9459] LOG: consistent recovery state reached at 0/C000138 2020-07-13 12:43:26.054 UTC [9458] LOG: database system is ready to accept read only connections 2020-07-13 12:43:26.469 UTC [9459] LOG: restored log file "00000001000000000000000D" from archive 2020-07-13 12:43:26.823 UTC [9459] LOG: redo done at 0/D0001B0 2020-07-13 12:43:27.242 UTC [9459] LOG: restored log file "00000001000000000000000D" from archive 2020-07-13 12:43:27.592 UTC [9459] LOG: selected new timeline ID: 2 2020-07-13 12:43:27.644 UTC [9459] LOG: archive recovery complete 2020-07-13 12:43:27.979 UTC [9458] LOG: database system is ready to accept connections
Conclusión
Como es habitual con cualquier nueva versión de Barman, recomendamos que todos actualicen sus sistemas a la última versión. Una lista completa de cambios y correcciones de errores está disponible aquí.
Tenga en cuenta que si ya está utilizando barman-cloud-wal-archive o barman-cloud-backup instalado a través del paquete RPM/Apt y está actualizando su sistema, debe instalar el barman-cli-cloud paquete. Esto se debe al hecho de que, con el lanzamiento de Barman 2.11, todas las herramientas relacionadas con la nube forman parte de barman-cli-cloud paquete como se explica al principio del artículo.
Las próximas versiones de Barman podrían mejorar las capacidades de uso y automatización del comando de recuperación, por ejemplo, al preparar un recovery.conf o recovery.signal archivo como lo hace el Barman real.
