El estado actual de la gestión de copias de seguridad de código abierto para PostgreSQL

Hay muchas formas de abordar la realización de copias de seguridad de un clúster de PostgreSQL. Hay varios artículos y blogs que presentan las diversas tecnologías mediante las cuales podemos guardar nuestros valiosos datos en PostgreSQL. Existen soluciones de copia de seguridad lógica, copia de seguridad física a nivel del sistema operativo, a nivel del sistema de archivos, etc. Aquí en este blog no vamos a cubrir la parte teórica que está adecuadamente cubierta por varios blogs y artículos, así como la documentación oficial.

Este blog se centra en el estado de las diversas herramientas y soluciones disponibles y en un esfuerzo por presentar una comparación exhaustiva basada en experiencias de la vida real. Este artículo de ninguna manera intenta promocionar ningún producto específico, realmente me gustan todas las herramientas, soluciones y tecnologías descritas en este blog. El objetivo aquí es anotar sus fortalezas, sus debilidades y guiar al usuario final sobre qué herramienta se adapta mejor a su entorno, infraestructura y requisitos específicos. Aquí hay un buen artículo que describe las herramientas de respaldo para PostgreSQL en varios niveles.

No describiré cómo usar las diversas herramientas en este blog, ya que esta información está documentada en el blog anterior y también en los documentos oficiales, así como en otros recursos en la red. Pero describiré los pros y los contras tal como los experimenté en la práctica. En este blog, nos ocupamos exclusivamente de las copias de seguridad clásicas de PostgreSQL físicas basadas en PITR que dependen de:

• pg_basebackup o pg_start_backup()/pg_stop_backup
• copia física
• archivo de WAL o replicación de transmisión

Hay varios productos y soluciones excelentes, algunos son de código abierto y de uso gratuito, mientras que otros son comerciales. Hasta donde yo sé, esos son:

• pgbarman por 2ndquadrant (gratis)
• pgbackrest (gratis)
• pg_probackup de Postgres Professional (gratis)
• BART de EDB (comercial)

No tuve la oportunidad de probar BART ya que se ejecuta en versiones de Linux que no uso. En este blog, incluiré mis propios pensamientos e impresiones mientras interactúo con los respectivos autores/comunidad/mantenedores de cada solución, ya que este es un aspecto muy importante que generalmente se subestima al principio. Un poco de terminología para comprender mejor los diversos términos en cada una de las herramientas:

pgbarman

Pgbarman o simplemente barman es la más antigua de esas herramientas. La última versión es la 2.6 (¡lanzada mientras estaba trabajando en este blog!, lo cual es una gran noticia).

Pgbarman admite la copia de seguridad base a través de dos métodos:

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

y transferencia WAL a través de:

• Archivo WAL
  • a través de rsync
  • a través de barman-wal-archive / put-wal
• WAL mediante replicación de transmisión con ranura de replicación
  • Asíncrono
  • Sincrónico

Esto nos da 8 combinaciones listas para usar en las que podemos usar barman. Cada uno tiene sus pros y sus contras.

Copia de seguridad base a través de pg_basebackup (backup_method =postgres)

Ventajas:

• la forma más nueva/moderna
• se basa en la tecnología central probada de PostgreSQL
• recomendado por los documentos oficiales

Contras:

• sin copia de seguridad incremental
• sin copia de seguridad paralela
• sin compresión de red
• sin deduplicación de datos
• sin límite de ancho de banda de red

Copia de seguridad base a través de rsync (backup_method =rsync)

Ventajas:

• antiguo y probado
• Copia de seguridad incremental
• deduplicación de datos
• compresión de red
• copia de seguridad en paralelo
• límite de ancho de banda de red

Contras:

• no es la forma recomendada (por los autores)

Transferencia WAL a través de archivo WAL (a través de rsync)

Ventajas:

• más fácil de configurar

Contras:

• Sin RPO=0 (cero pérdida de datos)
• no hay forma de recuperarse de fallas de red prolongadas y persistentes

Transferencia WAL a través del archivo WAL (a través de barman-wal-archive / put-wal)

Ventajas:

• la forma más reciente y recomendada (introducida en 2.6)
• más confiable/seguro que rsync

Contras:

• Sin RPO=0 (cero pérdida de datos)
• todavía no hay forma de recuperarse de fallas de red prolongadas y persistentes

Transferencia WAL a través de transmisión WAL con ranura de replicación (a través de pg_receivewal)

Ventajas:

• más moderno (y recomendado)
• RPO=0 (cero pérdida de datos) en modo síncrono

Contras:

• siempre asociado con la ranura de replicación. Podría crecer en caso de fallas en la red

Entonces, aunque pg_basebackup (método postgres) parece ser el futuro de pgbarman, en realidad, todas las características sofisticadas vienen con el método rsync. Entonces, enumeremos todas las características de Barman con más detalle:

• Operación remota (copias de seguridad/restauración)
• Copias de seguridad incrementales. Una de las grandes características de barman, las copias de seguridad incrementales se basan en la comparación del nivel de archivo de los archivos de la base de datos con los de la última copia de seguridad del catálogo. En barman, el término "diferencial" se refiere a un concepto diferente:según la terminología de barman, una copia de seguridad diferencial es la última copia de seguridad + los cambios individuales desde la última copia de seguridad. Los documentos de Barman dicen que proporcionan copias de seguridad diferenciales a través de WAL. Las copias de seguridad incrementales de Barman funcionan a nivel de archivo, lo que significa que si se cambia un archivo, se transfiere todo el archivo. Esto es como pgbackrest y a diferencia de otras ofertas como pg_probackup o BART que admiten copias de seguridad incrementales/diferenciales a nivel de bloque. Las copias de seguridad incrementales de Barman se especifican a través de:reuse_backup =enlace o copia. Al definir "copiar", logramos una reducción del tiempo de la copia de seguridad, ya que solo se transfieren y se respaldan los archivos modificados, pero aún no se reduce el espacio, ya que los archivos sin cambios se copian de la copia de seguridad anterior. Al definir "enlace", los archivos sin cambios se vinculan (no se copian) desde la última copia de seguridad. De esta manera conseguimos tanto la reducción de tiempo como la reducción de espacio. De ninguna manera quiero crear más confusión en esto, pero en realidad, las copias de seguridad incrementales de barman son directamente comparables con las copias de seguridad incrementales de pgbackrest, ya que barman trata (a través de un enlace o copia) una copia de seguridad incremental de manera efectiva como una copia de seguridad completa. Entonces, en ambos sistemas, una copia de seguridad incremental se ocupa de los archivos que se modificaron desde la última copia de seguridad. Sin embargo, con respecto a las copias de seguridad diferenciales, significa algo diferente en cada uno de los sistemas mencionados, como veremos a continuación.
• Copia de seguridad desde el modo de espera. Barman ofrece la opción de realizar la mayor parte de las operaciones de copia de seguridad base desde un modo de espera, liberando así al principal de la carga de E/S añadida. Sin embargo, tenga en cuenta que aún los WAL deben provenir del primario. No importa si usa archive_command o transmisión WAL a través de ranuras de replicación, aún no puede (a partir de este escrito con barman en la versión 2.6) descargar esta tarea al modo de espera.
• trabajos paralelos para copia de seguridad y recuperación
• Un conjunto rico y completo de configuración de retención basado en:
  • Redundancia (número de copias de seguridad a conservar)
  • Ventana de recuperación (cómo se deben guardar las copias de seguridad en el pasado)
  En mi opinión, desde la perspectiva del usuario, lo anterior es excelente. El usuario puede definir reuse_backup =link y una ventana de recuperación y dejar que barman (su trabajo cron) se ocupe del resto. No hay que preocuparse por las copias de seguridad diff/incr/full, etc., programarlas o administrarlas. El sistema (barman) simplemente hace lo correcto de manera transparente.
• Programación de sus propios scripts de gancho antes y después del evento.
• Reasignación de espacios de tabla

Esas son las mejores fortalezas del barman. Y realmente esto es casi más de lo que el DBA promedio pediría de una herramienta de copia de seguridad y recuperación. Sin embargo, hay algunos puntos que podrían ser mejores:

• La lista de correo no es tan activa y los mantenedores rara vez escriben o responden preguntas
• No hay función para reanudar una copia de seguridad fallida o interrumpida
• Las ranuras de replicación o el uso de rsync/barman-wal-archive para archivar no perdonan en caso de fallas en la red u otras fallas del sitio de copia de seguridad. En cualquier caso, si la interrupción de la red es lo suficientemente prolongada y los cambios en la base de datos valen una gran cantidad de archivos WAL, entonces el principal sufrirá que "no quede espacio en el dispositivo" y eventualmente colapsará. (no es algo bueno). Lo que es prometedor aquí es que barman ahora proporciona una forma alternativa (a rsync) de transferir WAL para que la protección adicional contra, p. El agotamiento del espacio pg_wal podría implementarse en el futuro, lo que junto con el currículum de respaldo realmente haría que el barman fuera perfecto, al menos para mí.

pgrespaldo

Pgbackrest es la tendencia actual entre las herramientas de copia de seguridad de código abierto, principalmente por su eficiencia para hacer frente a grandes volúmenes de datos y el extremo cuidado que sus creadores ponen en la validación de copias de seguridad a través de sumas de verificación. Al momento de escribir este artículo, se encuentra en la versión v2.09, y los documentos se encuentran aquí. La Guía del usuario puede estar un poco desactualizada, pero el resto de los documentos están muy actualizados y son precisos. Pgbackrest se basa en el archivado WAL utilizando su propio archive_command y su propio mecanismo de transferencia de archivos, que es mejor y más seguro que rsync. Por lo tanto, pgbackrest es bastante avanzado, ya que no ofrece el conjunto más amplio de opciones que ofrece barman. Dado que no hay un modo síncrono involucrado, naturalmente, pgbackrest no garantiza RPO =0 (pérdida de datos cero). Describamos los conceptos de pgbackrest:

• Una copia de seguridad puede ser:
  • Lleno. Una copia de seguridad completa copia todo el clúster de la base de datos.
  • Diferencial (diff). Una copia de seguridad diferencial copia solo los archivos que se modificaron desde la última copia de seguridad completa. Para una restauración exitosa, tanto la copia de seguridad diferencial como la copia de seguridad completa anterior deben ser válidas.
  • Incremental (incr). Una copia de seguridad incremental copia solo los archivos que se modificaron desde la última copia de seguridad (que puede ser una copia de seguridad completa, diferencial o incluso incremental). De manera similar a la copia de seguridad diferencial, para realizar una restauración exitosa, todas las copias de seguridad anteriores requeridas (incluida esta copia de seguridad, la última diferencia y la anterior completa) deben ser válidas.
• Una estrofa es la definición de todos los parámetros necesarios de un clúster de PostgreSQL. Un servidor PostgreSQL normal tiene su propia estrofa, mientras que los servidores de respaldo tendrán una estrofa para cada clúster de PostgreSQL del que respaldan.
• Una configuración es donde se guarda la información sobre las estrofas (normalmente /etc/pgbackrest.conf)
• Un repositorio es donde pgbackrest guarda WAL y copias de seguridad

Se anima al usuario a seguir la documentación como sugiere la propia documentación, de arriba a abajo. Las características más importantes de pgbackrest son:

• Copia de seguridad y restauración en paralelo
• No se necesita acceso SQL directo al servidor PostgreSQL
• Operación local/remota
• Retención basada en:
  • retención de copias de seguridad completas (cantidad de copias de seguridad completas para conservar)
  • retención de copias de seguridad de diferencias (cantidad de copias de seguridad de diferencias que se deben conservar)
  Las copias de seguridad incrementales no tienen su propia retención y caducan tan pronto como caduca una copia de seguridad anterior. De modo que el usuario puede definir un programa para realizar copias de seguridad completas y un conjunto continuo de copias de seguridad diferentes entre ellas.
• Copia de seguridad desde el modo de espera. Algunos archivos aún deben provenir del principal, pero la copia masiva se realiza en el modo de espera. Aún así, los WAL deben originarse en el primario.
• Integridad de la copia de seguridad. Las personas detrás de pgbackrest son extremadamente cuidadosas cuando se trata de la integridad de las copias de seguridad. Se realiza una suma de comprobación de cada archivo en el momento de la copia de seguridad y también se comprueba después de la restauración para asegurarse de que ningún error problemático de hardware o software pueda dar lugar a una restauración defectuosa. Además, si las sumas de comprobación a nivel de página están habilitadas en el clúster de PostgreSQL, también se calculan para cada archivo. Además, se calculan sumas de comprobación para cada archivo WAL.
• Si la compresión está deshabilitada y los enlaces físicos están habilitados, es posible abrir el clúster directamente desde el catálogo. Esto es extremadamente importante para bases de datos grandes de varios TB.
• Resumen de una devolución fallida/interrumpida. Muy útil en caso de redes poco fiables.
• Restauración delta:restauración ultrarrápida para grandes bases de datos, sin limpiar todo el clúster.
• Envío WAL asíncrono y paralelo al servidor de respaldo. Este es uno de los puntos más fuertes de pgbackrest. El archivador PostgreSQL solo copia en el spool a través de archive-push y el trabajo pesado de la transferencia y el procesamiento ocurre en un proceso pgbackrest separado. Esto permite transferencias WAL masivas al tiempo que garantiza tiempos de respuesta bajos de PostgreSQL.
• Reasignación de espacios de tabla
• Compatibilidad con Amazon S3
• Compatibilidad con el tamaño máximo de WAL en cola. Cuando el sitio de respaldo está inactivo o la red está fallando, el uso de esta opción simulará que el archivado fue exitoso, lo que permite que PostgreSQL elimine WAL evitando que se llene pg_wal y, por lo tanto, salva al servidor pgsql de un PÁNICO potencial.

Por lo tanto, pgbackrest en cuanto a características pone mucho énfasis en lo que respecta a la validación y el rendimiento de los datos, no sorprende que lo utilicen las instalaciones de PostgreSQL más grandes y concurridas. Sin embargo, hay una cosa que podría mejorarse:

• Sería muy útil tener una opción más "liberal" en lo que respecta a la retención, es decir, proporcionar una forma declarativa de especificar algún período de retención y luego dejar que pgbackrest se ocupe de las copias de seguridad completas/diferenciadas/aumentadas según sea necesario.

pg_probackup

Pg_proback es otra herramienta prometedora para copias de seguridad. Originalmente se basa en pg_arman. Su énfasis está en el rendimiento de la copia de seguridad. Se basa en catálogos, e instancias, muy similar al resto de herramientas, por lo que tenemos. Sus características principales incluyen:

• Respaldo enriquecido de nivel de copia de seguridad que va desde:
  • Copias de seguridad completas
  • Incremental de tres tipos:
    • Copia de seguridad de la PÁGINA. Cambios de nivel encontrados a través del escaneo WAL. Requiere acceso completo a la secuencia WAL ininterrumpida desde la copia de seguridad anterior.
    • Copia de seguridad DELTA. Solo las páginas modificadas se copian en la copia de seguridad. Independiente del archivo WAL, pone cierta carga en el servidor.
    • Copia de seguridad PTRACK. Requiere un parche central especial de pgsql. Funciona manteniendo un mapa de bits sobre la marcha tan pronto como se modifican las páginas. Copia de seguridad realmente rápida con una carga mínima en el servidor.
• Las copias de seguridad también se pueden dividir en:
  • Copias de seguridad autónomas. Esos no tienen requisitos en WAL fuera de la copia de seguridad. Sin PITR.
  • Archivar copias de seguridad. Estos se basan en el archivado continuo y son compatibles con PITR.
• modelo multiproceso (en contraste con barman, pgbackrest y, por supuesto, el mismo PostgreSQL que sigue un modelo multiproceso)
• Coherencia de datos y validación bajo demanda sin restauración
• Copia de seguridad desde un modo de espera sin acceso al primario.
• Una especificación de política de retención expresiva en la que se puede usar la redundancia en forma de Y junto con la ventana. La combinación de copias de seguridad (a través de la combinación) se admite mediante la conversión de copias de seguridad incrementales anteriores a completas como una forma de liberar espacio y proporcionar un método para una rotación de copias de seguridad sin problemas.

Por lo tanto, pg_probackup proporciona un conjunto de excelentes funciones con énfasis en el rendimiento, algo que beneficiaría a las grandes instalaciones. Sin embargo, todavía faltan algunas cosas, a saber:

• Ninguna versión oficial admite copias de seguridad remotas. Esto significa que pg_probackup debe ejecutarse en el mismo host que el clúster de pgsql. (Hay una rama de desarrollo que se ocupa de la copia de seguridad desde un sitio remoto, así como del archivado en un servidor de copia de seguridad remoto)
• No hay soporte para un currículum de copia de seguridad fallido.

Podemos resumir los párrafos anteriores con una matriz de funciones como la siguiente.

Control de clúster

ClusterControl brinda la funcionalidad ya sea para generar una copia de seguridad inmediata o para programarla y automatizar la tarea de una manera simple y rápida.

Podemos elegir entre dos métodos de copia de seguridad, pgdump (lógico) y pg_basebackup (binario). También podemos especificar dónde almacenar las copias de seguridad (en el servidor de la base de datos, en el servidor de ClusterControl o en la nube), el nivel de compresión y el cifrado.

Además, con ClusterControl podemos usar la función de recuperación de un momento dado y la verificación de la copia de seguridad para validar la copia de seguridad generada.