‘Disaster Recovery Scenary’ con Microsoft Azure (I)

Comencemos con las definiciones. Según Wikipedia un Plan de Recuperación ante Desastres (del inglés Disaster Recovery Plan) es un proceso de recuperación que cubre los datos, el hardware y el software crítico, para que un negocio pueda comenzar de nuevo sus operaciones en caso de un desastre natural o causado por humanos.

Esto también debería incluir proyectos para enfrentarse a la pérdida inesperada o repentina de personal clave, y aunque esto no es objeto de este artículo, es una parte consustancial de un plan de este tipo, e implica en todos los supuestos, procedimientos de activación, operación y vuelta a la normalidad que será necesario diseñar, validar, verificar y actualizar permanentemente.

Otros dos términos que manejaremos y que hay que tener perfectamente definidos son Recovery Time Objective (RTO) y Recovery Point Objective (RTO). Para simplificar, diremos que hacen referencia al tiempo máximo en que debemos recuperar los servicios y el punto en el que queremos recuperarlos.

El primero es el más sencillo de entender: es el tiempo que queremos tardar, como máximo, en volver a disponer de nuestros servicios (ERP, CRM, etc.). El segundo hace referencia a la cantidad de datos o procesos que podemos aceptar perder. Es decir un RTO de 24 horas significa que para nosotros es aceptable perder los datos de las últimas 24 horas, o lo que es lo mismo, una vez levantados nuestros sistemas de nuevo, que estos se encuentren en el estado en que estaban 24 horas antes.

Estos dos términos van a definir la complejidad de nuestro proceso de Disaster Recovery (DR), pero sobre todo, van a ser las variables fundamentales a la hora de determinar los costes de nuestra protección.

Para los que ya llevamos algún tiempo en el mundo IT, es sabido que el paradigma del DR cambió con los atentados del 11-S y la caída de las Torres Gemelas debido una situación que hasta entonces no había parecido plausible: algunas empresas que desaparecieron tras los atentados, lo hicieron no por verse implicadas directamente en los mismos y haber sufrido daños, sino porque sus centros de respaldo y DR se encontraban dentro de la Zona 0, y aunque no sufrieron daños, no fueron accesibles durante días.

A partir de dicho momento la distancia de aseguridad entre el CPD y su centro de respaldo se incrementó considerablemente. Es curioso cómo hacer esto, en entorno Cloud, soslaya completamente este inconveniente, e incluso, juega a nuestro favor.

Entre las múltiples funcionalidades/facilidades que Microsoft poco a poco va incorporando a su plataforma Cloud Azure, está Azure Site Recovery una de las más interesantes por varios factores ya que puede entrar a formar parte de nuestra panoplia de recursos frente a una situación de DR:

El coste es contenido
La implementación no es muy complicada (al menos en su versión básica, que es la que veremos en estas líneas)
Resuelve una situación catastrófica que impacta en la disponibilidad de los recursos IT de la compañía y por tanto en el negocio de esta.
Los centros de respaldo se pueden ubicar en lugares alejados unos de otros, incluso más allá de fronteras nacionales, por lo que el concepto de distancia de seguridad se preserva (salvo una catástrofe planetaria, en cuyo caso, tampoco tendría mucha importancia).

¿Te interesa ampliar más sobre este tema? Pues sigue muy atento porque pronto os seguiré contando como, de una manera simplificada y partiendo de una infraestructura implementada en el datacenter de Microsoft en Dublín, cómo podemos montar y activar un centro de respaldo en el datacenter de Ámsterdam.

Descubre cómo SOGETI puede ayudarte a dar el salto a la nube.

Borja Cabellos