DRaaS: la recuperación de desastres como servicio en el cloud

DRaaS

Por José Luis Colom Planas

La DRaaS (Recuperación de Desastres como servicio en el CLOUD) es un componente de un DRP (Plan de Recuperación de Desastres) que implica el mantenimiento de copias de los datos empresariales en un entorno de almacenamiento en el CLOUD, como medida de seguridad. Hay una serie de ventajas que lo hacen atractivo, en su mayoría relacionadas con la reducción de costes.

1. INTRODUCCIÓN A LA CONTINUIDAD DEL NEGOCIO.

1.1. Normativa existente.

Como consecuencia de la creciente preocupación de las empresas para preservar su continuidad en el tiempo, aparece la Norma ISO 22301:2012 sobre Gestión de la Continuidad del Negocio.

Se trata de un nuevo estándar internacional, que especifica los requisitos para configurar y gestionar de forma eficaz un SGCN o Sistema de Gestión de la Continuidad de Negocio. En inglés BCMS (Business Continuity Management System).

Hasta la fecha, solamente disponíamos dentro de la familia de Normas ISO 270xx, el objetivo 14.1 “Aspectos de seguridad de la información en la gestión de la continuidad del negocio”, que incluye los controles del 14.1.1 al 14.1.5 del apéndice A de la Norma ISO 27001:2008 y de su equivalencia en la Norma ISO 27002:2005.

La continuidad del negocio es parte de la gestión general del riesgo en una compañía y tiene áreas superpuestas con la gestión de la Seguridad de la Información y la Gestión de Servicios de TI.

Si se planifica, implementa y revisa periódicamente, la gestión de la continuidad del negocio disminuirá la posibilidad de ocurrencia de un incidente disruptivo y, en caso de producirse, la organización estará preparada para responder en forma adecuada, reduciendo drásticamente el daño o impacto potencial de ese incidente.

Una vez determinado el alcance del SGCN dentro del contexto de la organización, logrado el compromiso de la Dirección, definidas las políticas, contemplada la legislación vigente en materia de protección de datos, hecho un análisis de riesgos y decidido su tratamiento tras evaluarlos, ya estamos en condiciones de establecer e implementar los procedimientos necesarios para la continuidad del negocio.

Como se trata de un sistema de gestión basado en la mejora contínua (ciclo PDCA), deberán establecerse los mecanismos de revisión y mejora a lo largo del tiempo.

1.2. DRP (Disaster Recovery Plan).

Aunque no nos basemos en la Norma, lo que al menos se debería tener siempre es un BCP (Business Continuity Plan) o en su defecto un DRP (Disaster Recovery Plan).

Un desastre es un evento que hace que la continuación de los servicios y funcionalidades normales de la empresa, sean imposibles. Así, un DRP se compone de las precauciones a tomar para que los efectos de un desastre se reduzcan al mínimo y la organización sea capaz de mantener o reanudar rápidamente sus servicios y funcionalidades, al menos las de misión crítica.

Por lo general, la planificación de la recuperación de desastres no solo implica un análisis de los procesos de negocio y las necesidades de continuidad, sino que también puede incluir un enfoque significativo en la prevención de desastres.

La recuperación de desastres se está convirtiendo en un aspecto cada vez más importante de la informática empresarial. Como los dispositivos, sistemas y redes son cada vez más complejos, hay muchas mas cosas que simplemente pueden salir mal. Como consecuencia de ello, los planes de recuperación también se han vuelto más complejos.

La mediana y gran empresa suele tener los sistemas en CPDs dimensionados y complejos para tales enfoques simplistas mientras que las pymes lo que no tienen es presupuesto para implementar según qué DRP. Sin embargo, la interrupción del servicio o la pérdida de datos pueden tener un impacto financiero grave, ya sea directamente o a través de la pérdida de confianza del cliente, independientemente del tamaño de la empresa.

El DRP varía de una empresa a otra, en función de variables como el tipo de negocio, los procesos involucrados y el nivel de seguridad necesario.

Por una razón u otra, la realidad es que la mayoría de las empresas todavía están mal preparadas ante un desastre. Apenas el 50 por ciento de ellas afirman tener un DRP y de las que lo tienen, muchas nunca han probado su plan, lo que equivale a no tener ninguno en absoluto.

2. DRaaS (RECUPERACIÓN DE DESASTRES EN EL CLOUD).

2.1. Generalidades.

La DRaaS (Recuperación de Desastres como servicio en el CLOUD) es un componente de un DRP (Plan de Recuperación de Desastres) que implica el mantenimiento de copias de los datos empresariales en un entorno de almacenamiento en el CLOUD, como medida de seguridad.

Algunas empresas que todavía están recelosas de ubicar almacenamiento primario en el CLOUD, son más propensas a usar copias de seguridad basadas en la Nube o incluso a implementar allí un completo sistema de recuperación ante desastres.

Hay una serie de ventajas que hacen atractivo el DRaaS, en su mayoría relacionadas con la reducción de costes. El pago por uso lo hace asequible en contraposición a la necesidad de emplear otros recursos en una concepción clásica, si pensemos en la infraestructura de TI necesaria para el centro de datos replicado o de Backup.

Tomados en conjunto, estos ahorros del DRaaS significan que las pequeñas empresas puedan contemplar planes de recuperación de desastres, que habría sido imposible implementar de otra manera.

2.2. Aspectos a tener en cuenta.

Hay cuestiones de seguridad importantes a considerar en el DRP, antes de adoptar DRaaS. Conjuntamente con el  CSP (Cloud Services Provider), debe garantizarse que:

  • Los datos se transfieren hacia el CLOUD de forma segura.
  • Los usuarios en caso de contingencia, se autentifiquen  correctamente.
  • En caso de desastre, se tendrá el ancho de banda y la capacidad de red necesaria para redirigir a los usuarios al CLOUD (Cambio de Rol a destino).
  • El DRP también debe incluir detalles de cómo se van a restaurar los datos, cuando se restablezca la situación (Cambio de Rol a origen).

2.3. Glosario de términos empleados en un DRP.

RTO (Recovery Time Objective / Objetivo de Tiempo de Recuperación): Es el tiempo dentro del cual, un proceso o procesos empresariales deben ser restituidos después de un desastre (o interrupción)  con determinado nivel de servicio, con el fin de evitar consecuencias inaceptables asociadas a una ruptura en la continuidad del negocio.

RPO (Recovery Point Objective / Objetivo de Punto de Recuperación): Es el intervalo máximo tolerable en el que pueden perderse datos de un servicio de TI, tras ocurrir un desastre. En otras palabras, es el momento en el que los datos se restauran y se obtiene una perspectiva de los datos que se perderán durante el proceso de recuperación. Suele coincidir con el tiempo transcurrido desde el último backup o desde la última replicación, si ésta no es continua.

reto_rpo

3. DIFERENTES ENFOQUES DE DRaaS.

3.1. Proceso de elección.

Al igual que con DR tradicional, no existe un modelo único para la recuperación de desastres en el CLOUD. El proceso de elaboración de un DRP se inicia con la identificación y priorización de Servicios, aplicaciones y datos, determinando para cada uno la cantidad de tiempo de inactividad que es aceptable antes de que haya un impacto empresarial significativo.

Priorizar los activos y determinar los necesarios objetivos de tiempo de recuperación (RTO), determinará el método adecuado de recuperación ante desastres.

cloud bssed

Tabla cortesía de SearchDisasterRecovery

Identificar los activos críticos y los métodos de recuperación, es el aspecto más relevante en este proceso, ya que es necesario asegurar de que todas las aplicaciones y datos así clasificados, están incluidos en el DRP. De igual modo, para controlar los costes y para asegurar la recuperación rápida y focalizada cuando el DRP debe ser ejecutado, debe asegurarse el dejar de lado las aplicaciones y los datos irrelevantes.

categorizacion

Categorización de activos  (C) ITIL:2011

Cuanto más focalizado esté el alcance de un DRP, más probable es que pueda verificarse periódicamente y ejecutarse caso de desastre, dentro de los objetivos definidos.

Con las aplicaciones identificadas y priorizadas, y definido el RTO, podrán determinarse los métodos mejores y más rentables de alcanzarlo.

Es infrecuente que se obtenga un único método DR para todas los Servicios, aplicaciones y datos. Lo más probable es terminar el proceso de análisis con varios métodos, protegiendo cada uno a grupos de aplicaciones y datos con un RTO similar.

tabla servicios DRaaS_IBM

Tabla cortesía de SmartCloud Virtualized Server Recovery de IBM

3.2. Ambos entornos, de producción y de Backup, en el CLOUD.

Una opción cada vez más popular es poner ambos en el CLOUD, tanto el entorno primario de producción, como el entorno secundario de RD, estando ambos a cargo de un MSP (Proveedor de Servicios Gestionados). De esta manera se aprovechan todos los beneficios del Cloud Computing, basado en el “pago por uso” para la eliminación de las instalaciones de infraestructura.

En lugar de hacerlo la empresa, ésta desplaza DR al CSP (Proveedor de Servicios en el Cloud).

La elección del proveedor de servicios y el proceso de negociación de las Cláusulas Contractuales y de los correspondientes acuerdos de nivel de servicio (SLAs), son de suma importancia.

NOTA DEL EDITOR: Puede consultarse un artículo sobre las Cláusulas Contractuales en entornos de Cloud Computing, en éste mismo Blog, mediante el siguiente enlace:

Cláusulas Contractuales

Al ceder parte de la Gestión al proveedor de servicios, la empresa debe estar absolutamente segura de que es capaz de ofrecer un servicio ininterrumpido dentro del SLA, definido tanto para los casos de entorno primario, como para los de entorno DR.

3.3. Solamente el entorno de Backup en el CLOUD.

Otra opción es tener como entorno primario un entorno tradicional y, realizar copias de seguridad y su restauración caso de contingencia,  en un entorno de CLOUD.

Las aplicaciones y los datos permanecen de forma local mediante este enfoque, con un proceso de copia hacia la nube y restaurándose desde ella en el hardware de las instalaciones de la empresa,  después de que se produzca un desastre.

Cuando se contempla la copia de seguridad y recuperación en el CLOUD, es crucial entender claramente ambos caminos. La copia de seguridad es sencilla, mientras que el aspecto más difícil es la  recuperación.

Con ancho de banda limitado y, quizá terabytes de datos a restaurar, lograr restaurar los datos de nuevo en las instalaciones de la empresa dentro de un RTO previamente definido, puede ser un reto.

En función de los datos que se van a restaurar, funcionalidades como la compresión y, más importante aún, la deduplicación, pueden facilitar y hacer viable las restauraciones de datos desde la nube, hacia la infraestructura en las instalaciones de la empresa.

3.4. Backup en el CLOUD, con restauración intermedia en VMs del CLOUD.

Otra opción en caso de desastre, es utilizar mientras duren sus efectos VM (Máquinas Virtuales) en el CLOUD, ya que con deduplicación, prácticamente sólo se tiene que restaurar una copia de máquina virtual completa y las diferencias de las demás. En este enfoque, los datos no se restauran inmediatamente en las instalaciones de infraestructura de la empresa, sino que se restablecen en las máquinas virtuales de la nube. Esto requiere tener pre-contratado almacenamiento en la nube y un pool de recursos.

La restauración a la situación original se puede hacer inmediatamente, después que la empresa recupere la infraestructura tras un desastre, o bien de manera “suave” y continuada hasta conseguir el nivelado, mientras se sigue trabajando con VMs en el CLOUD.

La “crianza” o mantenimiento previo de máquinas virtuales DR, consiste en mantenerlas relativamente puestas al día a través de replicaciones o restauraciones programadas. Es crucial en los casos en que RTO agresivos deban cumplirse.

replicacion_EMC_NetApp

3.5. Réplica de VMs en el CLOUD.

Para aplicaciones que requieran RTO (Objetivo de Tiempo de Recuperación) y RPO (Objetivos de Punto de Recuperación) agresivos,  la replicación es la mejor elección de movimiento de datos.

La replicación de máquinas virtuales en el CLOUD, se puede utilizar para proteger datos, tanto de VM a VM ambas en la nube, como de VM en las instalaciones hacia la nube.

Para éste método, el CSP normalmente proporciona puntos de recuperación consistentes con las aplicaciones. Suelen proveerse para las principales, como Exchange, SQL Server, Oracle, SharePoint, etc.

3.6. Resumen.

El CLOUD nos proporciona una serie de ventajas en relación al DR tradicional:

  • Amplía enormemente las opciones de recuperación ante desastres.
  • Los ahorros de costes son significativos.
  • Permite métodos de DR en pymes, que anteriormente estaban reservados a las grandes organizaciones.
  • No cambia, sin embargo, los fundamentos del DR:
  • Tener que elaborar un DRP (Plan de Recuperación de Desastres) sólido.
  • Tener que probarlo periódicamente.
  • Los usuarios deben estar concienciados y preparados adecuadamente.

4. ¿ESTÁ EL CLOUD PREPARADO PARA OFRECER UN SERVICIO DE DR?

Es importante para decidir si un servicio de recuperación de desastres es viable, analizar las necesidades de la empresa, entender la arquitectura de los sistemas críticos en el entorno primario o de producción y definir los RPO (Objetivos de Punto de Recuperación) y RTO (Objetivos de Tiempo de Recuperación).

Hay muchos casos en que la nube pública o “privada en modalidad off-premise”, está mejor preparada para el servicio de recuperación de desastres y es mas económica, que las soluciones tradicionales o basadas en infraestructuras dedicadas.

4.1. El escenario adecuado.

Estos escenarios adecuados, se reconocen por presentar las siguientes características:

Ningún deseo de “poseer” o intención de invertir capital alguno en una solución de recuperación de desastres, con predisposición a alquilar todas las tecnologías necesarias (licencias, almacenamiento, tratamiento, servicios) en modalidad de “pago por uso” mensual.

Enviar las copias de seguridad replicando (esperemos que deduplicadas) a una ubicación “off-premise” o fuera del sitio.

Configurarse para estar “always-on” en una red “resiliente”, con AD (Autentificación de Directorio o equivalente) y “encaminadores” o firewalls que garanticen la reorientación inmediata de los usuarios desde un directorio principal, caso de interrupción de la red o de un desastre completo.

Emplear plataformas tecnológicas comunes que aprovechen la virtualización (virtualización x86) y/o crear particiones (por ejemplo, LPAR de Power Systems “i”) que pueden ser segregables.

Deseo de externalizar la implementación de su RDP y trasladar el riesgo de desempeño a un proveedor de servicios capaz, que será el propietario del acuerdo de nivel de servicio (SLA) para los datos de entorno secundario de la replicación, pruebas, documentación y personal para llevar a cabo la restauración.

Deseo de maximizar las reclamaciones que se puedan obtener de los seguros, en caso de desastre.

4.2. Análisis de un caso.

Analicemos un caso, basado en una empresa con dichas características, paso a paso:

Se contrató el servicio de implantar el DRP a un CSP, con un RPO de 12 a 24 horas y un RTO de 4 a 8 horas, ambos comprobables.

Todo se contrató en modalidad de “pago por uso” mensual (OPEX frente a CAPEX).

Debido a la deduplicación y a la “siembra inicial de los datos”, el ancho de banda actual disponible con Internet, agregando un túnel VPN seguro, pudo ser aprovechado para el tráfico de replicación. Una segunda conexión redundante de backup, se contrató por seguridad al TSP (Proveedor de Servicios de Telecomunicaciones).

Las copias de seguridad se realizan todas las noches, mediante deduplicación y replicado en el sitio de destino (CPD del proveedor de servicios en el CLOUD).

La situación del Backup es monitoreado por el proveedor, el cual administra la solución de RD.

Escritorios de usuarios fueron virtualizados y respaldados mediante una “imagen de oro”, así como todos los datos locales para ciertos usuarios clave (directivos / gerentes / otros equipos críticos) bajo sospecha de no hacer salvaguardas hacia una unidad de red.

Active Directory, autenticación y cortafuegos se configuraron para estar “siempre activos”.

En el CSP, solo se adecua la granja de servidores virtualizados y el aumento requerido de personal en el equipo que administra la recuperación, en momentos de prueba o de desastre real para realizar la recuperación. Al imputarse dichos costes solo cuando se necesitan, permite alinear los costes de recuperación con lo que realmente se está utilizando y solamente durante dicho intervalo (OPEX).

Los escritorios virtuales se pueden clonar y ampliarse a toda la plantilla en el momento de desastre para que puedan trabajar desde su casa o ir a la sala de conferencias contratada en un hotel.  Sólo tienen que acceder mediante un navegador a  un sitio de Internet y los empleados volverán a trabajar con sus aplicaciones y datos corporativos.

Los procedimientos de “Solicitud de restablecimiento” o Cambio de Rol, y los “procedimientos técnicos para la recuperación” fueron escritos por el CSP que administra la recuperación y puestos a disposición de la empresa cliente para su revisión y adaptación, y así poder incluirlos en el DRP.

El Cambio de Rol podrá ser invocado por cualquier razón, no sólo un desastre, como puede ser para una verificación o test del DRP o para proporcionar tiempo de actividad durante una migración o actualización de hardware / sistema operativo o software de aplicación.

El CSP permitirá una VTR (Validation Test of Recovery) o “prueba de validación de la recuperación” realizada por él mismo en otras VM (Máquinas Virtuales), de forma que no moleste a la empresa cliente para dichas pruebas, salvo una vez realizadas para la verificación final.

Compromiso de devolver el entorno primario a la empresa cliente desde el CLOUD, en 72 horas una vez restaurada la situación de desastre en la infraestructura del sitio del cliente, y tras la petición formal de dicha intención.

Entrega por el CSP de un “documento de rendimiento de la prueba”, sin contener ningún tipo de información técnica confidencial, para que pueda ser compartida con los grupos de interés de la empresa, como pueden ser clientes o auditores, aumentando el reconocimiento.

En el momento de producirse un desastre real, el entorno de producción cambiará de rol hacia el entorno secundario, gestionado por el proveedor de servicios en el CLOUD.

La empresa cliente puede permanecer el tiempo que sea necesario operando sobre dicho entorno secundario, siempre pagando las cuotas acordadas.

Las copias de seguridad se seguirán llevando a cabo por el CSP hasta que vuelvan a intercambiarse los roles y el control pase de nuevo al entorno productivo.

5. DR EN EL CLOUD, VERSUS DR TRADICIONAL.

El concepto de DRaaS en el CLOUD,  presenta varias ventajas competitivas respecto al servicio tradicional de recuperación de desastres, incluyendo un menor coste de operaciones y un menor tiempo de recuperación.

Analizándolo en detalle:

5.1. Ventajas de DRaaS frente a DR tradicional.

El coste es el factor clave para la elección de un DRaaS. Un sitio secundario físico DR, significa inversiones en espacio, conectividad, servidores y quizá cabinas de almacenamiento en un CPD adicional. También conduce a costos operacionales adicionales de energía y refrigeración, mantenimiento del sitio, y las necesidades asociadas de personal técnico y de apoyo.

Un servicio de recuperación de desastres basado en el CLOUD, ofrece un entorno secundario basado en máquinas virtuales, a partir de la infraestructura física o virtual en el centro de datos principal de la empresa. Se paga para almacenar las instantáneas y los datos de las aplicaciones en un estado de suspensión, y la replicación de los datos del entorno primario al secundario (Cloud DR) para la sincronización de datos entre sitios (OPEX).

Con DRaaS, la recuperación ante desastres permite poner en línea el sitio secundario en cuestión de segundos o minutos, en lugar del tiempo requerido para un sitio físico DR, que podría tardar unos minutos (si no horas). El arranque de una máquina física toma por lo menos un minuto o más, mientras que una instancia de máquina virtual puede estar en funcionamiento en cuestión de segundos. Típicamente, un sitio físico DR sólo funciona durante la replicación de datos, o en el caso de un desastre real.

Además, la pérdida de disponibilidad está directamente relacionada con el tiempo de inactividad. Un sitio DR en el CLOUD que arranca al cabo de unos pocos segundos, se traduce en una pérdida de disponibilidad de únicamente ese período de tiempo.

En caso de que la conectividad de red no esté disponible con la configuración física de DR, las operaciones manuales pueden ser necesarias para reanudar las operaciones del sitio. Sin embargo, un DRaaS se pueden activar desde cualquier sitio, incluso con un ordenador portátil dotado de una conexión 3G a Internet.

5.2. Inconvenientes de DRaaS frente a DR tradicional.

El CPD del CSP,  puede incluso estar ubicado en un continente diferente. Esto puede causar problemas de latencia para las VM (Máquinas Virtuales) de una empresa en los casos en que se utilicen aplicaciones críticas que requieran tiempos de respuesta altos y baja latencia. Suele ser el caso de controlar procesos productivos en planta, con captura de transacciones desde máquinas o PLCs (Controladores Lógicos Programables), en tiempo real.

Con un DRaaS, la empresa debe asegurarse de que sus aplicaciones son compatibles con la infraestructura de nube pública. Por ejemplo, algunas aplicaciones pueden exigir un entorno específico que puede no estar disponible en el CSP. Deben estudiarse en detalle todos los casos.

Por tanto, la elección de ir a un DRaaS se regirá exclusivamente por el imperativo del negocio. Si una empresa tiene aplicaciones importantes que deben estar disponibles en cuestión de minutos de tiempo de inactividad, se puede considerar DRaaS. Sin embargo, si una organización presenta problemas de latencia o aplicaciones poco estándares, se debe optar por la DR física tradicional.

5.3. Restricciones a tener en cuenta.

Debido a los diferentes protocolos utilizados por los proveedores de DRaaS para escribir datos en su almacenamiento en el CLOUD, la velocidad o tasa de transferencia a la que los datos se copian o replican en la nube puede diferir de un proveedor a otro. Por ejemplo, según estudios realizados, la velocidad a la que los datos se copian con un servicio de copia de seguridad de Google Cloud, difiere de la de una copia de seguridad en la nube de Amazon, incluso con el mismo ancho de banda disponible.

Además, aunque no hay ninguna limitación sobre el tipo de datos que pueden ser guardados en la nube, puede haber una restricción impuesta por el CSP en el tamaño del archivo. Por ejemplo, cierto proveedor de almacenamiento en el Cloud limita el envío de un único archivo, a un tamaño máximo de 5 GB; Sin embargo no limita la cantidad de datos que pueden ser enviados por período de tiempo.

6. LEGISLACIÓN Y PROTECCIÓN DE DATOS.

Si una organización tiene restricciones en cuanto a la ubicación geográfica donde residen los datos (Regulaciones tipo ENS y/o legislación en materia de protección de datos tipo LOPD), como pueden ser las AA.PP. (Administraciones Públicas), debe estudiarse el caso con detenimiento. Una solución pasa por elegir un proveedor nacional, o bien contratar el DRaaS en un CSP que nos de a escoger entre sus diferentes CPDs, optando por uno que esté ubicado en España, en el EEE (Espacio Económico Europeo) o en su defecto, en un país considerado por la AEPD (Agencia Española de Protección de Datos) con nivel adecuado de protección.

No hay que olvidar que el hecho de llevar datos cifrados al CLOUD, no exime de los requisitos jurídicos.

NOTA DEL EDITOR: Para ampliar conceptos en relación a la problemática legislativa de llevar datos personales al CLOUD, puede consultarse en éste mismo Blog, los siguientes artículos:

CLOUD COMPUTING Y PROTECCIÓN DE DATOS: REGULANDO EL DESORDEN

CONFLICTO ENTRE LA LOPD Y LA LEY DEL TERRITORIO DONDE SE UBICA EL CLOUD

NOTA DEL EDITOR: Para ampliar conceptos en relación a los Backups en general, puede consultarse en éste mismo Blog, el siguiente artículo:

BACKUPS: ¿QUÉ DEBEMOS TENER EN CUENTA?

7. CERTIFICACIONES.

Existen diferentes certificaciones que pueden acreditar el “buen hacer” de un proveedor de DRaaS:

ISO 22301:2012 à Certifica al CSP conforme dispone de un Sistema de Gestión de la Continuidad del Negocio.

ISO 27001:2008 à Certifica al CSP conforme dispone de un Sistema de Gestión de la Seguridad de la Información.

El comité ISO/IEC JTC1, está elaborando dos borradores sobre CLOUD SECURITY, concretamente:

  •  ISO 27017 à “Security in Cloud Computing”.
  •  ISO 27018 à “Code of pactice for data protection controls for public Cloud Computing services”.

ISAE 3402 à Marco esencial para la auditoría de servicios en la era posterior a la Ley Sarbanes-Oxley.  El SAS 70 (Statement on Auditing Standard 70) y sus antecesores, han sido la Norma de los Estados Unidos para presentar información acerca de los controles de las organizaciones de servicios, que con el ISAE 3402 evoluciona hacia una norma global.

8. BIBLIOGRAFIA CONSULTADA

TechTarget. (SearchDisasterRevovery). “Disaster recovery and business continuity tutorials”.

DR tutorials

Jacob Gsoedl. “Disaster recovery in the cloud explained”. August 2011. SearchDisasterRecovery.

DR in the Cloud