En un plan de recuperación ante desastres, su objetivo de punto de recuperación (RPO) es un parámetro de recuperación clave que determina la cantidad de datos que puede permitirse perder. RPO se enumera en el tiempo, de segundos a días. Efectivamente, RPO depende directamente de su sistema de respaldo. Marca la antigüedad de sus datos de copia de seguridad que debe recuperar para reanudar las operaciones normales.
Si realiza una copia de seguridad nocturna a las 10 p.m. y su sistema de base de datos falla sin posibilidad de reparación a las 3 p.m. al día siguiente, pierde todo lo que se modificó desde su última copia de seguridad. Su RPO en este contexto particular es la copia de seguridad del día anterior, lo que significa que puede darse el lujo de perder los cambios de un día.
El siguiente diagrama de nuestro documento técnico sobre recuperación ante desastres ilustra el concepto.
Sin embargo, para un RPO más estricto, una copia de seguridad podría no ser suficiente. Al hacer una copia de seguridad de su base de datos, en realidad está tomando una instantánea de los datos en un momento dado. Entonces, cuando esté restaurando una copia de seguridad, se perderá los cambios que ocurrieron entre la última copia de seguridad y la falla.
Aquí es donde entra en juego el concepto de recuperación puntual (PITR).
¿Qué es PITR?
Point In Time Recovery (PITR), como su nombre indica, consiste en restaurar la base de datos en cualquier momento del pasado. Para poder hacer esto, necesitaremos restaurar una copia de seguridad y luego aplicar todos los cambios que ocurrieron después de la copia de seguridad hasta justo antes de la falla.
Para PostgreSQL, los cambios se almacenan en los registros de WAL (para obtener más detalles sobre WAL y los datos que almacenan, puede consultar este blog).
Entonces, hay dos cosas que debemos asegurarnos de poder realizar un PITR:las copias de seguridad y los WAL (necesitamos configurar el archivado continuo para ellos).
Para realizar el PITR, necesitaremos recuperar la copia de seguridad y luego aplicar los WAL.
¿Cuándo podría ser útil?
Puede usar esta estrategia siempre que esté restaurando desde un problema que causó que los datos se corrompieran. Debe tener en cuenta que está tratando de minimizar la pérdida de datos, pero hay algunos problemas que pueden hacer que los datos ya no sean útiles después de eso.
Algunos ejemplos de esto pueden ser modificaciones de datos no planificadas (DML o DDL), fallas de medios o mantenimiento de bases de datos (como actualizaciones) que conducen a la corrupción de datos. No podrá recuperar los cambios de datos que ocurrieron después del problema.
Supongamos que un usuario ha realizado incorrectamente un DML, haciendo que los datos de toda una tabla se alteren o eliminen incorrectamente. Puede realizar una PITR de la base de datos en una ubicación separada y luego exportar el contenido de la tabla. Luego puede restaurar esa tabla en la base de datos existente, revirtiendo efectivamente a una copia de cómo estaba la tabla antes de que ocurriera el problema.
Por supuesto, no siempre es posible restaurar solo una parte de la base de datos de esta manera, por lo que en ese caso necesitará restaurar toda la base de datos a un punto determinado y tendrá una pérdida de datos mínima pero inevitable (perderá cualquier cambio que haya ocurrido después de que ocurriera el problema).
¿Cómo usarlo con ClusterControl?
En un blog anterior, pudimos ver cómo implementar PITR manualmente, ahora veamos cómo usar ClusterControl para realizar esta tarea.
Habilitación de la recuperación de un punto en el tiempo
Para habilitar la función PITR, debemos tener habilitado el archivo WAL. Para ello podemos ir a ClusterControl -> Seleccionar Clúster de PostgreSQL -> Acciones de nodo -> Habilitar archivado WAL, o simplemente ir a ClusterControl -> Seleccionar Clúster de PostgreSQL -> Copia de seguridad -> Configuración y habilitar la opción “Habilitar recuperación en un momento dado”. (WAL Archiving)” como veremos en la siguiente imagen.
Debemos tener en cuenta que para habilitar el Archivado WAL, debemos reiniciar nuestra base de datos. ClusterControl también puede hacer esto por nosotros.
Además de las opciones comunes a todas las copias de seguridad como el "Directorio de copia de seguridad" y el "Período de retención de la copia de seguridad", aquí también podemos especificar el Período de retención de WAL. Por defecto es 0, lo que significa para siempre.
Para confirmar que tenemos WAL Archiving habilitado, podemos seleccionar nuestro nodo maestro en ClusterControl -> Select PostgreSQL Cluster -> Nodes, y deberíamos ver el mensaje WAL Archiving Enabled, como podemos ver en la siguiente imagen.
Creación de una copia de seguridad compatible con la recuperación a un momento dado
Teniendo habilitado WAL Archiving, como vimos en el paso anterior, podemos crear nuestra copia de seguridad compatible con PITR. Para ello, vaya a ClusterControl -> Seleccione Clúster de PostgreSQL -> Copia de seguridad -> Crear copia de seguridad.
Podemos crear una nueva copia de seguridad o configurar una programada. Para nuestro ejemplo, crearemos una única copia de seguridad al instante.
Aquí debemos elegir el método “pg_basebackup”, compatible con PITR, el servidor desde el que se realizará la copia de seguridad (para que sea compatible con PITR, debe ser el maestro), y dónde queremos almacenar la copia de seguridad. También podemos subir nuestra copia de seguridad a la nube (AWS, Google o Azure) habilitando el botón correspondiente.
Luego especificamos el uso de compresión, encriptación y la retención de nuestra copia de seguridad.
En la sección de copia de seguridad, podemos ver el progreso de la copia de seguridad e información como el método, el tamaño, la ubicación y más.
Recuperación de un punto en el tiempo a partir de una copia de seguridad
Una vez finalizada la copia de seguridad, podemos restaurarla utilizando la función PITR de ClusterControl. Para ello, en nuestra sección de copias de seguridad (ClusterControl -> Select PostgreSQL Cluster -> Backup), podemos seleccionar "Restaurar copia de seguridad", o directamente "Restaurar" sobre la copia de seguridad que queremos restaurar.
Aquí elegimos qué copia de seguridad queremos restaurar y desde qué directorio.
Dejamos seleccionada la opción “Restaurar en nodo” y continuamos.
Ahora debemos elegir dónde restaurar nuestra copia de seguridad y habilitar la opción PITR. Al especificar el tiempo, será el tiempo hasta que nos recuperemos. Tenga en cuenta que se utiliza la zona horaria UTC y que nuestro servicio de PostgreSQL en el maestro se reiniciará.
Podemos monitorear el progreso de nuestra restauración desde la sección Actividad en nuestro ClusterControl.
Conclusión
PITR es una característica necesaria para cumplir con un RPO ajustado. Necesitamos configurarlo correctamente para garantizar un plan correcto de recuperación ante desastres. ClusterControl proporciona una interfaz fácil de usar para ayudarlo a implementar PITR para sus bases de datos PostgreSQL.
