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

En el caso de las implementaciones de Kubernetes, puedes configurar copias de seguridad continuas con un plan de copia de seguridad (BackupPlan) administrado por el operador de AlloyDB Omni para cada clúster de base de datos. Para obtener más información, consulta Crea una copia de seguridad y restablece en Kubernetes.

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.

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.

En el caso de las implementaciones de Kubernetes, el operador de AlloyDB Omni admite la recuperación de una base de datos en el mismo clúster y espacio de nombres de Kubernetes a partir de una copia de seguridad con nombre o la clonación desde un momento determinado. Para obtener más información, consulta Crea una copia de seguridad y restablece en Kubernetes y Descripción general de la clonación manual 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 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?