
pgbackrest release/2.59.0
Solución de copia de seguridad y restauración en paralelo para PostgreSQL con cifrado, restauración delta y compatibilidad con almacenamiento de objetos en múltiples nubes para la recuperación ante desastres empresariales.
pgBackRest
Copia de seguridad y restauración confiable de PostgreSQL
Introducción
pgBackRest es una solución confiable de copia de seguridad y restauración para PostgreSQL que escala sin problemas hasta las bases de datos y cargas de trabajo más grandes.
pgBackRest v2.59.2 es la versión estable actual. Las notas de la versión están en la página de Releases.
¡Danos una estrella en GitHub si te gusta pgBackRest!
Noticias
27 de septiembre de 2026 - pgBackRest 2.59.2 publicado
17 de agosto de 2026 - pgBackRest 2.59.1 publicado
20 de julio de 2026 - Nuevo tarball de distribución
Características
Copia de seguridad y restauración en paralelo
La compresión suele ser el cuello de botella durante las operaciones de copia de seguridad, por lo que pgBackRest resuelve este problema con procesamiento en paralelo y algoritmos de compresión más eficientes como lz4 y zstd.
Operación local o remota
Un protocolo personalizado permite a pgBackRest realizar copias de seguridad, restauraciones y archivado de forma local o remota mediante TLS/SSH con una configuración mínima. También se proporciona una interfaz para consultar PostgreSQL a través de la capa de protocolo, de modo que nunca se requiere acceso remoto a PostgreSQL, lo que mejora la seguridad.
Múltiples repositorios
Los múltiples repositorios permiten, por ejemplo, un repositorio local con retención mínima para restauraciones rápidas y un repositorio remoto con una retención más larga para redundancia y acceso en toda la empresa.
Copias de seguridad completas, diferenciales e incrementales (a nivel de archivo o de bloque)
Se admiten copias de seguridad completas, diferenciales e incrementales. pgBackRest no es susceptible a los problemas de resolución temporal de rsync, lo que hace que las copias de seguridad diferenciales e incrementales sean seguras sin necesidad de calcular la suma de verificación de cada archivo. Las copias de seguridad a nivel de bloque ahorran espacio al copiar únicamente las partes de los archivos que han cambiado.
Rotación de copias de seguridad y expiración del archivo
Se pueden establecer políticas de retención para copias de seguridad completas y diferenciales para crear cobertura para cualquier período de tiempo. El archivo WAL se puede mantener para todas las copias de seguridad o estrictamente para las copias de seguridad más recientes. En este último caso, el WAL necesario para que las copias de seguridad más antiguas sean consistentes se mantendrá en el archivo.
Integridad de la copia de seguridad
Se calculan sumas de verificación para cada archivo de la copia de seguridad y se vuelven a comprobar durante una restauración o verificación. Después de que una copia de seguridad termina de copiar archivos, espera hasta que cada segmento WAL necesario para que la copia de seguridad sea consistente llegue al repositorio.
Las copias de seguridad en el repositorio pueden almacenarse en el mismo formato que un clúster estándar de PostgreSQL (incluidos los tablespaces). Si la compresión está deshabilitada y los enlaces duros están habilitados, es posible tomar una instantánea de una copia de seguridad en el repositorio y levantar un clúster de PostgreSQL directamente sobre la instantánea. Esto es ventajoso para bases de datos a escala de terabytes cuya restauración de la forma tradicional consume mucho tiempo.
Todas las operaciones utilizan fsync a nivel de archivo y directorio para garantizar la durabilidad.
Sumas de verificación de páginas
Si las sumas de verificación de páginas están habilitadas, pgBackRest validará las sumas de verificación de cada archivo que se copie durante una copia de seguridad. Todas las sumas de verificación de páginas se validan durante una copia de seguridad completa y las sumas de verificación de los archivos que han cambiado se validan durante las copias de seguridad diferenciales e incrementales.
Los fallos de validación no detienen el proceso de copia de seguridad, pero se envían advertencias con detalles de exactamente qué páginas han fallado la validación a la consola y al registro de archivos.
Esta característica permite detectar la corrupción a nivel de página de forma temprana, antes de que expiren las copias de seguridad que contienen copias válidas de los datos.
Reanudación de copias de seguridad
Una copia de seguridad interrumpida se puede reanudar desde el punto en que se detuvo. Los archivos que ya se copiaron se comparan con las sumas de verificación del manifiesto para garantizar la integridad. Dado que esta operación puede realizarse completamente en el host del repositorio, reduce la carga en el host de PostgreSQL y ahorra tiempo, ya que el cálculo de sumas de verificación es más rápido que comprimir y retransmitir datos.
Compresión y sumas de verificación en streaming
La compresión y el cálculo de sumas de verificación se realizan en streaming mientras los archivos se copian al repositorio, ya sea que el repositorio esté ubicado local o remotamente.
Si el repositorio está en un host de repositorio, la compresión se realiza en el host de PostgreSQL y los archivos se transmiten en formato comprimido y simplemente se almacenan en el host del repositorio. Cuando la compresión está deshabilitada, se utiliza un nivel de compresión inferior para hacer un uso eficiente del ancho de banda disponible mientras se mantiene el costo de CPU al mínimo.
Restauración delta
El manifiesto contiene sumas de verificación para cada archivo de la copia de seguridad, de modo que durante una restauración es posible utilizar estas sumas de verificación para acelerar enormemente el procesamiento. En una restauración delta, cualquier archivo que no esté presente en la copia de seguridad se elimina primero y luego se generan sumas de verificación para los archivos restantes. Los archivos que coinciden con la copia de seguridad se dejan en su lugar y el resto de los archivos se restauran como de costumbre. El procesamiento en paralelo puede conducir a una reducción drástica en los tiempos de restauración.
Envío y obtención de WAL en paralelo y asíncrono
Se incluyen comandos dedicados para enviar WAL al archivo y obtener WAL del archivo. Ambos comandos admiten paralelismo para acelerar el procesamiento y se ejecutan de forma asíncrona para proporcionar el tiempo de respuesta más rápido posible a PostgreSQL.
El envío de WAL detecta automáticamente los segmentos WAL que se envían varias veces y los deduplica cuando el segmento es idéntico; de lo contrario, se genera un error. El envío de WAL asíncrono permite delegar la transferencia a otro proceso que comprime los segmentos WAL en paralelo para obtener el máximo rendimiento. Esta puede ser una característica crítica para bases de datos con un volumen de escritura extremadamente alto.
La obtención de WAL asíncrona mantiene una cola local de segmentos WAL que se descomprimen y están listos para su reproducción. Esto reduce el tiempo necesario para proporcionar WAL a PostgreSQL, lo que maximiza la velocidad de reproducción. Las conexiones y el almacenamiento de mayor latencia (como S3) son los que más se benefician.
Los comandos de envío y obtención garantizan que la base de datos y el repositorio coincidan comparando las versiones de PostgreSQL y los identificadores del sistema. Esto prácticamente elimina la posibilidad de configurar incorrectamente la ubicación del archivo WAL.