Si te digo backup físico y backup lógico, backup incremental, backup continuo, backup en frío, backup en caliente, dump SQL, backup selectivo, recuperación selectiva, PITR. ¿Tienes claro en qué consisten? ¿cuándo se usan y cómo?
En este artículo vamos a poner luz sobre los conceptos de PostgreSQL relacionados con las copias de seguridad y recuperaciones porque, si tienes claros todos los conceptos, puedes diseñar una política de backups perfectamente válida para tus bases de datos PostgreSQL.
Lo siguiente será implementar esa política, y para eso necesitas conocer cómo se realizan cada uno de los backups y recuperaciones que vas a ver a continuacón.
Lo primero que tienes que tener claro es qué es un cluster.
En un servidor de bases de datos puedes tener una o varias versiones de PostgreSQL instaladas y con cada una de ellas puedes iniciar una o más instancias.
Una instancia es un servicio de bases de datos levantado en el servidor. En esa instancia pueden haber una o más bases de datos.
Pues bien, en PostgreSQL, un cluster es una instancia de base de datos.
Por otra parte, una base de datos se puede ver desde el punto de vista lógico (es un conjunto de tablas relacionadas entre ellas, vistas sobre esas tablas, claves, restricciones, triggers y otros objetos que son propiedad de usuarios y se almacenan en tablespaces, etc.).
Desde el punto de vista físico, una base de datos también se puede ver como un conjunto de archivos físicos en el sistema de ficheros del sistema operativo.
Todas las técnicas de backup y recuperación se encuentran en un enfoque o en el otro. Vamos a verlas una a una.
Todos los backups lógicos utilizan la técnica SQL Dump que consiste en hacer un recorrido ordenado e inteligente por los objetos de la base de datos y volcar en un fichero las sentencias SQL necesarias para recrearlos. ‘SQL Dump’ significa ‘volcado de SQL’.
Una ventaja de este tipo de backups es que se puede restaurar sobre cualquier instancia, sea cual sea el sistema operativo, arquitectura o versión de PostgreSQL.
Otra ventaja es que los ficheros de backup serán legibles y si lo necesitamos podremos editarlos.
Y otra ventaja es que no necesitamos parar la instancia para realizar el backup con lo cual, el servicio que preste no se verá interrumpido.
Pero no todo son ventajas, obviamente.
La principal desventaja es que no permiten la recuperación hasta un punto en el tiempo. Luego hay otras como el bajo rendimiento para bases de datos grandes, etc.
Para hacer backups de este tipo PostgreSQL facilita dos herramientas:
Con pg_dumpall hacemos backup del cluster completo, por lo tanto no es un backup selectivo.
La recuperación que podemos hacer con este tipo de backup tampoco es selectiva, es una recuperación completa.
Como el fichero de backup es un script SQL podemos utilizar la consola de comandos de PostgreSQL, psql, para realizar la recuperación.
PG_DUMP
Con pg_dump hacemos copias de seguridad de bases de datos (le podremos indicar una o varias) y también de objetos concretos de la base de datos (una o varias tablas, un esquema completo, la estructura de la base de datos sin datos, etc). Por lo tanto, con esta herramienta podemos hacer backup selectivos.
Además, con pg_dump tenemos la opción de especificar el formato de salida del fichero de backup. Por defecto será un script SQL como en el caso anterior. Pero en este caso las recuperaciones no serán selectivas si no que se restaurará todo lo que haya en el fichero de backup.
Aunque, obviamente, al tratarse de un fichero legible y editable siempre podremos extraer lo que nos interesa restaurar. Pero por simplicidad vamos a quedarnos con que un backup lógico y selectivo, en formato SQL, no permite per se (o si quieres, no favorece) la recuperación selectiva.
Para poder hacer recuperaciones selectivas tendrás que elegir alguno de los otros formatos.
Con pg_dump en cualquier formato no-SQL podrás realizar backup selectivos y realizar recuperaciones selectivas si lo necesitas.
En este caso no podrás visualizar ni editar los ficheros de backup ni tampoco utilizar psql para la recuperación. Para hacerlo PostgreSQL proporciona la herramienta pg_restore.
BACKUPS FÍSICOS
Los ficheros físicos no son legibles ni editables y son exclusivos para el sistema de ficheros al que corresponden por lo tanto no será posible recuperar la instancia en otro sistema operativo, arquitectura o versión de PostgreSQL.
Dependiendo de la técnica tendremos que parar la instancia para hacer el backup o no. La posibilidad de hacer recuperaciones hasta un punto en el tiempo también depende de la técnica elegida.
Los backup físicos no permiten backup ni recuperación selectiva.
Las técnicas empleadas son:
FILESYSTEM
Con esta técnica el servicio de PostgreSQL tiene que ser interrumpido, más o menos tiempo dependiendo de la herramienta elegida como veremos a continuación, pero es la única técnica de todas las que hemos visto, y veremos, que requiere la parada del servicio para garantizar una copia consistente de los ficheros físicos.
Y aquí viene el primer inconveniente que no teníamos con los backups lógicos y es que, necesitamos saber cómo está distribuida nuestra instancia por el disco, es decir, saber las rutas físicas de los tablespaces. Por eso, lo primero que tendremos que hacer es averiguarlo y tenerlo en cuenta cada vez que hagamos una copia de este tipo.
Esta técnica tampoco permite recuperaciones hasta un punto en el tiempo.
Las herramientas que se utilizan son:
cp/scp
Como vamos a copiar ficheros físicos utilizamos comandos del sistema operativo.
El proceso consistiría en hacer una parada limpia de la instancia y hacer una copia, local o remota, con cp o scp de todos los ficheros y directorios pertenecientes a la instancia.
No olvides iniciar el servicio de nuevo, y ya lo tenemos.
Imagínate hacer copias de seguridad de este tipo sobre bases de datos que pesen varios TB.
Y si el servicio que presta la base de datos requiere continuidad 24×7, olvida definitivamente esta técnica.
rsync
Con rsync mejoramos los inconvenientes anteriores: la parada del servicio será menor y la copia de seguridad de bases de datos grandes será también más ligera.
rsync es una herramienta para la transferencia de archivos entre una ubicación y otra que puede ser remota. Entre sus múltiples ventajas se encuentra que transfiere solo los archivos, o partes de archivos, que han sido modificados en lugar de transferir el archivo completo nuevamente. Es decir, sólo transfiere los cambios.
Por lo tanto podríamos hacer una copia de seguridad inicial con rsync sin parar el servicio de base de datos. Después, un número determinado de copias incrementales, esta vez con el servicio parado. La primera copia será la más lenta, pero el servicio no tiene que esperar a que ésta acabe para reactivarse. El resto de copias sí requieren inactividad de la instancia pero, como sólo se copiarán los cambios, el tiempo será reducido.
A este tipo de copias se las conoce como copias de seguridad incrementales, o backups incrementales.
Tampoco podemos hacer recuperaciones hasta un punto en el tiempo utilizando la técnica de filesystem y la herramienta rsync.
ARCHIVADO CONTINUO
No requiere la parada del servicio, ni conocer la ubicación de los tablespaces.
Este tipo de backup se conoce también como backup continuo.
La herramienta facilitada por PostgreSQL para hacer este tipo de copias de seguridad es pg_basebackup.
Por último subrayar que todas las recuperaciones requieren parada del servicio y que los backups que necesitan hacerse con la instancia parada se conocen como cold backups (backups en frío) y los que pueden hacerse con la instancia en ejecución se conocen como hot backups (backups en caliente).
Se que es mucha información y mucha terminología pero espero haber conseguido mi propósito y que, lo que antes eran palabras y conceptos sueltos en tu cabeza, ahora se hayan estructurado y por lo tanto la comprensión sea más sencilla.
Si quieres profundizar en las distintas técnicas y herramientas te recomiendo mi curso Administración PostgreSQL: Técnicas de Backup y Recuperación.
Es un curso online de 10 horas de video que capacita para el diseño e implementación de políticas de backup en bases de datos PostgreSQL.
En total son 5 clases teóricas, 28 clases prácticas y 21 talleres avanzados donde se simulan escenarios reales de recuperación ante desastres que sin duda te convertirán en un experto en la materia.
Tendrás acceso de por vida al curso así como a las actualizaciones o ampliaciones que vaya incorporando posteriormente.
A continuación tienes un video donde explico, visualmente y de viva voz, todos los conceptos tratados en este post.