Implementando una estrategia de recuperación de desastres con Amazon RDS

Anuraag Deekonda, Consultor especializado en migraciones de AWS

Amazon RDS (Relational Database Service) es un servicio administrado que facilita la configuración, funcionamiento y escalado de una base de datos relacional. Basado en el almacenamiento y poder de cómputo de alto rendimiento de AWS, Amazon RDS soporta los motores de base de datos MySQL, SQL Server, PostgreSQL, MariaDB y Oracle. Amazon RDS ofrece un conjunto completo de soluciones para el aprovisionamiento, aplicación de parches, supervisión y recuperación de desastres (DR). Esta publicación presenta tres características de Amazon RDS que admiten DR: respaldos (snapshots) automatizadas, respaldos (snapshots) manuales, y réplicas de lectura

Por qué necesitas un plan de recuperación de desastres (DR)?

En un ambiente de producción, es importante tomar precauciones para que tu solución pueda recuperarse en caso de que ocurra un evento inesperado. Si bien Amazon RDS proporciona una configuración Multi-AZ de alta disponibilidad, no puede proteger tu solución de todas las posibilidades, como un desastre natural, un actor malintencionado, o la corrupción lógica de una base de datos. Para mantener la continuidad del negocio, es importante diseñar y probar un plan de recuperación de desastres (DR).

Entendiendo RTO y RPO

El objetivo de tiempo de recuperación (RTO, Recovery Time Objective) y el objetivo de punto de recuperación (RPO, Recovery Point Objective) son dos métricas clave a tener en cuenta al desarrollar un plan de DR. El RTO representa cuántas horas le lleva a la solución regresar a un estado operativo después de un desastre. El RPO, que también se expresa en horas, representa la cantidad de datos que podrían perderse cuando ocurre un desastre. Por ejemplo, un RPO de una (1) hora significa que la solución puede perder hasta una (1) hora de datos cuando ocurra un desastre.

Diferentes características de Amazon RDS soportan diferentes RTOs y RPOs a diferentes costos:

Como puede ver en la tabla anterior, snapshots (respaldos) automatizados están limitados a una sola región mientras que snapshots (respaldos) manuales y réplicas de lectura se soportan en múltiples regiones.

Amazon Aurora

Este artículo no cubre de forma explícita Amazon Aurora porque Amazon Aurora tiene características de recuperación de desastres (DR) ligeramente diferentes. Sin embargo, muchas de las técnicas presentadas aquí se aplican a los clústeres de base de datos Aurora. Para obtener más información, consulte la documentación de Amazon Aurora.

Respaldos (snapshots) de Amazon RDS

Los respaldos (snapshots) son un componente clave de un plan de recuperación de desastres para su base de datos. Amazon RDS soporta dos tipos de respaldos: snapshots automatizados, y snapshots manuales.

Los respaldos (snapshots) de Amazon RDS siguen las siguientes normas:

• Su instancia de base de datos debe estar ACTIVA para que los respaldos puedan ocurrir
• Copias de seguridad automatizadas no suceden mientras una copia se esté ejecutando en la misma región para la misma instancia de base de datos.
• La primera copia de seguridad (snapshot) de una instancia de bases de datos contiene todos los datos almacenados en esa instancia (full snapshot).
• Todas las copias de seguridad (snapshot) creadas después de la primera copia son incrementales (incremental snapshots). Esto significa que solamente los últimos cambios desde la última copia de seguridad son capturados y almacenados.
• En una configuración Multi-AZ, las copias de seguridad se ejecutan en el nodo secundario (standby) para reducir el impacto de este proceso sobre el nodo primario.

Nota: respaldos (snapshots) automatizadas y manuales son almacenadas en un bucket de S3 que es administrado directamente por el servicio Amazon RDS. En consecuencia, el usuario no tiene visibilidad sobre esas copias de seguridad en la consola de Amazon S3.

Para información más detallada con relación a mecanismos de respaldo y almacenamiento de copias de seguridad vea el capítulo Trabajando con Copias de Seguridad en la guía del usuario de Amazon RDS.

Respaldos (snapshots) automatizadas

La característica respaldos automatizados de Amazon RDS está activada de forma predeterminada. Amazon RDS crea un respaldo o copia de seguridad (snapshot) del volumen asociado a su instancia de base de datos que respalda toda la instancia de base de datos y no solo bases de datos individuales. La primera copia de seguridad consiste en un snapshot de la instancia completa. Las copias de seguridad posteriores son de naturaleza incremental y los snapshots contienen solo los bloques que cambiaron desde la copia de seguridad (snapshot) anterior. Cada snapshot contiene punteros a todos los bloques de datos de los otros snapshots que se requieren para reconstruir la copia de seguridad. La eliminación del snapshot anterior no provoca la pérdida de datos, siempre y cuando exista al menos un snapshot que siga haciendo referencia a los datos originales.

Por qué necesitamos respaldos automatizadas?

Existen muchos beneficios asociados a tener respaldos automatizados:

• Los datos son almacenados en un bucket de Amazon S3 que pertenece y es administrado directamente por el servicio Amazon RDS.
• La presión asociada a tener que apartar tiempo para crear respaldos y moverlos a una ubicación segura desaparece por completo.
• La Ventana de tiempo para generar estos respaldos es configurable y puede ajustarse a una frecuencia y hora que funcione para ti: diaria, semanal, o mensual.
• Se mitiga el impacto de calamidades tanto manuales como naturales (por ejemplo, virus, mal funcionamiento del software o cortes de energía).
• Lo que es más importante, evita los efectos adversos de perder datos valiosos

Ventana para respaldos automatizados

La ventana de respaldos automatizados es un período de tiempo diario utilizado para crear copias de seguridad (respaldos) automatizadas. La ventana se selecciona al azar a partir de un bloque de tiempo de 8 horas para cada región de AWS. Sin embargo, se recomienda configurar la ventana de copia de seguridad durante las horas de mínima actividad para evitar una carga indebida en el servidor. Para obtener una lista de los bloques de tiempo para cada región, consulte el capítulo Ventana de Respaldo en la Guía del Usuario de Amazon RDS.

Período de retención para respaldos automatizados

El período de retención de respaldos es la ventana de tiempo durante la cual el usuario puede realizar una restauración a un punto en el tiempo (PITR, Point in Time Recovery). Puede establecer un período de retención de respaldos diferente cuando cree una instancia de base de datos y puede modificar el período de retención en cualquier momento.

Para información más detallada por favor referirse a Período de Retención de Respaldos.

Existen algunas diferencias entre respaldos (snapshots) manuales y automatizadas:

• El límite en el número de snapshots manuales (100 snapshots por región) no aplica para snapshots automatizados.
• El período de retención de snapshots no aplica para los snapshots manuales.
• Los snapshots manuales no son eliminados de manera automática; estos deben ser eliminados de manera explícita.

Configurando snapshots automatizados durante la creación de una instancia

1. En la pestaña Backup (copia de seguridad), en la sección Configure advanced settings (opciones de configuración avanzada), defina el Backup retention period (período de retención de respaldos) y Backup window (ventana de respaldos)
2. Defina un Start time (tiempo de inicio) para el respaldo y la Duration (duración) en horas que su base de datos necesita para completar la copia de seguridad. Es una práctica recomendada definir ventanas de respaldo en horas de mínima actividad.

Modificando la configuración de respaldos (snapshots) automatizados

Para cambiar la configuración de sus respaldos automatizados siga los pasos a continuación:

1. Seleccione la instancia de bases de datos para la cual quiere cambiar la configuración de respaldos y pulse el botón Modify (modificar).

   

2. Desplácese hasta la sección Backup (respaldo) y haga los cambios que desee en los campos Backup retention period (período de retención de respaldos) y Backup window (ventana de respaldos).
3. En la sección Scheduling of modifications (planificación de modificaciones), seleccione la opción deseada y luego pulse el botón Modify DB instance.

   

Restaurando a un punto en el tiempo

Recuperación a un punto en el tiempo (PITR, Point In Time Recovery) es el proceso de restaurar una base de datos al estado en el que estaba en una fecha y hora específica.

Cuando se activan los respaldos automatizados para su instancia de base de datos, Amazon RDS realiza automáticamente un snapshot diario de su instancia de base de datos. El snapshot se produce durante la ventana de respaldo definida en la configuración de la instancia. RDS también captura registros de bitácoras de transacciones (transaction logs) en Amazon S3 cada 5 minutos (a medida que se realizan actualizaciones en la instancia de base de datos). Archivar los registros de bitácoras de transacciones es una parte importante del proceso de recuperación de desastres (DR) y de la recuperación a un punto en el tiempo (PITR). Cuando se inicia la recuperación a un punto en el tiempo, los registros de las bitácoras de transacciones se aplican al snapshot diario más adecuado para restaurar la instancia de base de datos al punto específico en el tiempo solicitado.

Para instrucciones más detalladas por favor referirse al capítulo Restaurando una Instancia de Base de Datos a un Punto en el Tiempo en la guía del usuario de Amazon RDS.

Retención de respaldos (snapshots) automatizados

Cuando eliminas una instancia de base de datos, puedes optar por conservar sus respaldos automatizados. Esto puede resultar útil si más adelante decides restaurar la instancia de base de datos. Los respaldos retenidos contienen snapshots automatizados y registros de bitácoras de transacciones (transaction logs) de una instancia de base de datos. También incluyen las propiedades de la instancia de base de datos (como el almacenamiento asignado y la clase de instancia de base de datos), que son necesarias para restaurarla en una instancia activa. Puede restaurar o eliminar los respaldos automatizados retenidas mediante la consola de administración de AWS, la API de Amazon RDS y la interfaz CLI de AWS. Consulte Retención de Copias de Seguridad Automatizadas en la Guía del usuario de Amazon RDS para obtener más información sobre las limitaciones y recomendaciones para conservar estos respaldos.

Respaldos (snapshots) manuales

Respaldos manuales (iniciadas por el usuario) son respaldos completos de la instancia de base de datos. Estos snapshots son almacenados en Amazon S3, y retenidos hasta que el usuario de manera explícita los elimine. Estos snapshots pueden ser copiados y compartidos a diferentes regiones y cuentas AWS. Dado que esas copias de seguridad (respaldos) contienen todos los datos contenidos en la instancia, incluyendo archivos de datos (data files) y archivos temporales, el tamaño total de la instancia determina el tiempo requerido para crear el snapshot.

Crear un snapshot en una instancia de base de datos en modo Single-AZ genera una breve suspensión de actividad (I/O) en el volumen asociado a la instancia. Esta suspensión de actividad puede durar desde solo unos segundos hasta un par de minutos dependiendo del tamaño y clase de la instancia de base de datos. Instancias de bases de datos configuradas en modo Multi-AZ no son afectadas por esta suspensión de actividad en el almacenamiento porque el snapshot se genera en el nodo secundario.

Para instrucciones detalladas de como crear una copia de seguridad (snapshot) para una base de datos haga referencia al siguiente enlace en la guía del usuario de Amazon RDS.

Visualizando respaldos (snapshots)

Para visualizar snapshots en la consola de Amazon RDS haga click en la opción Snapshots, después elija el filtro Manual Snapshots y luego seleccione el snapshot que desea visualizar en la lista, tal y como se muestra en la figura a continuación.

Copiando y compartiendo snapshots

En Amazon RDS, puede copiar snapshots de base de datos automatizados o manuales. Cuando se crea una copia de un snapshot, esa copia se convierte en un snapshot manual. Es posible copiar un snapshot en la misma región de AWS o en otras regiones de AWS, e incluso es posible copiar un snapshot en otras cuentas de AWS. Si copia un snapshot de base de datos en otra región de AWS, se crea un snapshot de base de datos manual que se conserva en esa región de AWS. Al copiar un snapshot de base de datos desde la región de AWS de origen, se incurre en cargos por transferencia de datos

No se puede copiar directamente un snapshot de bases de datos automatizado a otra cuenta AWS. Para compartir un snapshot de bases de datos automatizado, primero cree un snapshot manual copiando el snapshot automatizado que desea replicar y luego comparta esa copia manual de base de datos. Este proceso también aplica a recursos creados por AWS Backup. En este caso, el proceso es inverso, primero se comparte el snapshot y después se copia el snapshot a la otra cuenta AWS.

Para mayor información con relación a copiar snapshots de base de datos, incluyendo limitaciones, vea el capítulo Copiando un Snapshot en la guía del usuario de Amazon RDS.

Compartiendo snapshots de Amazon RDS a otras cuentas de AWS

Amazon RDS le permite compartir snapshots de base de datos o snapshots de clúster con otras cuentas de AWS. Compartir snapshots con otras cuentas altamente seguras puede ser útil si le preocupa que un «mal actor» interrumpa las operaciones en sus cuentas de producción. Puede compartir snapshots de base de datos manuales con hasta 20 cuentas de AWS.

• Los snapshots automatizados de Amazon RDS no se pueden compartir directamente con otras cuentas de AWS. Para compartir un snapshot automaizado primero debe hacer una copia del snapshot, lo que lo convierte en una versión manual. Luego, comparte la copia con la otra cuenta de AWS.
• Los snapshots manuales de instancias de base de datos que usan grupos de opciones personalizados (custom option groups) con opciones persistentes o permanentes, como el cifrado de datos transparente (TDE, Transparent Data Encryption) y la zona horaria, no se pueden compartir.
• Los snapshots que usan la clave de cifrado predeterminada de Amazon RDS (default encryption key) no se pueden compartir directamente. En su lugar, primero debe copiar el snapshot eligiendo una clave de cifrado personalizada (custom Encryption key) y, a continuación, compartir la clave personalizada y el snapshot copiado.

Para instrucciones detalladas con relación a la copia de snapshots de bases de datos a otras cuentas de AWS por favor lea el capítulo Compartiendo un Snapshot de Base de Datos de la guía del usuario de Amazon RDS.

Restaurando una instancia de base de datos con un snapshot

Si ocurre un desastre, puede crear una nueva instancia de base de datos mediante la restauración a partir de un snapshot de base de datos. Cuando restaura la instancia de base de datos, elija el nombre del snapshot de base de datos desde la que desea restaurar. A continuación, debe proporcionar un nombre para la nueva instancia de base de datos que se va a crear. Estas son algunas cosas a tener en cuenta sobre el proceso de restauración:

• No puede restaurar desde un snapshot de base de datos a una instancia de base de datos existente. En su lugar, se crea una nueva instancia de base de datos al momento de restaurar. Si desea utilizar el mismo nombre que la instancia de base de datos existente, primero debe eliminar o cambiar el nombre de la existente.
• Si bien es posible restaurar un snapshot de base de datos a una instancia de base de datos con un tipo de almacenamiento diferente al de la instancia de base de datos de origen, el proceso de restauración es más lento. Se requiere trabajo adicional para migrar los datos a un nuevo tipo de almacenamiento
• No se puede restaurar una instancia de base de datos desde un snapshot de base de datos compartido que esté cifrado (encrypted). En su lugar, haga una copia del snapshot de base de datos y, a continuación, restaure la instancia de base de datos utilizando esa copia.
• Se recomienda conservar el grupo de parámetros (parameter group) de cualquier snapshot de base de datos que cree. Esto le permite restaurar la instancia de base de datos con el grupo de parámetros correcto.
• Cuando se restaura desde un snapshot de base de datos, de forma predeterminada, el grupo de opciones (option group) asociado al snapshot de base de datos se asocia a la instancia de base de datos restaurada. Puede asociar un grupo de opciones diferente a una instancia de base de datos restaurada. Sin embargo, el nuevo grupo de opciones debe contener cualquier opción persistente o permanente que se haya incluido en el grupo de opciones original.

Para instrucciones detalladas por favor lea el capítulo Restaurando desde un Snapshot de Base de Datos en la guía del usuario de Amazon RDS.

Restaurando en otras regiones de AWS

Como se ha explicado anteriormente, para realizar una restauración entre regiones de un snapshot de base de datos, primero copie el snapshot en la región deseada. A continuación, puede restaurar el snapshot de base de datos en una nueva instancia de base de datos.

Integración con AWS Backup

Los snapshots de base de datos de Amazon RDS se pueden integrar con AWS Backup. AWS Backup es un servicio de copia de seguridad totalmente administrado que puede utilizar para centralizar y automatizar la copia de seguridad de los datos en los servicios de AWS en la nube y en los centros de cómputo del cliente. Con AWS Backup, puede configurar de forma centralizada las políticas de respaldo y monitorear la actividad de respaldo de sus recursos de AWS. Para obtener más información por favor consulte la documentación de AWS Backup.

Réplicas de Lectura

Amazon RDS para MariaDB, MySQL, PostgreSQL, SQL Server y Oracle admiten la capacidad de crear réplicas de lectura de una base de datos de origen. Al crear una réplica de lectura, Amazon RDS primero toma un snapshot de la instancia de base de datos de origen y, a continuación, crea una instancia de solo lectura. Amazon RDS utiliza el método de replicación asíncrona del motor de base de datos para actualizar la réplica de lectura siempre que se realice un cambio en la instancia de base de datos de origen. La réplica de lectura funciona como una instancia de base de datos que solo permite conexiones de lectura. Las aplicaciones se pueden conectar a una réplica de lectura del mismo modo que lo hacen con cualquier instancia de base de datos. Amazon RDS replica todos los objetos de la instancia de base de datos de origen. De forma predeterminada, se crea una réplica de lectura con la misma clase y el mismo tipo de almacenamiento que la instancia de base de datos de origen. Sin embargo, puede crear una réplica de lectura que tenga un tipo de almacenamiento diferente al de la instancia de base de datos de origen. Puede crear hasta cinco réplicas de lectura por instancia de base de datos de origen.

Además de usar réplicas de lectura para reducir la carga en la instancia de base de datos de origen, también puede usar réplicas de lectura para implementar una solución de recuperación de desastres (DR) para su ambiente de base de datos de producción. Si la instancia de base de datos de origen falla, puede promover su réplica de lectura a un servidor de origen independiente. Las réplicas de lectura también se pueden crear en una región diferente a la de la base de datos de origen. El uso de una réplica de lectura en múltiples regiones puede ayudar a garantizar que su aplicación vuelva a funcionar rápidamente si experimenta un problema de disponibilidad regional.

Una métrica importante para monitorear con una réplica de lectura es el retraso de la réplica (replica lag), que es la cantidad de tiempo que la réplica está detrás de la base de datos de origen. Un retraso en la réplica puede afectar su recuperación. El retraso de la réplica puede variar en función de la latencia de la red entre las regiones de origen y destino. También puede verse afectado por la cantidad de tráfico que se replica. Como las réplicas de lectura tienen una instancia de base de datos en ejecución, el tiempo necesario para recuperarse después de un desastre es menor. Sin embargo, el uso de réplicas de lectura de esta manera suele ser una opción más costosa que el uso de snapshots de bases de datos automatizados o manuales.

Para instrucciones detalladas sobre como crear réplicas de lectura por favor refiérase al capítulo Trabajando con Réplicas de Lectura en la guía del usuario de Amazon RDS.

Promoviendo una Réplica de Lectura

A diferencia de una configuración Multi-AZ de Amazon RDS, el failover a una réplica de lectura no es un proceso automatizado. Si utiliza réplicas de lectura entre regiones, debe asegurarse de que desea cambiar sus recursos de AWS a la región secundaria. El tráfico entre regiones puede experimentar latencia y la reconfiguración de las aplicaciones puede resultar complicada

Para instrucciones detalladas por favor haga referencia al capítulo Promoviendo Réplicas de Lectura de la guía del usuario de Amazon RDS.

Después de convertir una réplica de lectura en una región secundaria para que sea una instancia independiente, si más adelante desea volver a la región original, debe crear una nueva réplica de lectura. A diferencia de una configuración Multi-AZ de Amazon RDS, esto no se hace automáticamente.

Probando su plan de recuperación de desastres (DR)

Un plan de recuperación de desastres (DR) solo es útil si se prueba y valida periódicamente. Probar su plan de DR le ayuda a identificar posibles problemas o brechas para que pueda tomar medidas correctivas. Un plan completo de DR incluye no solo los recursos de su base de datos, sino también toda la infraestructura de sus aplicaciones. Si bien una prueba completa del plan de DR puede llevar una cantidad significativa de tiempo y recursos, ayuda a garantizar que se sienta seguro de que funcionará cuando sea necesario.

Resumen

En este blog he compartido algunas prácticas recomendadas para implementar una estrategia de recuperación de desastres (DR) con Amazon RDS. Esta publicación proporciona un marco básico que puede implementar en Amazon RDS para DR mediante respaldos automatizados, respaldos manuales y réplicas de lectura. También he destacado algunos conceptos clave, como la recuperación a un punto en el tiempo, el uso compartido de snapshots de bases de datos entre cuentas de Amazon RDS y la creación de réplicas de lectura entre regiones.

Este artículo fue traducido automáticamente del  Blog de AWS en Inglés.

Sobre el autor

Anuraag Deekonda es un Consultor especializado en migraciones del equipo de servicios profesionales de Amazon Web Services. Anuraag trabaja con los clientes para crear soluciones escalables, de alta disponibilidad y seguras en la nube de AWS. Su área de enfoque son las migraciones homogéneas y heterogéneas de bases de datos locales a Amazon RDS y Aurora PostgreSQL

Sobre el traductor

Camilo Leon es un Arquitecto de Soluciones Principal especializado en bases de datos en Amazon Web Services. Camilo Trabaja con clientes de AWS para proporcionar orientación y asistencia técnica en servicios de bases de datos relacionales, ayudándoles a mejorar el valor de sus soluciones cuando utilizan AWS.