Hacer una copia de seguridad de PostgreSQL es uno de los requisitos esenciales para proteger y recuperar la base de datos de situaciones catastróficas como la caída del servidor, la caída de la base de datos o la corrupción.

No importa si está ejecutando su base de datos en docker, VM o en la nube, la copia de seguridad de una base de datos es importante.

Dicho esto, decidir la estrategia de copia de seguridad de PostgreSQL y recuperación para la organización o el individuo puede ser un punto de dolor. Ciertamente, requiere una comprensión de su aplicación, negocio y costo.

Aprendamos por dónde empezar y cómo elegir una estrategia de respaldo de copia de seguridad de PostgreSQL.

También puedes ver ¡Cómo monitorear PostgreSQL como todo un jefe!. 

Vamos a adentrarnos, Aquí hay una situación:

Una aplicación de comercio electrónico que tiene PostgreSQL como backend.

El tamaño de su base de datos no es grande, es alrededor de 100GB.

La mayoría de nuestros usuarios están activos hasta las 7 de la tarde y no se accede a ella durante las 24 horas.

Hacemos una copia de seguridad de PostgreSQL lógica completa, seria todas las noches a las 12 AM, que toma alrededor de 2 horas de tiempo que es razonable y luego ejecutamos algunas operaciones diarias de la base de datos.

Supongamos que el lunes por la mañana, a las 10 am, tuvimos una caída del sistema, el disco de datos desapareció.

La única opción que tenemos es recrear la base de datos desde cero y restaurarla desde la copia de seguridad utilizando la copia de seguridad lógica.

La copia de seguridad de PostgreSQL tardara unas 3 horas en restaurar la base de datos. Haciendo algunas tareas domésticas, pruebas funcionales básicas y la aplicación estuvo disponible para los usuarios a las 2 de la tarde.

Permítanme hacer hincapié en dos puntos en la copia de seguridad de PostgreSQL:

  1. La base de datos se restauró a partir de la copia de seguridad de la noche anterior. 10 horas de pérdida de datos. -> ¿Importa cuántos datos se pierden o hasta qué punto se pueden recuperar?
  2. 4 horas de inactividad de la aplicación. -> ¿Qué tan rápido se puede recuperar la base de datos y poner la aplicación en línea?

¿Qué es el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO)?

El objetivo de punto de recuperación es una medida de la cantidad máxima tolerable de datos a perder.

También ayuda medir cuánto tiempo puede transcurrir entre la última copia de seguridad de los datos y un desastre sin causar graves daños a la empresa.

El RPO es útil para determinar la frecuencia con la que se debe realizar la copia de seguridad de PostgreSQL.

El RPO es importante porque en la mayoría de los casos, es probable que se pierdan algunos datos cuando ocurre un desastre.

Incluso los datos de los que se hace una copia de seguridad en tiempo real tienen un riesgo de pérdida de datos.

La mayoría de las empresas realizan copias de seguridad de los datos a intervalos de tiempo fijos: una vez cada hora, una vez al día o quizás con tan poca frecuencia como una vez a la semana.

El RPO mide la cantidad de datos que puede permitirse perder como resultado de un desastre.

Por ejemplo, imagine que hace una copia de seguridad de PostgreSQL una vez al día a medianoche y que se produce un desastre a las ocho de la mañana. En ese caso, perderías ocho horas de datos.

Si tu RPO es de veinticuatro horas o más, estás en buena forma. Pero si tu RPO es, por ejemplo, de cuatro horas, no lo estás.

Objetivo de tiempo de recuperación (RTO):

El objetivo de tiempo de recuperación es una métrica que ayuda a calcular la rapidez con la que necesita recuperar su aplicación (aplicación + base de datos) y sus servicios tras un desastre para mantener la continuidad del negocio.

El RTO se mide en términos de cuánto tiempo puede sobrevivir su empresa tras un desastre antes de que las operaciones vuelvan a la normalidad.

Si su RTO es de veinticuatro horas, significa que ha determinado que la empresa puede mantener las operaciones durante ese tiempo sin disponer de sus datos e infraestructura normales.

Si los datos y la infraestructura no se recuperan en veinticuatro horas, la empresa podría sufrir un daño irreparable.

Dependiendo de cuál sea su objetivo (en términos de RPO y RTO) tiene que decidir su estrategia de copia de seguridad de PostgreSQL.

Una de las cosas clave a recordar es que su estrategia de copia de seguridad PostgreSQL incluye:

Método para tomar una copia de seguridad (en línea, fuera de línea, lógica)

Frecuencia de la copia de seguridad PostgreSQL (semanal, diaria, cada hora)

En el escenario que he mencionado si quisiéramos recuperar la base de datos con la mínima pérdida de datos podríamos haber utilizado la siguiente estrategia

Habilitar el archivado (almacenar la WAL en una ubicación segura)

Copia de seguridad completa de PostgreSQL en línea (PITR) con copia de seguridad incremental/archivo.

Copia de seguridad completa semanal

Incremental diario-medianoche

Podríamos haber utilizado la recuperación puntual restaurando la base de datos a partir de una copia de seguridad completa y luego aplicando incrementales (WALs archivados) hasta el último punto.

Estrategia de copia de seguridad de PostgreSQL más común (basada en el entorno)

Siendo ingeniero de bases de datos durante la mayor parte de mi experiencia profesional me he dado cuenta de que NO es prudente definir su estrategia de copia de seguridad sólo en función del tamaño de la base de datos.

Si bien es una buena idea combinar tanto el backup online como el lógico (pg_dump/pg_dumpall) para ciertas situaciones.

Sin embargo, se debe pensar bien qué tipo de datos son y cuánto se está dispuesto a perder en caso de situaciones catastróficas.

  1. Copia de seguridad semanal en línea y copias de seguridad incrementales diarias para las bases de datos de misión crítica y de producción.
  2. Copia de seguridad lógica para bases de datos no críticas o de desarrollo- Frecuencia – Semanal o quincenal.

Métodos alternativos de copia de seguridad

Uno de los métodos más comunes y más utilizados es tomar una copia de seguridad de PostgreSQL en línea es pg_basebackup.

Tambien realizar la copia de seguridad a nivel de sistema de archivos (copiar el directorio de datos) después de poner la DB en modo de copia de seguridad.

Sin embargo, una instantánea a nivel de disco es otra forma si está utilizando el gestor de almacenamiento para su disco subyacente.

Las instantáneas de volumen son mucho más rápidas y extremadamente útiles si tiene una base de datos de gran tamaño (2+ Terabyte)

¿Cómo reducir el RPO y el RTO?

Ahora todos entendemos el uso de RPO y RTO y lo importante que es para cualquier negocio u operación.

A continuación se presentan algunas de las prácticas más comunes y mejores a nivel de base de datos para reducir su RPO y RTO:

Replicación sincrónica con failover automático:

Si no puede permitirse el lujo de perder datos (aplicaciones de misión crítica, industrias bancarias, instituciones financieras) tener una replicación sincrónica de PostgreSQL ciertamente ayuda y también asegura que tiene una copia comprometida de los datos (dependiendo del modo de sincronización que elija) en el nodo en espera.

En caso de cualquier catástrofe, puede hacer una conmutación por error automática/manual al nodo en espera y reducir significativamente el RTO y RPO.

Este método no asegura una pérdida de datos nula hasta que diseñe su aplicación para esperar el commit en la base de datos antes de completar la transacción.

Este enfoque de replicación sincronizada de PostgreSQL también puede añadir una sobrecarga adicional de rendimiento de la aplicación.

Replicación asíncrona con failover automático:

La replicación en flujo es asíncrona por defecto, en cuyo caso hay un pequeño retraso entre la consignación de una transacción en el primario y que los cambios sean visibles en el standby.

Sin embargo, este retraso es mucho menor que con el envío de registros basado en archivos.

También depende de la carga/transacciones y del ancho de banda de la red. 

Con la replicación de flujo, no se requiere archive_timeout para reducir la ventana de pérdida de datos.

También hemos visto clientes que utilizan la espera con 24 horas de retraso para manejar ciertas situaciones de recuperación, en las que el usuario ha dejado caer accidentalmente una tabla y el retraso de la espera ayudó a recuperarla.

Consideración del sitio de Recuperación de Desastres: PostgreSQL le permite crear un sitio de recuperación de desastres a otra región mediante el uso de WAL.

Esto es particularmente importante para asegurar que usted tiene la copia más actualizada de su base de datos en otra región o centro de datos en caso de cualquier escenario de desastre donde el centro de datos completo se ha ido o no es accesible.

Usted puede o no ser capaz de tomar el golpe en la pérdida de datos (Recovery Point Objective) sin embargo RTO se reducirá incluso el sitio está completamente desaparecido.

Conclusión de hacer una copia de seguridad PostgreSQL :

La clave para el éxito de una estrategia de copia de seguridad de PostgreSQL es entender a los usuarios finales y a las empresas.

Le ayudará a entender la importancia de sus datos y la rapidez con la que quiere que su sistema esté disponible en caso de cualquier situación catastrófica.

Esto nos ayuda a definir el RTO y el RPO.

Encontrar la solución adecuada, ya sea una copia de seguridad, un sistema de reserva o cualquier estrategia de recuperación de desastres, y asegurarnos de que se pruebe correctamente y, por último, de que se implemente.

Conoce más de la Base de Datos de código abierto más avanzada del mundo déjanos tus datos y con gusto te presentamos una demostración gratuita


1 comentario

PostgreSQL frente a MySQL: Una comparación de 360 grados · agosto 28, 2021 a las 8:17 pm

[…] También te puede interesar ¿Cómo decidir su estrategia de copia de seguridad de PostgreSQL? […]

Deja una respuesta

Marcador de posición del avatar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *