Blog

Noticias

Anuncio de lanzamiento de Barman 3.11.1 y 3.11.0

EDB se complace en anunciar el lanzamiento de Barman 3.11.1 y 3.11.0. 

Principales características de esta versión:

Versión 3.11.1 – 22 de agosto de 2024

Corrección de errores:

  • Corrección de fallos en `barman-cloud-backup-delete`. Este comando estaba fallando al aplicar políticas de retención debido a un error introducido por la versión anterior.

Versión 3.11.0 – 22 de agosto de 2024

Características:
  • Añadido soporte para respaldos incrementales en Postgres 17 o superior. Esta característica principal está compuesta por varios cambios pequeños
    • Añadida la opción de línea de comandos `–incremental` al comando `barman backup`. Se utiliza para especificar el respaldo padre al realizar un respaldo incremental. El padre puede ser un respaldo completo o uno incremental.
    • Añadido el acceso directo `latest-full` al ID de respaldo. Junto con `latest`, se puede utilizar como acceso directo para seleccionar el respaldo padre para un respaldo incremental. Mientras que `latest` selecciona el último respaldo, independientemente de que sea completo o incremental, `latest-full` selecciona el último respaldo completo.
    • El comando `barman keep` sólo puede aplicarse a respaldos completos en caso de `backup_method = postgres`. Si un respaldo completo tiene respaldos incrementales que dependen de él, todos los incrementales también son conservados por Barman.
    • Al eliminar un respaldo se eliminan también todos los respaldos incrementales que dependan de él, si los hubiera.
    • Las políticas de retención no tienen en cuenta los respaldos incrementales sino únicamente los respaldos completos, puesto que los incrementales no pueden recuperarse sin disponer de toda la cadena de respaldos hasta el respaldo completo.
    • `barman recover` necesita combinar el respaldo completo con la cadena de respaldos incrementales al realizar la recuperación. La nueva opción CLI `–local-staging-path`, y la correspondiente opción de configuración `local_staging_path`, se utilizan para especificar la ruta en el host de Barman en el que se combinarán los respaldos al recuperar un respaldo incremental.
  • Cambios en la salida de `barman show-backup`:
    • Añadido el campo “Estimated cluster size”. Es útil disponer de una estimación del tamaño del directorio de datos de un cluster al restaurar un respaldo. Especialmente cuando se recuperan respaldos comprimidos o incrementales, situaciones en las que el tamaño del respaldo no refleja el tamaño del directorio de datos en Postgres. En formato JSON, se almacena como `cluster_size`.
    • Añadido el campo “WAL summarizer”, que muestra si `summarize_wal` estaba habilitado en Postgres en el momento de realizar el respaldo. En formato JSON, se almacena como `server_information.summarize_wal`. Este campo es omitido en Postgres 16 o anteriores.
    • Añadido el campo “Data checksums”. Muestra si `data_checkums` estaba habilitado en Postgres en el momento de realizar el respaldo. En formato JSON, se almacena como `server_information.data_checksums`.
    • Añadido el campo “Backup method». Muestra el método utilizado para el respaldo. En formato JSON, se almacena como `base_backup_information.backup_method`.
    • Se ha cambiado el nombre del campo “Disk Usage” por “Backup Size”. Este último proporciona un nombre más completo que representa el tamaño del respaldo en el host de Barman. El campo JSON bajo `base_backup_information` también cambió de nombre: de `disk_usage` a `backup_size`.
    • Añadido el campo “WAL size”. Muestra el tamaño de los WAL requeridos por el respaldo. En formato JSON, se almacena como `base_backup_information.wal_size`.
    • Refactorizado el campo “Incremental size”. Ahora se llama “Resources saving” y muestra una estimación de los recursos ahorrados al realizar respaldos incrementales con `rsync` o `pg_basebackup`. Compara el tamaño del respaldo con el tamaño estimado del cluster para determinar la cantidad de recursos de disco y de red ahorrados al realizar un respaldo incremental. En formato JSON, el campo ha pasado de llamarse `incremental_size` a `resource_savings` en `base_backup_information`.
    • Añadido el campo `system_id` al documento JSON. Este campo contiene el identificador de sistema de Postgres. Estaba presente en el formato de consola, pero faltaba en el formato JSON.
  • Añadidos campos relacionados con los respaldos incrementales de Postgres:
    • “Backup type”: indica si el respaldo de Postgres es completo o incremental. En formato JSON, se almacena como `backup_type` en `base_backup_information`.
    • “Root backup”: el ID del respaldo completo que es la raíz de una cadena de uno o más respaldos incrementales. En formato JSON, se almacena como `catalog_information.root_backup_id`.
    • “Parent backup”: el ID del respaldo completo o incremental del que se tomó el respaldo incremental corriente. En formato JSON, se almacena como `catalog_information.parent_backup_id`.
    • “Children Backup(s)”: los ID de los respaldos incrementales que se tomaron con el respaldo en cuestión como padre. En formato JSON, se almacena como `catalog_information.children_backup_ids`.
    • “Backup chain size”: el número de respaldos en la cadena desde el respaldo incremental actual hasta el respaldo raíz. En formato JSON, se almacena como `catalog_information.chain_size`.
  • Cambios en la salida de `barman list-backup`:
    • Ahora incluye el tipo de respaldo en la salida JSON. Puede ser `rsync` para respaldos tomados con rsync, `full` o `incremental` para respaldos tomados con `pg_basebackup`, o `snapshot` para instantáneas en la nube. Al mostrarse en la consola, el tipo de respaldo se representa con las etiquetas `R`, `F`, `I` o `S`.
    • Se ha eliminado de la salida la información sobre tablespaces. Eso estaba sobredimensionando la salida. La información sobre tablespaces todavía se puede encontrar en la salida de `barman show-backup`.
  • Siempre se establece un timestamp con una zona horaria cuando se configura `recovery_target_time` a través de `barman recover`. Anteriormente, si no se definía explícitamente ninguna zona horaria mediante `–target-time`, Barman configuraba `recovery_target_time` sin zona horaria en Postgres. Sin una zona horaria, Postgres asumía lo que estuviera configurado a través de `timezone` GUC en Postgres. A partir de ahora, si el usuario no ha definido ninguna zona horaria mediante la opción `–target-time`, Barman emitirá una advertencia y configurará `recovery_target_time` con la zona horaria del host de Barman.
  • Al recuperar un respaldo con el enfoque “no get wal” y si está configurado `–target-lsn`, se copiarán únicamente los archivos WAL necesarios para alcanzar el objetivo configurado. Anteriormente Barman copiaba todos los archivos WAL desde su archivo a Postgres.
  • Al recuperar un respaldo con el enfoque “no get wal” y si `–target-immediate` está configurado, se copiarán únicamente los archivos WAL necesarios para alcanzar el punto consistente. Anteriormente Barman copiaba todos los archivos WAL desde su archivo a Postgres.
  • Ahora `barman-wal-restore` transfiere los WALs del directorio de spool a `pg_wal` en lugar de copiarlos. Esto puede mejorar el rendimiento si el directorio de spool y el directorio `pg_wal` están en la misma partición.
  • `barman check-backup` Ahora `barman check-backup` muestra la razón por la que un respaldo fue marcado como `FAILED` en la salida y en los registros. Anteriormente, para que un usuario supiera por qué el respaldo se había marcado como `FAILED`, debía ejecutar el comando `barman show-backup`.
  • Añadida la opción de configuración `aws_await_snapshots_timeout` y la correspondiente opción de línea de comandos `–aws-await-snapshots-timeout` en `barman-cloud-backup`. Especifica el tiempo de espera en segundos para que los respaldos de instantáneas alcancen el estado completado.
  • Añadido el mecanismo keep-alive a los respaldos basados en rsync. Anteriormente, la sesión Postgres creada por Barman para ejecutar `pg_backup_start()` y `pg_backup_stop()` permanecía inactiva durante el tiempo que tardaba en realizarse el respaldo base. Esto podía provocar que un firewall o un enrutador interrumpiera la conexión debido a que permanecía inactiva durante mucho tiempo. El mecanismo keep-alive envía consultas de heartbeat a Postgres a través de esa conexión, reduciendo así la probabilidad de que la misma se interrumpa. El intervalo entre heartbeats puede controlarse mediante la nueva opción de configuración `keepalive_interval` y la correspondiente opción CLI `–keepalive-interval` del comando `barman backup`.
Corrección de errores:
  • Al recuperar un respaldo con el enfoque “no get wal” y `–target-time` configurado, se copiarán todos los archivos WAL. Anteriormente Barman intentaba adivinar los archivos WAL requeridos por Postgres para alcanzar el tiempo objetivo configurado. Sin embargo, el mecanismo no era lo suficientemente robusto ya que se basaba en las estadísticas del archivo WAL en el host de Barman (más concretamente la hora de creación). Por ejemplo: si se produjera un retraso de archivado o streaming entre Postgres y Barman, esto podría ser suficiente para que fallara la recuperación, ya que Barman no copiaría todos los archivos WAL necesarios debido a la débil comprobación basada en las estadísticas de archivo.
  • Conecta `python-snappy` a `0.6.1` al ejecutar Barman con Python 3.6 o anterior. Las versiones más recientes de `python-snappy` requieren la versión `cramjam` `2.7.0` o posterior, y estas solo están disponibles para Python 3.7 o posterior.
  • `barman receive-wal` ahora finaliza con el código `1` en lugar de `0` en los siguientes casos:
    • No se puede ejecutar con la opción `–reset` porque `pg_receivewal` se está ejecutando.
    • No se puede iniciar el proceso `pg_receivewal` porque ya está en ejecución.
  • Corrección y mejoras de la información sobre Python en la salida de `barman diagnose`:
    • El comando ahora se asegura de usar el mismo intérprete de Python bajo el cual está instalado Barman al mostrar la versión de Python a través de la clave JSON `python_ver`. Anteriormente, si un entorno tenía varias instalaciones de Python y/o entornos virtuales, la salida podía ser errónea, ya que podía obtenerse de un intérprete de Python diferente.
    • Añadida la clave `python_executable` a la salida JSON. Contiene la ruta al intérprete exacto de Python utilizado por Barman.

Esta información también se publica en la sección NEWS de Barman.

Información sobre Barman

Backup and Recovery Manager (o Barman) es una herramienta de administración de código abierto que realiza respaldos remotos y recuperación ante desastres de servidores PostgreSQL en entornos empresariales críticos. Se basa en la robusta y confiable tecnología Point-In-Time Recovery de PostgreSQL, que permite a los DBAs administrar remotamente un catálogo completo de respaldos así como la fase de recuperación de múltiples servidores remotos – desde una sola ubicación. Barman se distribuye bajo licencia GNU GPL 3 y es mantenido por EDB.

Haz clic aquí para leer la noticia original en inglés en la página web oficial de PostgreSQL.