Recuperación en caso de catástrofe

Existen varios enfoques o estrategias de recuperación de desastres (DR) que pueden servir de apoyo a un plan de recuperación de desastres. Dependiendo de su caso de uso, puede mezclar y combinar estos enfoques en función de las cargas de trabajo, los entornos, los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) que defina su organización.

La copia de seguridad y la restauración son fundamentales en cualquier planteamiento de recuperación en caso de catástrofe. Asegúrate de que al menos haces copias de seguridad de los datos de tu carga de trabajo. De acuerdo con el modelo de responsabilidad compartida IBM Cloud, debe tener copias de seguridad recuperables de sus datos que estén disponibles para restaurar si se produce un desastre. Para obtener más información, consulte Responsabilidades compartidas por el uso de productos IBM Cloud. Para asegurarte de que entiendes cómo acceder a los archivos de copia de seguridad y restaurarlos, revisa la documentación de cada servicio.

Esperar a que IBM Cloud se recupere una región o servicio afectado es una vía válida, pero recuerda que puede tardar muchas horas o más. Revise la Tabla 1. para conocer los enfoques de RD que ofrecen distintos niveles de velocidad de recuperación, complejidad y coste.

Enfoques de recuperación en caso de catástrofe y posibles tipos de cargas de trabajo, tolerancia al tiempo de inactividad y coste y complejidad de mantenimiento.
Enfoque	Tipo de carga de trabajo	Tolerancia al tiempo de inactividad	Coste y complejidad
Huella cero	No crítico	Tiempo de inactividad prolongado	Bajo
Espera básica	Semicrítico	Varias horas	Medio
Funcionamiento mínimo	Semicrítico	Unas horas	Medio
Activa/Activa	Sistemas críticos	Tiempo de inactividad cero	Alto

La huella cero sólo es adecuada para sistemas que toleran tiempos de inactividad prolongados, como los entornos de desarrollo y pruebas no críticos. Es una opción rentable que se basa en la capacidad de la computación en nube para ampliar rápidamente los recursos cuando es necesario, en lugar de mantener sistemas de reserva. El modo de espera básico se basa en el enfoque de huella cero mediante la creación previa de algunos componentes que, de otro modo, pueden tardar en aprovisionarse. El funcionamiento mínimo es adecuado para cargas de trabajo en las que se pueden tolerar unas pocas horas de inactividad, lo que reduce el coste global. Los sistemas Crucial, que toleran un tiempo de inactividad cero, funcionan en una configuración activa-activa interregional activa/acitiva. Mantener los sistemas en una configuración activa/activa supone el mayor coste y esfuerzo. Para su plan de DR, puede combinar enfoques que se adapten a las diferentes cargas de trabajo, especialmente cuando el presupuesto es una limitación.

Para elegir un enfoque, es importante saber si el servicio realiza automáticamente copias de seguridad de tus datos y cómo se realizan las copias de seguridad dentro del servicio. Revisa la documentación de cada servicio para saber dónde se almacenan las copias de seguridad, cómo restaurarlas y dónde puedes recuperarlas.

Si el servicio realiza automáticamente copias de seguridad de tus datos, incluidas las instantáneas, comprueba que se almacenan de forma interregional o en buckets que se replican en otra región. Si un servicio no realiza copias de seguridad automáticamente, es necesario configurar dicho almacenamiento o replicación de copias de seguridad.

Considere el alcance de la recuperación que podría necesitar para cada catástrofe concreta. Una catástrofe puede inhabilitar una región entera o una sola instancia de servicio. Adapte su planteamiento a los escenarios que planifique y hágase las siguientes preguntas:

¿Permite mi plan la recuperación de uno o varios servicios en nube de forma aislada?
¿Hasta qué punto es flexible mi carga de trabajo con servicios ubicados en distintas regiones?
Si recupero un solo servicio, ¿cuál es el impacto en mis cargas de trabajo, necesito recuperar algo más?
¿Qué cambios de configuración pueden ser necesarios en mis aplicaciones para que apunten a diferentes instancias de servicio y hasta qué punto es sencillo realizar dichos cambios?

Trabajar con diferentes escenarios de catástrofe enriquece su planificación.

Los siguientes enfoques de DR se centran en la VPC y los servicios de base de datos como ejemplos. Los mismos principios generales se aplican a otros servicios IBM Cloud.

Enfoque 1: Huella cero

Un planteamiento de huella cero tiene el tiempo de recuperación global más largo y el perfil de costes más bajo. Para muchas organizaciones, la huella cero no es aceptable para las cargas de trabajo de producción, pero es una buena opción para el desarrollo, las pruebas del sistema u otras cargas de trabajo que ocupan un lugar bajo en la lista de prioridades de recuperación.

Resumen del enfoque de huella cero:

En una segunda región no hay infraestructuras ni servicios. Todo se vuelve a crear si se produce una catástrofe.
La copia de seguridad de los datos del servidor se realiza mediante una instantánea interregional.
Los datos de la base de datos se recuperan utilizando copias de seguridad de la base de datos.
Uso de Infrastructure as Code a través de IBM Cloud Schematics para desplegar su entorno.
Utilizar cadenas de herramientas para desplegar el código de las aplicaciones.
Adecuado para los RTO y RPO menos estrictos, aunque algunas bases de datos admiten la recuperación puntual.
Permite recuperar datos dañados.

Para permitir una reconstrucción precisa y más rápida del entorno, cree y utilice una cadena de herramientas que despliegue servicios de infraestructura mediante IBM Cloud Schematics. A continuación, despliegue código en esos servicios utilizando repositorios de código Git.

Para realizar copias de seguridad y replicar datos que se escriben en volúmenes de almacenamiento en bloque o en almacenamiento de archivos, utilice Backup for VPC. Compruebe que la copia de seguridad se almacena como instantáneas de copia de seguridad entre regiones y que la replicación de almacenamiento de archivos está activa.

Un método alternativo consiste en desplegar y configurar un agente de Veeam en cada servidor o un servidor central de Veeam Backup and Replication o un software de backup similar "traiga su propio". En función de la herramienta elegida, elabore un programa de copia de seguridad o replicación adecuado. Si decide utilizar Veeam, escriba los archivos de copia de seguridad en un bucket Object Storage. El bucket debe ser interregional o, cuando las necesidades de cumplimiento lo requieran, estar configurado para replicarse en otro bucket específico alojado en una segunda región de su elección.

Para las VSI que ejecutan sistemas operativos Linux, el cubo puede montarse directamente utilizando s3fs basado en FUSE. Para las VSI que ejecutan Microsoft Windows, Rclone es la herramienta preferida para el montaje directo. Rclone es una herramienta de símbolo del sistema de código abierto que se utiliza para gestionar archivos en el almacenamiento en la nube, incluyendo Object Storage. En cada caso, el cubo se monta como una unidad de red y funciona de forma similar a una unidad compartida del Sistema Común de Archivos de Internet (CIFS) o del Sistema de Archivos de Red NFS ). La instalación del agente de Veeam y el montaje del bucket se pueden programar y automatizar en el momento de la provisión de VSI, utilizando la configuración de datos de usuario. Asegúrese de utilizar el punto final adecuado para el cubo.

Si está utilizando Databases for MySQL, IBM Cloud Databases for PostgreSQL, o IBM Cloud Databases for MongoDB, la recuperación puntual a partir de copias de seguridad está disponible. La recuperación puntual funciona registrando automáticamente todos los cambios transaccionales que se producen después de una copia de seguridad completa en archivos de registro de transacciones o similares. El proceso vuelve a comenzar cuando se realiza la siguiente copia de seguridad completa. Cuando se recupera la base de datos, el administrador de la misma define un punto de restauración dentro de los últimos 7 días. A continuación, la copia de seguridad completa más cercana antes de ese momento se restaura en una nueva instancia. Por último, se reproducen los cambios transaccionales registrados, hasta el momento definido. El último punto en el tiempo para la recuperación es aquel en el que se registró el último cambio transaccional y está disponible en la base de datos de origen. Las restauraciones de este tipo siempre se realizan hacia delante, no hacia atrás. No se puede restaurar una copia de seguridad y retroceder deshaciendo transacciones. Las bases de datos que no ofrecen recuperación puntual pueden recuperarse hasta el punto de la última copia de seguridad. Los cambios transaccionales no se les aplican, por lo que las transacciones que tienen lugar después de la copia de seguridad se pierden en la recuperación. Las copias de seguridad se realizan automáticamente cada 24 horas y los archivos de copia de seguridad se colocan en un bucket interregional Object Storage para mayor resistencia. La recuperación es posible a cualquier otra región multizona, excepto a través de los límites de la zona de cumplimiento.

Las restauraciones de bases de datos pueden tardar varias horas en completarse.

Además de las copias de seguridad automáticas de las bases de datos, los clientes pueden realizar copias de seguridad bajo demanda. Cada 24 horas se realiza una copia de seguridad automática. A menos que se disponga de una recuperación puntual, pueden perderse hasta 24 horas de transacciones cuando se restaura una copia de seguridad diaria. Las copias de seguridad bajo demanda que se realizan durante el periodo de 24 horas reducen la pérdida de datos transaccionales. Las copias de seguridad bajo demanda pueden realizarse a través de la consola, una llamada CLI o mediante una llamada API. El uso de llamadas CLI o API permite automatizar las copias de seguridad mediante una simple tarea cron. Todas las copias de seguridad bajo demanda también se escriben en un bucket multirregión Object Storage.

Si utiliza otra base de datos, consulte la documentación del producto sobre el método de copia de seguridad más adecuado. Por lo general, realice una copia de seguridad de los datos en un bucket interregional Object Storage, incluido cualquier registro que proporcione una recuperación puntual.

Diagrama que representa un ejemplo de arquitectura para una solución DR de huella cero

Enfoque 2: Espera básica

El enfoque básico de espera difiere del Enfoque 1 porque algunos elementos del entorno de RD se construyen fuera, en particular los servicios de red que tienen un plazo de entrega más largo. Los elementos construidos reducen el RTO global si se recurre a la RD, pero conllevan un coste financiero continuo. El coste de la espera básica se reduce en comparación con el mantenimiento de un entorno de RD de "funcionamiento mínimo".

Resumen del planteamiento básico de espera:

En una segunda región se aprovisiona y configura una infraestructura limitada.
Se aprovisiona y configura la infraestructura de red que tiene plazos de entrega más largos, como equilibradores de carga globales, Direct Link, VPN o similares.
Se crea y se apaga un número limitado de imágenes VSI para proporcionar una recuperación más rápida con un coste mínimo.
Utiliza grupos de autoescalado para escalar rápidamente.
Utilizar bases de datos de réplica de lectura, cuando sean compatibles.
Un RTO más rápido en comparación con el Enfoque 1, ya que algunos servicios se crean previamente.

Considere la posibilidad de implantar la infraestructura como código IaC ) para desplegar la infraestructura y la configuración tanto de producción como de RD. Almacene y mantenga el código fuente IaC en un único repositorio para una replicación precisa en la región DR. Hacer coincidir los servicios y la configuración de la región de RD con los de la región de producción evita problemas causados por errores de configuración que luego lleva tiempo identificar y solucionar.

Los costes de tiempo de ejecución pueden reducirse para los servicios -en particular, las máquinas virtuales- que se aprovisionan, configuran y luego se apagan. Utilice técnicas de creación de plantillas de instancias y autoescalado para escalar rápidamente y soportar la capacidad de carga de trabajo necesaria.

Para evitar los retrasos asociados a los plazos de entrega, se aprovisionan determinados elementos de red. Los elementos de red incluyen Direct Link, que pueden tener plazos de entrega significativos, conexiones VPN y equilibradores de carga globales. Si se produce una catástrofe, se puede establecer una configuración para redirigir rápidamente el tráfico a la región DR, sin necesidad de realizar cambios de conexión en el extremo del cliente.

Como antes, para realizar copias de seguridad y replicar datos que se escriben en volúmenes de almacenamiento en bloque o en almacenamiento de archivos, utilice Backup for VPC. Compruebe que la copia de seguridad se almacena como instantáneas de copia de seguridad entre regiones y que la replicación de almacenamiento de archivos está activa.

Un método alternativo consiste en desplegar y configurar un agente de Veeam en cada servidor o un servidor central de Veeam Backup and Replication o un software de backup similar "traiga su propio". En función de la herramienta elegida, elabore un programa de copia de seguridad o replicación adecuado. Si decide utilizar Veeam, escriba los archivos de copia de seguridad en un bucket IBM Cloud Object Storage. El bucket debe ser interregional o, cuando las necesidades de cumplimiento lo requieran, estar configurado para replicarse en otro bucket específico alojado en una segunda región de su elección.

Es posible crear una base de datos de réplica de lectura en la región elegida para DR para determinadas bases de datos de IBM Cloud. En la segunda región se mantiene automáticamente una copia de la base de datos, que puede convertirse en una copia autónoma en caso de desastre. Las réplicas de lectura proporcionan un RTO más estricto, mientras que la replicación asíncrona desde la base de datos de producción pretende limitar cualquier pérdida de datos transaccionales a menos de 15 minutos.

Para otros servicios de IBM Cloud Database, la última copia de seguridad debe restaurarse en una nueva instancia en la región de DR, teniendo en cuenta que algunos tipos de bases de datos proporcionan recuperación puntual. Para las bases de datos que no ofrecen recuperación puntual, realice copias de seguridad bajo demanda además de la copia de seguridad diaria automática para reducir la pérdida de datos. Las copias de seguridad bajo demanda se pueden programar como una tarea cron o utilizar IBM Cloud Code Engine. Las restauraciones de bases de datos pueden llevar varias horas o más, y el tiempo empleado aumenta con el volumen de la base de datos.

En cada uno de estos casos, la pérdida de datos depende de la hora de la última copia de seguridad disponible de la base de datos, que puede ser de hace hasta 24 horas.

Diagrama que representa un ejemplo de arquitectura para una solución DR de reserva básica

Enfoque 3: Funcionamiento mínimo

El enfoque de operación mínima difiere del Enfoque 2 porque se mantiene y ejecuta un servicio mínimo en el emplazamiento de RD, lo que reduce el RTO. Se incluye el tejido de red, como Direct Link, las VPN y los equilibradores de carga globales, que de otro modo podrían tener plazos de entrega de varios días.

Resumen del planteamiento de operación mínima:

La infraestructura mínima se aprovisiona, configura y activa en una segunda región.
El autoescalado se utiliza para aprovisionar capacidad rápidamente.
Se dispone de infraestructura de red como Direct Link, VPN for VPC y equilibradores de carga globales.
Los datos se restauran con frecuencia en la región DR.
Las réplicas de lectura de la base de datos se realizan in situ, siempre que estén disponibles.
El funcionamiento mínimo proporciona un RTO más rápido, ya que los servicios están en funcionamiento y los datos se restauran al menos parcialmente.

Las copias de seguridad de los datos se aplican a los servicios DR activos con una frecuencia que admite un RTO más agresivo. Las copias de seguridad pueden automatizarse mediante la ejecución de trabajos IBM Cloud Code Engine.

En caso de catástrofe, se lleva a cabo la recuperación de las copias de seguridad pendientes y no aplicadas y se escalan los servicios hasta un nivel adecuado. Si se utiliza una réplica de lectura IBM Cloud Database, la réplica de lectura se transforma en una copia independiente.

Diagrama que muestra un ejemplo de arquitectura para una solución DR de funcionamiento mínimo

Enfoque 4: Activo/activo

El enfoque activo/activo consiste básicamente en ejecutar dos despliegues, cada uno de los cuales se utiliza en las operaciones cotidianas. Tener dos regiones de producción erradica el tiempo de recuperación, aparte de aumentar los recursos en el sitio superviviente, pero es más complejo desde el punto de vista de los datos.

Utilizar el enfoque activo/activo:

Se han construido dos regiones y cada una de ellas se utiliza activamente.
Las bases de datos mantienen dos copias, una por región.
Proporciona el RTO más rápido, ya que los servicios se ejecutan en la segunda región.
El planteamiento aumenta la complejidad.

La gestión de los datos cambiantes de la aplicación es la consideración más compleja con este enfoque. Cuando se utilizan bases de datos, un despliegue activo/activo real tiene bases de datos que se pueden leer y escribir en dos regiones. Para mantener ambas copias sincronizadas, las cargas de trabajo del cliente deben gestionar y verificar que las escrituras se realizan correctamente en ambas instancias de la base de datos, mediante código de aplicación.

En sentido estricto, activo/activo no es realmente un enfoque para la recuperación de desastres. En su lugar, es un enfoque para ayudar a garantizar una alta disponibilidad en la que se elimina una región de IBM Cloud Cloud como posible punto único de fallo. Si se detecta un fallo, es necesario tomar medidas para escalar los servicios rápidamente y que todas las solicitudes de conexión se resuelvan en la región superviviente.

Diagrama que representa un ejemplo de arquitectura para una solución Activo/Activo