Pasar al contenido principal

pgbackman_new_logo_3_0.png

PgBackMan es una herramienta para administar copias de seguridad lógicas de bases de datos PostgreSQL creadas con pg_dump y pg_dumpall. Esta diseñada para administrar backups de miles de databases ejecutandose en diferentes nodos PostgreSQL con soporte para multiples servidores de backup.

También administra la información relacionada con roles y configuración asociada cuando crea una copia de seguridad de una base de datos. Esta información es necesaria para garantizar una restauración completa de una copia de seguridad lógica y todos los elementos asociados a la misma.

PgBackMan no es una herramienta para administrar copias de seguridad PITR. Existen otras soluciones para administrar estas copias, como por ejemplo PITRTools, OmniPITR, y Barman.

Características principales

  • Base de datos central con los metadatos del sistema.
  • Shell PgBackMan para la interacción con el sistema.
  • Gestión de múltiples servidores de backups.
  • Gestión de múltiples servidores PostgreSQL.
  • Gestión de miles de copias de seguridad a través de un catálogo de copias.
  • Copia de seguridad completa de los datos asociados a los usuarios necesarios en el proceso de recuperacion de un backup.
  • Copia de seguridad completa de los datos de configuración asociados a una base de datos y necesarios en el proceso de recuperación de un backup.
  • Copias de seguridad inmediatas y programadas.
  • Gestión de políticas de retención para las copias de seguridad.
  • Informes detallados de las copias de seguridad.
  • Múltiples tipos de copias de seguridad predefinidos, CLUSTER,FULL,SCHEMA,DATA.
  • Definiciones automáticas de copias de seguridad de todas las bases de datos disponibles en un servidor PostgreSQL.
  • Definiciones automáticas de copias de seguridad de todas las bases de datos sin definiciones en un servidor PostgreSQL.
  • Borrado automático despues de un período de cuarentena de las definiciones de backup de bases de datos que han sido borradas en un nodo PgSQL.
  • Restauración automática de backups.
  • Posibilidad det pausar/reanudar el proceso de replicación en nodos esclavos/standby cuando se estén realizando copias de seguridad grandes.
  • Programa pgbackman_dump autónomo que funciona incluso si la base de datos central con información de metadatos no está disponible.
  • Posibilidad de mandar alertas via SMTP cuando ocurre un error.
  • Manejo de situaciones de error.
  • Programado en Python y PL/pgSQL.
  • Distribuido bajo la GNU General Public License 3.

License

PgBackMan es propiedad de Rafael Martinez Guerrero / PostgreSQL-es y USIT-Universidad de Oslo, y el código fuente es distribuido bajo la licencia GNU General Public License 3.

 

Documentation

El manual de PgBackMan está disponible en los formatos HTML y PDF. El código fuente de la documentación en formato RST está también disponibles en GitHub https://github.com/rafaelma/pgbackman/blob/master/docs/manual_es.rst

Última versión

HTML 1.2.0 PDF 1.2.0

Versiones antiguas

Versión 1.1.0
 

Descargas

El código fuente de PgBackMan está disponible en GitHub y se distribuye bajo la GNU General Public License 3.
También podeis encontrar paquetes RPM y DEB para algunas de las principales distribuciones Linux. Consultar la documentación de PgBackMan para obtener información sobre como instalar y configurar este programa.

Código fuente

Paquetes RPM

Paquetes DEB

 

Soporte

Informes de errores / Peticiones de funcionalidad

Si encontrais un error o quereis realizar una petición de una nueva funcionalidad, podeis registrarlo en GitHub / pgbackman
 

Sobre copias de seguridad en PostgreSQL

Realizar copias de seguridad es una tarea de administración importante que puede tener consecuencias desastrosas si no se realiza adecuadamente. El uso de sistemas RAID en los sistemas de almacenamiento, replicación de datos entre nodos, el uso de clusters y confiar al 100% en que la SAN no fallará NO pueden reemplazar a una buena política de copias de seguridad. Estas medidas son necesarias para implementar sistemas de alta disponibilidad (HA) pero no pueden reemplazar nunca a una copia de seguridad.

Existen dos tipos diferentes de copias de seguridad que pueden ser usadas para implementar una buena política de copias de seguridad y restauración de datos:

  • Copias de seguridad físicas.
  • Copias de seguridad lógicas

Independientemente del tipo de copia de seguridad usada, es necesario tener un buen plan de copias y restauración de datos que tenga en cuenta los intervalos de ejecución de las copias, las políticas de retención de los mismos, los problemas de rendimiento de las copias de seguridad a realizar y el tiempo necesario para realizar una restauración completa de datos a partir de una copia de seguridad.

Copias de seguridad físicas

Este tipo de copia de seguridad copia los archivos donde PostgreSQL graba los datos de las bases de datos. Existen numerosas técnicas y metodos para realizar estas copias físicas de los archivos, que no tienen cabida en este manual. Consultar el capítulo 24 del manual de PostgreSQL, Chapter 24. Backup and Restore, para obtener información sobre estas técnicas.

Lo más importante con las copias de seguridad físicas es que algunos de los métodos que se utilizan para realizarlas junto con el archivo continuo de archivos WAL (write ahead log) se pueden utilizar para implementar PITR (Point in time recovery) y conseguir una solución completa de recuperación de desastres.

Existen numerosas soluciones que se pueden usar para administrar sistemas que implementen PITR, entre ellas PITRTools, OmniPITR y Barman.

Copias de seguridad lógicas

PostgreSQL tiene dos programas, pg_dump y pg_dumpall, que se pueden utilizar para realizar copias de seguridad lógicas de bases de datos PostgreSQL. Estos crean una instantanea (snapshot) de la base de datos en el momento en que se ejecutan.

Estos programas crean copias consistentes de una o todas las bases de datos en el servidor incluso si estas se están utilizando activamente durante la creación de las copias de seguridad. Otra característica a destacar de pg_dump y pg_dumpall es que no bloquean a otros usuarios durante la ejecución de la copia de seguridad, pudiendo estos acceder a los datos sin problemas.

Aunque una copia de seguridad creada con pg_dump o pg_dumpall nunca puede garantizar una recuperación de todos los datos actualizados entre el momento en que la copia se crea y el momento de un futuro desastre con perdida de datos, estas copias son necesarias en numerosos casos, e.g. para archivar versiones de una base de datos, para mover bases de datos entre servidores, para clonar bases de datos entre sistemas de producción, pre-producción y desarrollo, o para extraer una base de datos en particular después de restaurar una copia de seguridad PITR.

De todas maneras, las copias de seguridad lógicas nos proporcionan una gran flexibilidad en numerosas ocasiones y son también una manera fácil de crear copias de seguridad de bases de datos que no necesiten copias de seguridad PITR.

Cuando creamos una copia de seguridad lógica de una base de datos necesitamos la siguiente información para asegurarnos que podremos realizar una restauración completa de los datos:

  1. Esquema (schema) de la base de datos.
  2. Datos grabados en la base de datos.
  3. Roles que sean dueños de objetos en la base de datos.
  4. Roles con privilegios sobre objetos en la base de datos.
  5. Roles con privilegios sobre la base de datos o el esquema.
  6. Como crear todos los roles dueños de objetos o con privilegios.
  7. Paramétros de configuración definidos explícitamente para un rol.
  8. Parámetros de configuración definidos explícitamente para la base de datos.

Desafortunadamente, toda esta información no se puede obtener en una ejecución única para una base de datos. 1, 2, 3 y 4 se pueden obtener con pg_dump. 5, 7 y 8 con pg_dumpall y 6 o con pg_dumpall -r o un pg_dumpall completo.

Al mismo tiempo pg_dumpall retorna toda esta información para todas las bases de datos en un cluster PostgreSQL y no solamente para la base de datos de la cual queremos realizar una copia de seguridad.

Esto es algo que el proyecto PostgreSQL tiene que mejorar en un futuro para que sea más fácil crear copias de seguridad lógicas completas en una única ejecución.

Mientras tanto, PgBackMan tiene cuidado de esto y tiene en cuenta toda la información necesaria para realizar una restauración completa de una base de datos cuando registramos una copia de seguridad en el sistema.