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 con 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 contra errores del usuario, daños o fallas físicas a nivel de la base de datos, en lugar de instantáneas de imágenes de VM o del servidor.
  • Quieres 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.

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 copias de seguridad, más tiempo llevará restablecer y recuperar la base de datos. La pérdida de datos depende del tipo de copia de seguridad. Si solo se crean copias de seguridad de los archivos de datos de forma periódica, cuando restablezcas, se perderán los datos desde la última copia de seguridad.

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 anticipada (WAL) y transmitir datos de WAL, posiblemente a una ubicación de almacenamiento remoto.

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 tu RPO debe tener en cuenta la posible pérdida de datos. Por el contrario, la transferencia continua de datos de WAL minimiza la posible pérdida de datos.

Cuando configuras copias de seguridad continuas, puedes realizar la recuperación a un momento específico. La recuperación de un momento determinado te permite restablecer una base de datos a un estado anterior a un error, como la eliminación accidental de tablas o las actualizaciones por lotes incorrectas. Sin embargo, este método de recuperación afecta tanto al RPO como al RTO, a menos que uses una base de datos auxiliar temporal. Restablecer una base de datos completa en su lugar revierte las transacciones posteriores en las tablas no afectadas y desconecta la base de datos, mientras que restablecer una base de datos auxiliar temporal te permite copiar solo los datos recuperados.

Estrategias de copia de seguridad

AlloyDB Omni admite estrategias de protección de datos, como copias de seguridad físicas periódicas, recuperación de un momento determinado, archivado y transmisión de WAL, y almacenamiento de copias de seguridad en diferentes ubicaciones. Como alternativa, para las bases de datos pequeñas, puedes realizar una copia de seguridad lógica con pg_dump para una sola base de datos o pg_dumpall para todo el clúster, y restablecer con pg_restore.

Herramientas de copia de seguridad

Para las implementaciones de contenedores y Linux, puedes programar y administrar copias de seguridad con las siguientes herramientas de PostgreSQL:

Según la opción de implementación, puedes configurar AlloyDB Omni para que almacene copias de seguridad en un almacenamiento local o remoto, como Cloud Storage o las opciones de almacenamiento que proporciona cualquier proveedor de servicios en la nube. Aunque el almacenamiento local puede ser más rápido para crear copias de seguridad y recuperarse, el almacenamiento remoto suele ser más sólido para controlar fallas cuando falla un host o una VM completa. Para obtener más información, consulta la Figura 1, en la que se muestran los posibles destinos de las copias de seguridad.

AlloyDB Omni con opciones de copia de seguridad

Figura 1. AlloyDB Omni con opciones de copia de seguridad.

Puedes realizar copias de seguridad 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 mejor protección contra las fallas de host y zonales que las copias de seguridad locales.

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

Para las implementaciones de almacenamiento local, compartido y remoto, puedes programar los siguientes tipos de copias de seguridad o realizarlas de forma manual según demanda:

  • 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 de archivos desde la última copia de seguridad completa.
  • Copias de seguridad incrementales: Son copias de seguridad de solo los cambios de archivos desde la última copia de seguridad de cualquier tipo.

Recuperación de un momento determinado

Las copias de seguridad continuas de los archivos 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 un momento específico y ayudar a minimizar la pérdida de datos.

Transmite datos de WAL a una ubicación remota

Según la herramienta de copia de seguridad que uses (como Barman), puedes configurar los datos de WAL para que se transmitan en tiempo real a una ubicación remota y, así, minimizar la pérdida de datos durante la recuperación. Incluso con la transmisión en tiempo real, existe una pequeña posibilidad de perder transacciones confirmadas, ya que las escrituras de transmisión en la ubicación remota son asíncronas de forma predeterminada. Sin embargo, puedes configurar la transmisión de WAL para que use el modo síncrono, que almacena los datos de 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 se suelen programar 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 incremental
  • 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 progresiva 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 de una falla que se produce durante la copia de seguridad completa del domingo, cuando la recuperación de la base de datos debe extenderse al domingo anterior antes de que se inicie la copia de seguridad.

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

Restablecimiento de copias de seguridad

Puedes restablecer una base de datos de AlloyDB Omni desde una copia de seguridad almacenada o recuperarla a un momento específico dentro de tu período de retención. Según tu entorno de implementación y tus necesidades de recuperación, puedes restablecer los datos in situ o restablecer la copia de seguridad en una instancia o un clúster de base de datos nuevos.

Para las implementaciones de contenedores y Linux, restablecer una base de datos de AlloyDB Omni suele implicar detener el servicio o el contenedor de la base de datos y restablecer los datos en el directorio de datos existente, o restablecer los datos en una ubicación nueva y, luego, iniciar una instancia de base de datos nueva con esos datos restablecidos. Para obtener más información, consulta Restablece un clúster de AlloyDB Omni con pgBackRest o Restablece un clúster de AlloyDB Omni con Barman.

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 y RPO flexibles.
  • Requiere un hardware adicional mínimo.
  • Proporciona las copias de seguridad fundamentales que se requieren para un plan de recuperación ante desastres.
  • Admite la recuperación a cualquier momento dentro de la ventana de recuperación.

Limitaciones

  • Puede requerir más espacio de almacenamiento que la base de datos en sí, según tus requisitos de retención.
  • La recuperación puede ser lenta y puede 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 una falla de la base de datos, lo que podría afectar de forma negativa el RPO.

Alternativas

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

¿Qué sigue?