cover

¿Por qué una estrategia de recuperación ante desastres?

Asegurar la continuidad del negocio es la necesidad principal de toda organización y esto se cumple brindando una respuesta ante un desastre o emergencias que pueda afectar los sistemas de información, sin embargo, siempre existirán variaciones de RTO y RPO principalmente lo cual será acorde al nicho de negocio de cada empresa, es por ello que resulta importante tener claro los objetivos para cada uno de los activos de la organización y partiendo de estos se podrá definir la mejor estrategia a seguir para respaldos y recuperación ante desastres.

Asegurar la continuidad del negocio es la necesidad principal de toda organización y esto se cumple brindando una respuesta ante un desastre o emergencias que pueda afectar los sistemas de información, sin embargo, siempre existirán variaciones de RTO y RPO principalmente lo cual será acorde al nicho de negocio de cada empresa, es por ello que resulta importante tener claro los objetivos para cada uno de los activos de la organización y partiendo de estos se podrá definir la mejor estrategia a seguir para respaldos y recuperación ante desastres.


Establecer objetivos. Recovery Point Objective (RPO)


Es la cantidad de tiempo máxima aceptable de perdida de datos desde el último punto de recuperación. Este objetivo determina lo que se considera una pérdida de datos aceptable entre el último punto de recuperación y la interrupción del servicio y es definida por la organización.


RPO es el tiempo entre la última copia de seguridad creada y el momento del desastre. Una vez definido el objetivo de RPO de la empresa, esto nos ayudará a definir la mejor estrategia de respaldo.


Para sistemas críticos, se recomienda un RPO de 15 minutos para un buen compromiso entre la carga del sistema y el tiempo de procesamiento.


Recovery Time Objective (RTO)


Es la demora máxima aceptable entre la interrupción y el restablecimiento del servicio. Este objetivo determina lo que se considera una ventana de tiempo aceptable cuando el servicio no está disponible.


Imagen blog

Esta es la fase en la cual se recuperan todos los sistemas y se verifica la integridad del sistema o de los datos, de esta forma todos los sistemas críticos pueden reanudar la operación. Uno de los ejemplos mas claros de esta etapa puede ser, verificar las bases de datos y registros, asegurándose de que las aplicaciones y/o servicios se estén ejecutando y estén disponibles.


Esta resulta una de las etapas más importantes, dado que depende de los responsables de los servicios para poder asegurar que estos se encuentren funcionando en optimas condiciones, existen practicas en donde se recomienda automatizar el levantamiento de servicios desde el encendido del servidor dado que esto agiliza y reduce los tiempos de validación y recuperación, y a su vez permite disminuir el tiempo que se está fuera de servicio.


Imagen blog

Estrategias de Recuperación en la nube


Una vez que se tienen definidos los tiempos de RTO y RPO se procede a determinar la mejor estrategia de DRP, dichas estrategias se listan a continuación.

  • Backup & Restore

  • Pilot Light

  • Warm standby

  • Multi-site active/active

Imagen blog

Esta estrategia se vuelve el enfoque adecuado para reducir la pérdida o la corrupción de los datos, en AWS esta estrategia brinda la posibilidad de recuperar los datos en diversas regiones en caso de existir una falla en la región productiva.


Para estos casos el proceso de recuperación consiste en volver a levantar la infraestructura, por ello resulta importante contar con estrategias que permitan levantar los recursos rápidamente y que puedan reducir el margen de error, algunos ejemplos de ello son: el uso de Lauch Template de EC2 que permite almacenar las características del servicio actual, o bien hacer uso de estrategias como Infraestructure as Code (IaC) ya que esto permite lanzar todos los recursos de una sola vez, reduciendo el margen de error humano.


Pilot Light


Este enfoque permite replicar los datos desde on premise, otra nube o una región de AWS hacia otra región de AWS, en el proceso se aprovisiona una copia de la infraestructura de la carga de trabajo principal. En esta estrategia de DR los recursos necesarios para replicar los datos siempre se encuentra activo y los recursos tales como los servidores de aplicación y sus configuraciones, se encuentran apagados hasta que se realice un ejercicio de recuperación o bien durante la conmutación por error ante un desastre, es por ello por lo que esta estrategia permite tener un ahorro de costos, debido a que estos se minimizan dado que solo existen recursos en los cuales se están replicando los datos.


Warm standby


Esta estrategia de DR se asegura que siempre exista una copia reducida del ambiente productivo, esto quiere decir que el ambiente podrá brindar una respuesta a las solicitudes pero con una capacidad reducida, es decir, no podrá manejar el mismo trafico que en producción, sin embargo, cuando un desastre en comparación con las dos estrategias previas, en esta se reducen los tiempos de recuperación dado que se realiza una conmutación a este ambiente y solo será necesario incrementar el tamaño de los recursos o bien implementar una estrategia de auto escalamiento para que los recursos necesarios se aprovisionen de forma automática según la demanda.


Multi-site active/active


Esta estrategia de DRP es muy similar al Warm Standby, dado que se debe mantener una copia del ambiente productivo, la diferencia con el anterior es que en esta estrategia la copia deberá contar con las mismas capacidades que en producción, en este caso, para esta estrategia la principal recomendación es vincular los ambientes con un administrador de dominio, en el caso de AWS hablamos de Route 53, el cual permitirá redirigir el tráfico de manera casi inmediata al ambiente de DR, es importante mencionar que mientras más se acerque la solución al punto de recuperación cero más costoso será.


Contáctanos para cualquier duda o comentario que tengas.

Fuente: Disaster recovery options in the cloud https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html

Fecha de publicación: 11/4/2024

Autor: Daniela Blanco | Solution Architect

Estos blogs podrían interesarte