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 a través de 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.
  • Deseas 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 (a diferencia de las instantáneas de imágenes de servidores o VM).
  • Quieres poder recuperar tu base de datos de forma local o remota, posiblemente hasta un momento específico.

Cómo funciona la arquitectura de referencia

La arquitectura de referencia de disponibilidad estándar abarca 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 necesarios, 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 crear una copia de seguridad, más tiempo se tardará en restablecer y recuperar la base de datos. La pérdida de datos depende del tipo de copia de seguridad. Si solo se realiza una copia de seguridad de los archivos de datos de forma periódica, cuando restablezcas la base de datos, perderás los datos que se hayan agregado desde la última copia de seguridad.

Reducción del 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 los archivos de registro de escritura anticipada (WAL) y transmitir los datos de WAL, posiblemente a una ubicación de almacenamiento remota.

Si los archivos WAL se archivan solo cuando están completos 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 del WAL maximiza la pérdida cero de datos.

Cuando realices copias de seguridad continuas, podrás realizar una recuperación a un momento específico. La recuperación a un momento determinado permite restablecer el estado de la base de datos a un momento anterior a un error, como la eliminación accidental de una tabla 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 copias de seguridad

Puedes configurar las copias de seguridad a nivel de Postgres de AlloyDB Omni para que se almacenen en el almacenamiento local o remoto. Si bien el almacenamiento local puede ser más rápido para crear copias de seguridad y recuperarse de ellas, 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 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 realizar la restauración con pg_restore.

Copias de seguridad en Kubernetes con el operador de AlloyDB Omni

En el caso de 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 datos 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 copias 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 crear en opciones de almacenamiento locales o remotas. 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 podría ofrecer un RTO más rápido.

En el caso de las implementaciones de almacenamiento local y compartido, se pueden programar los siguientes tipos de copias de seguridad o realizarlas manualmente a pedido:

  • Copias de seguridad completas: Son copias de seguridad completas de todos los archivos de la base de datos necesarios para la recuperación de datos.
  • Copias de seguridad diferenciales: Son copias de seguridad de solo los cambios en los archivos desde la última copia de seguridad completa.
  • Copias de seguridad incrementales: Son copias de seguridad de solo los cambios en los archivos 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 anticipada (WAL) de PostgreSQL admiten la recuperación en un momento determinado. Si, después de un evento de falla, los archivos WAL están intactos y se pueden usar, puedes utilizarlos para realizar la recuperación 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 descarga el WAL en el disco, a menos que una transacción que se confirma de forma asíncrona active la escritura antes. El valor predeterminado es 200 ms. Aumentar este valor reduce la frecuencia de escritura, pero podría aumentar la cantidad de datos perdidos si el servidor falla.

wal_writer_flush_after

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

synchronous_commit

Especifica si la confirmación devuelve una respuesta al usuario antes de que los datos de WAL se escriban 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 devolver un código de éxito al usuario. Si se configura como off, habrá hasta tres veces wal_writer_delay antes de que la transacción se escriba en el disco.

Supervisión del uso del WAL

Puedes usar los siguientes métodos para observar el uso del 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 y sincronizaciones de 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 del WAL a lo largo del tiempo.
pg_current_wal_lsn() Esta función devuelve 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 por segundo del WAL generado 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 de WAL a una ubicación remota

Cuando usas Barman, los datos de WAL también se pueden configurar para transmitirse en tiempo real a una ubicación remota y garantizar que haya poca o ninguna pérdida de datos durante la recuperación. A pesar de la transmisión en tiempo real, existe una pequeña probabilidad 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 de 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 un programa semanal típico 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 este programa típico, una ventana 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 necesarias. Este enfoque admite la recuperación ante una falla que se produce durante la copia de seguridad completa del domingo, y se requiere la recuperación de la base de datos para extenderse hasta el domingo anterior al inicio de la copia de seguridad.

Para minimizar el RTO con un potencial de RPO más alto, se pueden operar bases de datos adicionales en modo de recuperación continua. Esto implica volver a reproducir las copias de seguridad y actualizar continuamente el entorno secundario archivando y reproduciendo nuevos archivos WAL. 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 de WAL.

Restauración en entornos que no son de Kubernetes

En el caso de las implementaciones que no son de Kubernetes, restablecer una base de datos de AlloyDB Omni implica detener el contenedor de Docker y, luego, restablecer los datos, o bien restablecer los datos en una ubicación diferente y lanzar una nueva instancia 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.

Restauración 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 desde un punto en el tiempo (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 datos en Kubernetes y Descripción general de la clonación de un clúster de bases de datos a partir de 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 de recuperación ante desastres completo
  • Es posible realizar la recuperación a 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 tardar en recuperarse y podría generar un RTO más alto.
  • Puede provocar alguna pérdida de datos, según la disponibilidad de los datos de 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?