Protege tus datos con copias de seguridad

Selecciona una versión de la documentación:

En esta página, se describe la arquitectura de referencia de disponibilidad estándar de AlloyDB Omni, que proporciona protección de datos mediante copias de seguridad.

Casos de uso

Esta arquitectura de referencia admite las siguientes situaciones:

  • Tienes bases de datos que pueden tolerar cierto tiempo de inactividad y pérdida de datos desde la última copia de seguridad.
  • Quieres proteger tu base de datos de AlloyDB Omni de errores del usuario, corrupción o fallas físicas a nivel de la base de datos (en lugar de instantáneas de servidor o imagen de VM).
  • Quieres poder recuperar tu base de datos en el lugar o de forma remota, posiblemente hasta un momento específico.

Cómo funciona la arquitectura de referencia

La arquitectura de referencia de disponibilidad estándar cubre la copia de seguridad y la recuperación de tus bases de datos de AlloyDB Omni, ya sea que se ejecuten como una instancia independiente en un servidor host, como una máquina virtual (instala AlloyDB Omni), o en un clúster de Kubernetes (instala AlloyDB Omni en Kubernetes).

Si bien la disponibilidad estándar es una implementación básica y minimiza el hardware o los servicios adicionales requeridos, el objetivo de tiempo de recuperación (RTO) aumenta a medida que la base de datos se hace más grande. Cuantos más datos haya para respaldar, más tiempo tardará en restablecer y recuperar la base de datos. La pérdida de datos depende del tipo de copia de seguridad. Si solo se respaldan los archivos de datos de forma periódica, cuando restablezcas, incurrirás en la pérdida de datos desde la última copia de seguridad.

Cómo reducir el RPO

La función de archivado continuo de PostgreSQL te permite lograr un objetivo de punto de recuperación (RPO) bajo y habilitar la recuperación de un momento determinado a través de copias de seguridad. Este proceso implica archivar archivos de registro de escritura por adelantado (WAL) y transmitir datos WAL, posiblemente a una ubicación de almacenamiento remota.

Si los archivos WAL se archivan solo cuando están llenos o en intervalos específicos, una pérdida completa de la base de datos (incluidos los archivos WAL actuales) restringe la recuperación al último archivo WAL archivado, lo que significa que el objetivo de punto de recuperación (RPO) debe tener en cuenta la posible pérdida de datos. Por el contrario, la transferencia continua de datos WAL maximiza la pérdida de datos cero.

Cuando realizas copias de seguridad continuas, puedes realizar la recuperación a un momento específico. La recuperación de un momento determinado permite el restablecimiento a un estado anterior a un error, como la eliminación accidental de tablas o las actualizaciones incorrectas por lotes. Sin embargo, este método de recuperación afecta el objetivo de punto de recuperación (RPO), a menos que se utilice una base de datos auxiliar temporal.

Estrategias de copia de seguridad

Puedes configurar las copias de seguridad a nivel de AlloyDB Omni Postgres para que se almacenen en el almacenamiento local o remoto. Si bien el almacenamiento local puede ser más rápido para realizar copias de seguridad y recuperarse, el almacenamiento remoto suele ser más sólido para controlar las fallas cuando falla un host o una VM completos.

Copias de seguridad en entornos que no son de Kubernetes

Para las implementaciones que no son de Kubernetes, puedes programar copias de seguridad con las siguientes herramientas de PostgreSQL:

Como alternativa, para bases de datos pequeñas, puedes elegir realizar una copia de seguridad lógica de la base de datos (con pg_dump para una sola base de datos o pg_dumpall para todo el clúster). Puedes restablecer con pg_restore.

Copias de seguridad en Kubernetes con el operador de AlloyDB Omni

Para AlloyDB Omni implementado en un clúster de Kubernetes, puedes configurar copias de seguridad continuas con un plan de copia de seguridad para cada clúster de base de datos. Para obtener más información, consulta Crea copias de seguridad y restablece en Kubernetes.

Puedes almacenar copias de seguridad de AlloyDB Omni de forma local o remota en Cloud Storage, incluidas las opciones que proporciona cualquier proveedor de servicios en la nube. Para obtener más información, consulta la Figura 1, que muestra los posibles destinos de copia de seguridad.

AlloyDB Omni con opciones de copia de seguridad

Figura 1. AlloyDB Omni con opciones de copia de seguridad

Las copias de seguridad se pueden realizar en opciones de almacenamiento local o remoto. Las copias de seguridad locales suelen ser más rápidas porque solo dependen de la capacidad de procesamiento de E/S, mientras que las copias de seguridad remotas suelen tener una latencia más alta y un ancho de banda de red más bajo. Sin embargo, las copias de seguridad remotas proporcionan una protección óptima, incluidas las fallas zonales.

También puedes dividir las copias de seguridad locales en almacenamiento local o compartido. Si bien las opciones de almacenamiento local se ven afectadas por la falta de opciones de recuperación ante desastres cuando falla un host de base de datos, el almacenamiento compartido permite que ese almacenamiento se reubique en otro servidor y, luego, se use para la recuperación. Esto significa que el almacenamiento compartido ofrece potencialmente un RTO más rápido.

Para las implementaciones de almacenamiento local y compartido, los siguientes tipos de copia de seguridad se pueden programar o realizar de forma manual a pedido:

  • Copias de seguridad completas: copias de seguridad completas de todos los archivos de base de datos necesarios para la recuperación de datos
  • Copias de seguridad diferenciales: copias de seguridad de solo los cambios de archivo desde la última copia de seguridad completa
  • Copias de seguridad incrementales: copias de seguridad de solo los cambios de archivo desde la última copia de seguridad de cualquier tipo

Recuperación de un momento determinado

Las copias de seguridad continuas de los archivos de registro de escritura por adelantado (WAL) de PostgreSQL admiten la recuperación de un momento determinado. Si, después de un evento de falla, los archivos WAL están intactos y se pueden usar, puedes usarlos para recuperar sin pérdida de datos.

Para controlar la escritura de los archivos WAL, puedes configurar los siguientes parámetros:

Parámetro Descripción

wal_writer_delay

Especifica la frecuencia con la que el escritor de WAL vacía el WAL en el disco, a menos que la escritura sea activada antes por una transacción que se confirma de forma asíncrona El valor predeterminado es 200 ms. Si aumentas este valor, se reduce la frecuencia de las escrituras, pero puede aumentar la cantidad de datos perdidos si falla el servidor.

wal_writer_flush_after

Especifica la cantidad de datos WAL que se pueden acumular antes de que el escritor de WAL fuerce un vaciado en el disco. El valor predeterminado es 1 MB. Si se establece en cero, los datos WAL siempre se vacían en el disco de inmediato.

synchronous_commit

Especifica si la confirmación muestra una respuesta al usuario antes de que los datos WAL se vacíen en el disco. El parámetro de configuración predeterminado es on, lo que garantiza que la transacción sea duradera. En otras palabras, la confirmación se escribió en el disco antes de mostrar un código de éxito al usuario. Si se establece en off, hay hasta tres veces wal_writer_delay antes de que la transacción se escriba en el disco.

Supervisión del uso de WAL

Puedes usar los siguientes métodos para observar el uso de WAL:

Método de observación Descripción

pg_stat_wal

Esta vista estándar tiene las columnas wal_write y wal_sync, que almacenan los recuentos de la cantidad de escrituras WAL y sincronizaciones WAL. Cuando se habilita el parámetro de configuración track_wal_io_timing, también se almacenan wal_write_time y wal_sync_time. Las instantáneas periódicas de esta vista pueden ayudar a mostrar la actividad de escritura y sincronización de WAL a lo largo del tiempo.
pg_current_wal_lsn() Esta función muestra la posición actual del número de secuencia de registro (lsn) que, cuando se asocia con una marca de tiempo y se recopila como instantáneas a lo largo del tiempo, puede proporcionar los bytes/segundo de WAL generados con la función pg_wal_lsn_diff(lsn1, lsn2). Esta función es una métrica útil para comprender la tasa de transacciones y el rendimiento de los archivos WAL.

Transmite datos WAL a una ubicación remota

Cuando usas Barman, los datos WAL también se pueden configurar para transmitirse en tiempo real a una ubicación remota para garantizar que haya poca o ninguna pérdida de datos en la recuperación. A pesar de la transmisión en tiempo real, existe una pequeña posibilidad de perder transacciones confirmadas, ya que las escrituras de transmisión en el servidor Barman remoto son asíncronas de forma predeterminada. Sin embargo, es posible configurar la transmisión WAL con el modo síncrono que almacena el WAL y envía una respuesta de estado a la base de datos de origen. Ten en cuenta que este enfoque puede ralentizar las transacciones si tienen que esperar a que se complete esta escritura antes de continuar.

Programaciones de copias de seguridad

En la mayoría de los entornos, las copias de seguridad suelen programarse semanalmente. A continuación, se muestra una programación semanal típica de copias de seguridad:

  • Domingo: copia de seguridad completa
  • Lunes y martes: copia de seguridad
  • Miércoles: copia de seguridad diferencial
  • Jueves y viernes: copia de seguridad incremental
  • Sábado: copia de seguridad diferencial

Con esta programación típica, un período de recuperación continua de una semana requiere espacio de almacenamiento para hasta tres copias de seguridad completas, además de las copias de seguridad incrementales o diferenciales requeridas. Este enfoque admite la recuperación de una falla que ocurre durante la copia de seguridad completa del domingo, y la recuperación de la base de datos debe extenderse al domingo anterior antes de que comience la copia de seguridad.

Para minimizar el RTO con un RPO potencialmente más alto, las bases de datos adicionales pueden operar en modo de recuperación continua. Esto implica reproducir copias de seguridad y actualizar continuamente el entorno secundario mediante el archivo y la reproducción de archivos WAL nuevos. El RPO real, que refleja la posible pérdida de datos, depende de la frecuencia de las transacciones, el tamaño del archivo WAL y el uso de la transmisión WAL.

Restablecimiento en entornos que no son de Kubernetes

Para las implementaciones que no son de Kubernetes, el restablecimiento de una base de datos de AlloyDB Omni implica detener el contenedor de Docker y, luego, restablecer los datos, o restablecer los datos en una ubicación diferente y, luego, iniciar una instancia nueva de Docker con esos datos restablecidos. Una vez que se reinicia el contenedor, se puede acceder a la base de datos con los datos restablecidos.

Para obtener más información sobre las opciones de recuperación, consulta Restablece un clúster de AlloyDB Omni con pgBackRest y Restablece un clúster de AlloyDB Omni con Barman.

Restablecimiento en Kubernetes con el operador

Para restablecer una base de datos en Kubernetes, el operador ofrece la recuperación en el mismo clúster y espacio de nombres de Kubernetes, desde una copia de seguridad con nombre o un clon de un momento determinado (PIT). Para clonar una base de datos en un clúster de Kubernetes diferente, usa pgBackRest. Para obtener más información, consulta Crea copias de seguridad y restablece en Kubernetes y Descripción general de la clonación de un clúster de base de datos desde una copia de seguridad de Kubernetes.

Implementación

Cuando elijas una arquitectura de referencia de disponibilidad, ten en cuenta los siguientes beneficios, limitaciones y alternativas.

Beneficios

  • Es fácil de usar y administrar, y es adecuado para bases de datos no críticas con RTO/RPO flexibles.
  • Se requiere hardware adicional mínimo.
  • Siempre se requieren copias de seguridad para un plan completo de recuperación ante desastres.
  • Es posible la recuperación en cualquier momento dentro del período de recuperación.

Limitaciones

  • Requisitos de almacenamiento que posiblemente sean más grandes que la base de datos en sí, según los requisitos de retención.
  • Puede ser lento para recuperarse y puede generar un RTO más alto.
  • Puede provocar cierta pérdida de datos, según la disponibilidad de los datos WAL actuales después de la falla de la base de datos, lo que podría afectar negativamente el RPO.

Alternativas

  • Considera la arquitectura de disponibilidad mejorada o premium para mejorar la disponibilidad y las opciones de recuperación ante desastres.

¿Qué sigue?