GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

PostgreSQL: Crear un Backup listo para recuperar con pg_basebackup


El presente artículo describe diferentes formas de crear un Backup de PostgreSQL listo para recuperar (Ready to Restore) con el comando pg_basebackup, que implica generar un backup con la información de las transacciones (WAL) necesarias para su recuperación, así como también veremos el procedimiento de recuperación de dichos Backups y podremos identificar las diferencias, ventajas e inconvenientes de cada uno de estos métodos

Breve introducción a pg_basebackup

El comando pg_basebackup permite crear un backup en caliente del sistema de fichero de una Instancia de PostgreSQL (lo que se llama un Backup Base, es decir, el contenido del directorio data) a través de una conexión de base de datos, utilizando el protocolo de replicación.

Como consecuencia de esto, al ejecutar el comando pg_basebackup deberemos especificar los datos de conexión a PostgreSQL (por defecto intentará conectarse a localhost en el puerto 5432 con el usuario actual), en lugar de tener que especificar el directorio data.

Pero además, si no lo hemos hecho antes, deberemos de configurar el fichero pg_hba.conf para permitir la replicación (requiere reiniciar la Instancia para que tome efecto), ya que por defecto viene deshabilitado, y en estas condiciones si intentamos ejecutar el comando pg_basebackup podríamos obtener un error como el siguiente: pg_basebackup: could not connect to server: FATAL:  no pg_hba.conf entry for replication connection from host "[local]", user "postgres", SSL off

Además, el comando pg_basebackup utiliza al menos una sesión de WAL Senders, por lo que si no lo hemos hecho antes, deberemos configurar el fichero postgresql.conf para establecer un valor correcto del parámetro max_wal_senders (requiere reiniciar la Instancia para que tome efecto), ya que por defecto su valor es cero (la replicación está deshabilitada). De lo contrario, al intentar utilizar el comando pg_basebackup podríamos obtener un error como el siguiente: pg_basebackup: could not connect to server: FATAL:  number of requested standby connections exceeds max_wal_senders (currently 0)

Hay que tener en cuenta que el comando pg_basebackp utiliza una conexión, por lo que si no estamos utilizando la replicación (como en nuestro caso de ejemplo), con establecer max_wal_senders a 1 es más que suficiente. Sin embargo, si deseamos utilizar la opción --xlog-method=stream para incluir las transacciones (WAL) en nuestro Backup sin tener problemas de rotados de WAL, necesitaremos establecer una segunda conexión de replicación, por lo que deberemos aumentar  el valor de max_wal_senders (por ejemplo a 2, en nuestro caso de ejemplo que no utilizamos la replicación).

El comando pg_basebackup puede verse como una evolución de la forma tradicional de hacer Backup, resultando más sencillo, ya que ahora con un único comando obtenemos nuestro Backup, sin tener que invocar manualmente a las funciones pg_start_backup y pg_stop_backup, para adicionalmente hacer la copia de ficheros. En cualquier caso, antes de continuar con la lectura del presente artículo, es muy recomendable leer el artículo anterior PostgreSQL: Hot Physical Backup and Restore

Descripción del Escenario

Partimos de una instalación del PostgreSQL 9.2.18 con archivado de WAL comprimido sobre Centos7 utilizando únicamente los tablespaces por defecto. Las principales rutas son las siguientes:

  • Directorio Data: /var/lib/pgsql/data
  • Directorio Archivado de WAL comprimido: /var/lib/pgsql/PostgresqlWalCompr
  • Directorio para almacenar los Backups: /var/lib/pgsql/PostgresqlBackup

La configuración del archivado de WAL en el fichero postgresql.conf es la siguiente:

wal_level = archive
archive_mode = on
archive_command = '/usr/local/bin/omnipitr-archive -D /var/lib/pgsql/data -l /var/log/wal/wal.log -dl gzip=/var/lib/pgsql/PostgresqlWalCompr -v "%p"'

Sobre este escenario, vamos a realizar las pruebas que detallamos a continuación.

Backup listo para recuperar (Ready to Restore) a un directorio con pg_basebackup copiando los WAL al final (-x), ojo con wal_keep_segments

El comando pg_basebackup por defecto no incluye el contenido del directorio pg_log, es decir, no incluye los WAL, por lo que el backup generado no será recuperable por sí sólo y necesitaremos adicionalmente tener Backup de los WAL para poder restaurar con éxito (habitualmente de los WAL archivados).

Sin embargo, es posible hacer un Backup recuperable por sí solo (ready to restore) con pg_basebackup utilizando la opción -x, que incluirá la información de los WAL (directorio pg_log), y así evitaremos dependencias con el archivado de los WAL y simplificaremos el proceso de backup y de recuperación.

IMPORTANTE: Al utilizar la opción -x los WAL son recopilados al final del Backup, por lo tanto, el parámetro de configuración wal_keep_segments debe tener un valor suficientemente alto para que los WAL no sean eliminados/archivados antes de que finalice el Backup.

A continuación podemos ver un comando de ejemplo.

cd /var/lib/pgsql
pg_basebackup -l "Daily Backup" -x -D ./PostgresqlBackup/pg_basebackup

La ejecución del anterior comando creará un directorio con la copia del directorio data, así como con la información de los WAL necesarios para la recuperación, tal y como se puede observar en el siguiente pantallazo.

El proceso de recuperación es muy sencillo. Parar PostgreSQL, eliminar o mover el directorio data actual, copiar o mover el directorio data del Backup, y arrancar PostgreSQL. La siguiente secuencia de comandos sería un ejemplo práctico.

pg_ctl -D /var/lib/pgsql/data -m fast stop
cd /var/lib/pgsql
mkdir ./data.old
mv /var/lib/pgsql/data/* /var/lib/pgsql/data.old/
cp -r ./PostgresqlBackup/pg_basebackup/* ./data/
pg_ctl -D /var/lib/pgsql/data start

Backup listo para recuperar (Ready to Restore) a un tar comprimido con pg_basebackup copiando los WAL al final (-x), ojo con wal_keep_segments

Hacer un backup a un directorio tiene el inconveniente de que el tamaño del Backup puede ser demasiado grande, por lo que habitualmente se prefiere hacer el backup a un fichero tar comprimido (ej: tar.gz), de tal modo que podamos minimizar el espacio en disco necesario, así como el tiempo de transferencia del Backup en caso de tener que copiarlo. De nuevo, vamos a utilizar la opción -x (ojo con wal_keep_segments) para realizar la copia de los WAL al final del Backup. La única diferencia, es que en este caso, haremos el Backup a un tar comprimido. A continuación se puede ver un ejemplo del comando a ejecutar.

cd /var/lib/pgsql
pg_basebackup -l "Daily Backup" -x -D ./PostgresqlBackup/pg_basebackup -Ft -z

La siguiente pantalla capturada muestra la salida de ejecución del anterior comando. Como podemos observar, se ha generado un fichero comprimido con nombre base.tar.gz.

El proceso de recuperación es similar al caso anterior, en el que hicimos el Backup a un directorio, pero incluyendo algún paso adicional para descomprimir y borrar después el fichero tar.gz. A continuación se muestra una secuencia de comandos de ejemplo.

pg_ctl -D /var/lib/pgsql/data -m fast stop
cd /var/lib/pgsql
mkdir ./data.old
mv /var/lib/pgsql/data/* /var/lib/pgsql/data.old/
cp ./PostgresqlBackup/pg_basebackup/base.tar.gz ./data/
cd data
tar -xvf base.tar.gz
rm base.tar.gz
pg_ctl -D /var/lib/pgsql/data start

En la siguiente pantalla capturada se puede observar el resultado de ejecución de la anterior secuencia de comandos (hemos omitido la opción verbose al descomprimir el tar, para que quede más claro).

Backup listo para recuperar (Ready to Restore) a un directorio con pg_basebackup copiando los WAL por streaming (evitando problemas de wal_keep_segments)

En los ejemplos anteriores veíamos como crear un Backup listo para recuperar (Ready to Restore) con pg_basebackup utilizando la opción -x para copiar los WAL al final del Backup, lo cual nos permite tanto hacer un Backup a un directorio como a un tar comprimido. Sin embargo, tiene el inconveniente de que podríamos tener problemas derivados del rotado de WALs de tal modo que nos falte algún fichero WAL en nuestro Backup, en cuyo caso no podríamos recuperarlo con éxito (excepto con una intervención manual en la que necesitaríamos los WAL), situación que podríamos intentar evitar ajustando el valor de configuración del parámetro wal_keep_segments.

Una alternativa para conseguir un Backup listo para recuperar (con información de los WAL) sin depender del parámetro wal_keep_segments (evitando el riesgo derivado del rotado de los WAL) es utilizar la opción --xlog-method=stream. Al utilizar esta opción, el comando pg_basebackup crea una conexión secundaria para obtener los WAL necesarios por streaming, de tal modo que obtendremos un Backup completo que incluirá la información de todas las transacciones necesarias para su recuperación. El principal inconveniente, que sólo es posible realizar el Backup a un directorio, es decir, no es posible hacer el Backup a un tar ni a un tar comprimido. A continuación se muestra un comando de ejemplo, incluyendo la opción -P para informar del progreso del backup.

cd /var/lib/pgsql
pg_basebackup -l "Daily Backup" --xlog-method=stream -D ./PostgresqlBackup/pg_basebackup -P

La siguiente pantalla capturada muestra un ejemplo de ejecución del anterior comando de Backup.

El procedimiento de recuperación es el mismo que ya vimos anteriormente para la recuperación desde un Backup a directorio. Igualmente, no es necesario preparar el fichero recovery.conf. En resumidas cuentas, paramos PostgreSQL, copiamos ficheros, arrancamos, y ya está. A continuación mostramos una secuecuencia de comandos de ejemplo.

pg_ctl -D /var/lib/pgsql/data -m fast stop
cd /var/lib/pgsql
mkdir ./data.old
mv /var/lib/pgsql/data/* /var/lib/pgsql/data.old/
cp -r ./PostgresqlBackup/pg_basebackup/* ./data/
pg_ctl -D /var/lib/pgsql/data start

Despedida y Cierre

Hasta aquí llega el presente artículo, en el que hemos podido ver las diferentes alternativas para crear un Backup listo para recuperar (Ready to Restore) con el comando pg_basebackup. Antes de finalizar aprovecho para compartir varios enlaces de interés, para quien desee ampliar más información:

Poco más por hoy. Como siempre, confío que la lectura resulte de interés.

 


]
[Autor: GuilleSQL]



Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Marzo de 2019 (1)
Octubre de 2018 (1)
Julio de 2018 (1)
Junio de 2018 (4)
Mayo de 2018 (5)
Abril de 2018 (3)
Marzo de 2018 (2)
Febrero de 2018 (7)
Enero de 2018 (1)
Diciembre de 2017 (15)
Noviembre de 2017 (7)
Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Copyright © 2007 GuilleSQL, todos los derechos reservados.