Esta guía rápida presenta varias técnicas y estrategias para la copia de seguridad de PostgreSQL con Bacula Enterprise.
El plugin PostgreSQL está diseñado para simplificar y automatizar el procedimiento de copia de seguridad y restauración de la base de datos o del clúster PostgreSQL sin necesidad de secuencias de comandos complejas. El plugin también hace la copia de seguridad de información esencial, como la definición de los usuarios o los espacios de tabla. El plugin de PostgreSQL soporta tanto la técnica de dump y de Point In Time Recovery (PITR).
Este plugin está disponible para varias plataformas Linux 32/64bit, y soporta oficialmente y soporta versiones de PostgreSQL 8.4, 9.0.x, 9.1.x, 9.2.x y superior.
Instalación
El Plugin PostgreSQL es exclusivo del Bacula Enterprise y puede ser descargado por el repositorio del contratista. Para obtener, hable con nosotros.
Para instalar el paquete suelto, en la máquina que ya tiene el cliente Bacula instalado en la misma versión, por ejemplo:
rpm -ivh bacula-enterprise-postgresql-plugin-8.8.5-1.el7.x86_64.rpm
Reinicie el cliente de Bacula después de instalar el plugin. El comando status client de bconsole debe mostrar que el cliente cargó el plugin correctamente.
El plugin se puede instalar en la misma máquina o cualquier otro con acceso de red al servicio PostgreSQL y también el paquete «postgresql-client», o equivalente. Las herramientas como pg_dump y psql deben estar disponibles, y el plugin utiliza el usuario postgres para acceder a los bancos, sin contraseña.
Esta configuración (que es la predeterminada) se puede hacer con la siguiente entrada en su pg_hba.conf. Esta entrada debe ser la primera en la lista.
local all postgres ident
Si está accediendo a la base de datos remota o no puede desactivar la contraseña método de comunicación, puede establecer la contraseña a través de un archivo pgpass.
Configuración
El plugin del oráculo soporta los métodos: flujo de datos personalizados del Bacula y PITR. En el primero, la restauración de bases de datos y componentes granulares como esquema del banco pueden ser seleccionados directamente y automáticamente por el Bacula, y ciertos bancos pueden ser filtrados de la copia de seguridad, pero la copia de seguridad diferencial e incremental depende de la depuplicación a nivel de bloques del Bacula. En el PITR, la configuración del Archive Log del Postgresql es requerida, proporcionando al DBA también opciones para restaurar transacciones de los bancos en diversos horarios del día, no sólo al realizar la copia de seguridad. Las copias de seguridad diferenciales e incrementales también son nativas en la técnica PITR.
La selección del método de copia de seguridad se realiza a través de las opciones de plugin de FileSet. Gráficamente, como se muestra en la Figura 1.
Figura 1. Edición Opción de Plugin Postgresql en la configuración de FileSet de Bweb.
O en el texto:
FileSet {
Name = FS_postgresql
Include {
Options {
Signature = MD5
}
Plugin = "postgresql: mode=pitr" # ou mode=dump
}
}
Método Stream de Dumps
Sin especificar el modo =, el plugin Postgresql utilizará la técnica de Dumps especial de Bacula, que proporciona mayor granularidad de elementos del banco a la hora del restore, como roles, configuración de postgresql, pg_hba, pg_ident, tablespaces, script de creación del banco , esquema y datos del banco. Si no se desea este particionamiento, basta con usar el modo = dump.
Los dumps del Postresql se almacenan de una manera no estructurada, lo que puede traer pocas ganancias con la deduplicación global. Crear rutinas sort en el banco que clasifiquen las líneas, puede ayudar a promover más bloques iguales y un mejor rendimiento.
Para este método, las opciones de configuración del plugin están disponibles en la Tabla 1.
| Opción | Default | Descripción | Ejemplo |
|---|---|---|---|
| dump_opt | -c -b | Opciones adicionales para pg_dump | dump_opt=»-c» |
| user | postgres | Usuario del sistema operativo utilizado por los comandos | user=heitor |
| service | pg_service utilizado por los comandos | service=main | |
| use_sudo | Utilizar sudo para ejecutar los comandos de postgresql (quand no es root) | use_sudo | |
| compress | 0 | Habilita la compresión del dump por Postgresql (0-9). 0 es apagado, ideal cuando se está utilizando deduplicación | compress=5 |
| database | Copia las bases de datos que se casen con esa cadena. Para más de una cadena, se puede especificar otra línea de configuración del plugin | database=heitor* | |
| bin_dir | Ubicación de los binarios de Postgresql | bin_dir=/opt/pg9.1/bin |
Tabla 1. Opciones de flujo de datos del plugin Postgresql Bacula Enterprise
Stream de Dumps PostgreSQL en Windows
También es posible usar el plugin Postgresql de Bacula en Linux para realizar copias de seguridad de bases de datos instaladas en Windows. Cualquier máquina Linux con Cliente y Plugin de Bacula, además del Cliente de PostgreSQL instalado en una versión similar a la del Servidor Windows puede ser utilizada.
Para ello, debe habilitar el acceso remoto en la configuración del servidor PostgreSQL. En el archivo de configuración postgresql.conf, libere las direcciones para la conexión externa.
# Replace: # listen_addresses = 'localhost' # for listen_addresses = '*'
Modifique también en el servidor el archivo pg_hba.conf para aceptar (trust) conexiones externas confiables desde la IP del Cliente Linux, oa través de una contraseña (md5). La opción es mas fácil de arreglar hasta Bacula later.
host all all 192.168.0.50/0 trust # or host all all 192.168.0.50/0 md5
Recargue la configuración de PostgreSQL en Windows para aplicar los cambios.
En la máquina linux, instale el Cliente y Plugin EBacula, además del Cliente Postgresql (por ejemplo postgresql-client-9.6) si no lo ha hecho. Utilice el comando psql -h ip_server-windowspara probar la conexión.
Ate el nuevo cliente Bacula al Director y configure un FileSet (Edit Plugins) como en el ejemplo:
postgresql: dump_opt="-U postgres -h 192.168.3.253" database="pixprint"
Cree un archivo /etc/pg_service.conf con la configuración de conexión de cada base remota:
[remote1] host=192.168.1.163 port=5432 user=postgres pass=XXXXXX [remote2] host=192.168.1.164 port=5432 user=postgres pass=XXXXXX
Ate el nuevo cliente Bacula al Director y configure un FileSet (Edit Plugins) como en el ejemplo:
postgresql: dump_opt=-a database=mybacula service=remote1
Si prefiere la autenticación por contraseña en pg_hba.conf, debe crear un archivo .pgpass en el hogar del usuario que ejecuta el cliente Bacula (normalmente root) para configurar la contraseña y los parámetros de acceso al banco.
# /root/.pgpass syntax hostname:port:database:username:password
Cree un nuevo trabajo de copia de seguridad utilizando este FileSet, haga una recarga de Bacula para aplicar los cambios y ejecute un trabajo de prueba.Cree un nuevo trabajo de copia de seguridad utilizando este FileSet, haga una recarga del Bacula Director para aplicar los cambios y ejecute un trabajo de prueba.
Mejorando la Deduplicación de los Dumps
Para mejorar los backups con deduplicación de PostgreSQL, puede configurar un proceso CLUSTER de datos para todas las tablas de los bancos o al menos para las mayores.
Para cada tabla de base de datos, configure el CLUSTER de acuerdo con la clave principal o cualquier índice deseado:
select * from pg_indexes where tablename='table'; CLUSTER table USING table_pkey;
En el bweb, agregue una secuencia de comandos Before Job Run Script para el trabajo de PostgreSQL, para ejecutar el comando CLUSTER para cada base de datos:
su - postgres -c "psql -d database1 -c 'cluster verbose'" su - postgres -c "psql -d database2 -c 'cluster verbose'"
Restauración de los Dumps
Como se muestra en la Figura 2, la restauración de una base o de algún componente, se realiza directamente en el navegador de archivos de restauración de las interfaces Bacula.
Figura 2. Selección de componentes de los dumps para la restauración
Para restaurar una base de datos en una instancia de PostgreSQL distinta de la original, primero debe restaurar el esquema, y luego los volcados de creación y de datos de la base.
Método Point-in-Time-Recovery
Para habilitar el modo de archivo Postgresql, desde la versión 9.x, es necesario configurar las directivas archive_command, wal_level y archive_mode en su archivo de configuración Postgresql (normalmente postgresql.conf).
# on 9.0 - 9.x wal_level = archive archive_mode = on archive_command = 'test ! -f /mnt/waldir/%f && cp %p /mnt/waldir/%f'
Cree el directorio especificado en archive_command:
mkdir /mnt/waldir
Opcionalmente, es posible generar el archivo de los registros del Postgresql, con el siguiente archive_command alternativo:
archive_command = 'test ! -f /mnt/waldir/%f.gz && gzip -c %p > /mnt/waldir/%f.gz'
Nota: también puede realizar una copia de seguridad utilizando el wal_level hot_standby del servidor maestro. El servidor esclavo normalmente no es posible, ya que éste debe estar en permanente modo de recuperación.
Reinicie el servicio Postgresql para aplicar los cambios.
Este método requiere que las funciones pg_start_backup y pg_stop_backup sean operativas. Puede probarlas a través de los siguientes comandos de pgsql:
select pg_start_backup('test');
select pg_stop_backup();
El directorio /mnt/waldir debe ser eliminado periódicamente cuando su copia de seguridad tiene éxito y contempla algún período de retención. Un ClientRunAfterJob de Bacula puede hacer esto para archivos mayores de 14 días:
rm -f $(find /mnt/waldir -type f -mtime +14)
La configuración del plugin debe contener la directiva archive_dir debe coincidir con el directorio donde se están grabando los registros.
Para el funcionamiento del método PITR, la opción Accurate (Precisión) del trabajo del Bacula también debe estar habilitada:
Job {
Name = "Postgresql-PITR"
Client = laptop1-fd
FileSet = FS_postgresql
Accurate = yes
...
}
La configuración del plugin, así como la conexión con el banco, puede ser probado con el comando del Bacula:
* estimate listing job=pg-test
Para este método, las siguientes opciones están disponibles en la Tabla 2.
| Opción | Default | Descrición | Ejemplo |
|---|---|---|---|
| mode=pitr | Habilita la copia de seguridad PITR | ||
| archive_dir | pg_xlog | Debe apuntar a donde los WAL están siendo grabados por el archive_command | |
| user | postgres | Usuario del sistema operativo de Postgresql | |
| service | Información de conexión con Postgresql | service=main | |
| pgpass | Ruta al archivo de contraseña de Postgresql, si es necesario | pgpass=/etc/pgpass | |
| bin_dir | Ubicación de los binarios de Postgresql | bin_dir=/opt/pg9.1/bin |
Tabla 2. Opciones de PITR del Plugin Postgresql Bacula Enterprise
Para la restauración:
- Detenga el servicio Postgresql si se está ejecutando.
- Si tiene espacio para ello, copie todo el directorio de datos del clúster y cualquier espacio de tabla a una ubicación temporal, si los necesita posteriormente. Tenga en cuenta que esta precaución requerirá que tenga suficiente espacio libre en el sistema para almacenar dos copias de la base de datos existente. Si no tiene suficiente espacio, necesita al menos copiar el contenido del subdirectorio pg_xlog del directorio de datos del clúster, ya que puede contener registros que no se han archivado antes de que el sistema esté inactivo.
- Limpie todos los archivos y subdirectorios en el directorio de datos del clúster y en los directorios raíz de todos los espacios de tabla que está utilizando.
- Restaure los archivos de la base de datos de su descarga. Si está utilizando tablespaces, debe comprobar que los vínculos simbólicos en pg_tblspc / se han restaurado correctamente. Si es necesario, compruebe la opción de restauración de PrefixLinks.
- Elimine todos los archivos presentes en pg_xlog; estos vinieron de la copia de seguridad y, por lo tanto, son probablemente obsoletos y no actuales. Normalmente, este directorio debe estar vacío.
- Si ha desencadenado los archivos de segmento WAL que guardó en el paso 2, cópielo a pg_xlog /. (Es mejor copiarlos, no moverlos para que todavía tenga los archivos no modificados si se produce un problema y usted tiene que empezar de nuevo).
- Edite el archivo de comandos de recuperación recovery.conf.sample en el directorio de datos del clúster y cámbielo como recovery.conf. También es posible que desee modificar temporalmente el pg_hba.conf para impedir que los usuarios comunes se conecten hasta que esté seguro de que la recuperación ha funcionado.
- Inicie el servidor. El servidor entrará en el modo de recuperación y continuará leyendo los archivos WAL archivados que necesita. Si la recuperación se finaliza debido a un error externo, el servidor sólo se puede reiniciar y continuar la recuperación. Una vez finalizado el proceso de recuperación, el servidor renombra el recovery.conf a recovery.done (para evitar la reintroducción accidental del modo de recuperación en caso de un fallo más adelante) y, a continuación, iniciará las operaciones normales de la base de datos .
su postgres cd /path/to/your/data/directory mv recovery.conf.sample recovery.conf vi recovery.conf pg_ctl -D $PWD start
- Inspeccione el contenido de la base de datos para asegurarse de que se ha recuperado donde desee. Si no, vuelva al paso 1. Si todo está bien, deje a los usuarios acceder a la restauración de pg_hba.conf.
Referências
- PostgreSQL Backup Using Bacula Enterprise Edition – Bacula Systems. http://baculasystems.com
Disponível em: 
Español
