La recuperación tras desastre (DR) consta de tecnologías de TI y prácticas recomendadas diseñadas para impedir o minimizar la pérdida de datos y las interrupciones en la actividad de negocio provocadas por hechos catastróficos de diversa índole, desde fallos de equipos y cortes de energía localizados hasta ciberataques, emergencias civiles, ataques criminales o militares y desastres naturales.

Muchas empresas, especialmente las pequeñas y medianas organizaciones, descuidan su atención y olvidan elaborar un plan de recuperación tras desastre que sea fiable y factible. Sin uno de estos planes, están poco protegidas ante la repercusión de sucesos significativamente disruptivos.

El coste de un error de infraestructura pueden alcanzar los 100 000 USD por hora (enlace externo a IBM), y los costes de un error de una aplicación crucial pueden oscilar entre 500 000 USD y 1 millón de USD por hora. Muchas empresas no pueden recuperarse de semejantes pérdidas. Más del 40 % de las pequeñas empresas no vuelven a abrir tras sufrir un desastre, y entre las que sí lo hacen, un 25 % adicional vuelve a experimentar fallos dentro del primer año siguiente a la crisis. La planificación de la recuperación tras desastre puede reducir drásticamente estos riesgos.

La planificación de la recuperación tras desastre implica elaborar estrategias, planificar, desplegar la tecnología adecuada y realizar pruebas continuas. Mantener una copia de seguridad de los datos es un componente fundamental del plan de recuperación tras desastre, pero para elaborar un plan completo de recuperación tras desastre no basta únicamente con un proceso de copia de seguridad y recuperación.

La recuperación tras desastre también implica garantizar que se disponga de un almacenamiento y un cálculo adecuados disponibles para mantener unos procedimientos sólidos de migración tras error y restablecimiento. La migración tras error es el proceso de descargar cargas de trabajo a los sistemas de copia de seguridad de un modo en que los procesos de producción y las experiencias del usuario final se vean interrumpidos lo menos posible. El restablecimiento implica volver a los sistemas primarios originales.

Lea este artículo para obtener más información sobre la importante distinción entre copia de seguridad y planificación de recuperación tras desastre.

La planificación de la continuidad de negocio crea sistemas y procesos para garantizar que todas las áreas de su empresa puedan mantener las operaciones esenciales o puedan reanudarlas lo más rápido posible en caso de crisis o emergencia. La planificación de recuperación tras desastre es el subproceso de planificación de continuidad de negocio que se centra en recuperar los sistemas y la infraestructura de IT.

Análisis del impacto en el negocio

La creación de un plan exhaustivo de recuperación tras desastre empieza por el análisis del impacto en el negocio. Al realizar este análisis, se crean una serie de casos detallados de ejemplo de desastre que luego se pueden usar para prever el tamaño y el alcance de las pérdidas en las que se incurriría si se interrumpieran ciertos procesos de la empresa. ¿Qué pasaría si su centro de atención telefónica quedase devastado por un incendio, por ejemplo? ¿O si un terremoto destrozase su oficina central?

Este punto permite identificar las áreas y funciones más importantes de la empresa y determinar cuánto tiempo de inactividad se podría tolerar en cada una de estas funciones esenciales. Al disponer de esta información, se puede comenzar a crear un plan sobre cómo mantener las operaciones más importantes en distintas situaciones.

Los planes de planificación de recuperación tras desastre de TI se deben realizar tras la planificación de la continuidad de negocio y servir para facilitarla. Si, por ejemplo, en su plan de continuidad de negocio se indica a los representantes de servicio al cliente que, en caso de incendio, trabajen desde casa hasta que el centro de atención telefónica vuelva a la normalidad, ¿qué tipos de recursos de TI, hardware y software harían falta para respaldar ese plan?

Análisis de riesgos

Evaluar la probabilidad y las posibles consecuencias de los riesgos que afronta su empresa también es un componente esencial de la planificación de la recuperación tras desastre. A medida que aumenta la frecuencia de los ciberataques y del ransomware, es fundamental comprender los riesgos generales de ciberseguridad a los se enfrentan todas las empresas hoy en día, así como los riesgos específicos de su sector y de su ubicación geográfica.

Para muchas situaciones, como desastres naturales, fallos de equipos, amenazas internas, sabotajes y errores de los empleados, le vendrá bien evaluar los riesgos y tener en cuenta la repercusión general en su empresa. Formúlese las siguientes preguntas:

• ¿En qué pérdidas financieras incurriría a causa de oportunidades de ventas perdidas o interrupciones en las actividades que generan ingresos?
  
  
• ¿Qué tipo de daños sufriría la reputación de su marca? ¿Cómo se vería afectada la satisfacción del cliente?
  
  
• ¿Cómo se vería afectada la productividad de los empleados? ¿Cuántas horas de trabajo se podrían perder?
  
  
• ¿Qué riesgos podría representar la incidencia para la salud o la seguridad de las personas?
  
  
• ¿Se vería afectado el desarrollo de alguna iniciativa u objetivo de negocio? ¿De qué modo?

Priorización de las aplicaciones

No todas las cargas de trabajo tienen la misma importancia para la capacidad de la empresa de mantener las operaciones, y el tiempo de inactividad es mucho más tolerable en algunas aplicaciones que en otras. Divida sus sistemas y aplicaciones en tres niveles, según el tiempo de inactividad que pueda tolerar en ellos y la gravedad de las consecuencias de una eventual pérdida de datos.

1. Imprescindibles: aplicaciones cuyo funcionamiento es fundamental para la supervivencia del negocio.
   
   
2. Importantes: aplicaciones para las que se pueden tolerar periodos de tiempo de inactividad relativamente breves.
   
   
3. No esenciales: aplicaciones que se podrían sustituir temporalmente por procesos manuales, o de las que se podría prescindir, incluso.

Documentación de dependencias

El siguiente paso en una planificación de recuperación tras desastre es crear un inventario completo de los activos de hardware y software. En esta fase, es fundamental conocer las interdependencias de las aplicaciones cruciales. Si una aplicación de software queda inactiva, ¿qué otras se verían afectadas?

Diseñar resiliencia —y modelos de recuperación tras desastre— en los sistemas en el momento de crearlos es la mejor manera de gestionar las interdependencias de las aplicaciones. En las arquitecturas actuales basadas en microservicios, es muy habitual descubrir procesos que no se pueden iniciar cuando otros sistemas o procesos están inactivos, y viceversa. Es difícil recuperarse de una situación así, y es vital descubrir este tipo de problemas cuando aún hay tiempo de elaborar planes alternativos para los sistemas y procesos, antes de que ocurra un desastre de verdad.

Establecimiento de objetivos de tiempo de recuperación, objetivos de punto de recuperación y objetivos de coherencia de recuperación

Tener en cuenta los análisis de riesgo e impacto en el negocio permite establecer objetivos sobre cuánto se tardaría en recuperar la actividad de los sistemas, cuántos datos se podrían utilizar y cuánta desviación o corrupción de datos se podría tolerar.

El objetivo de tiempo de recuperación (RTO) es la cantidad máxima de tiempo que se debe tardar en restaurar el funcionamiento de la aplicación o del sistema tras una disrupción de servicio.

El objetivo de punto de recuperación (RPO) es la antigüedad máxima de los datos que se deben recuperar para reanudar las operaciones normales en la empresa. Para algunas empresas, perder siquiera unos pocos minutos de datos puede ser catastrófico, mientras que en otros sectores se pueden tolerar ventanas más largas.

En el acuerdo de nivel de servicio (SLA) de los servicios de protección de datos continua, se establece un objetivo de coherencia de recuperación (RCO). Es una métrica que indica cuántas entradas incoherentes se pueden tolerar en los datos empresariales de procesos o sistemas recuperados en situaciones de recuperación tras desastre, y describe la integridad de los datos empresariales en entornos de aplicaciones complejos.

Cuestiones de conformidad con la normativa

Todo el software y las soluciones de recuperación tras desastre que una empresa haya establecido deben cumplir con los requisitos de seguridad y protección de datos a los que debe adherirse. Esto significa que todos los sistemas de copia de seguridad de datos y migración tras error deben estar diseñados para cumplir con los mismos estándares que los sistemas primarios para garantizar la integridad y la confidencialidad de los datos.

Al mismo tiempo, varias normas regulatorias estipulan que todas las empresas deben mantener planes de recuperación tras desastre y/o continuidad de negocio. La ley Sarbanes-Oxley (SOX), por ejemplo, exige que todas las empresas públicas de EE. UU. conserven copias de todos los registros de negocio durante un mínimo de cinco años. No cumplir esta normativa (incluida la omisión de establecer y probar sistemas adecuados de copia de seguridad de datos) puede generar importantes sanciones económicas para las empresas, e incluso responsabilidad penal para sus directivos.

Elección de tecnologías

Las copias de seguridad actúan como base sobre la que crear cualquier plan sólido de recuperación tras desastre. Antes, la mayoría de las empresas utilizaban cintas y discos giratorios (HDD) para las copias de seguridad; mantenían varias copias de los datos y almacenaban al menos una en una ubicación externa.

Hoy en día, con la constante transformación digital, las copias de seguridad en cinta en repositorios externos no suelen poder cumplir los RTO necesarios para mantener activas las operaciones imprescindibles. Diseñar una solución propia de recuperación tras desastre implica replicar muchas de las prestaciones del entorno de producción y requiere incurrir en costes de personal de soporte, administración, instalaciones e infraestructura. Por esta razón, muchas organizaciones están recurriendo a soluciones de copia de seguridad basadas en cloud, o proveedores de recuperación tras desastre como servicio (DRaaS) a gran escala.

Elección de las ubicaciones de sitio de recuperación

Crear un centro de datos propio de recuperación tras desastre implica mantener el equilibrio entre distintos objetivos contrapuestos. Por un lado, se debe almacenar una copia de los datos en algún lugar que esté lo suficientemente distante geográficamente de la oficina central o de las oficinas como para que no se vea afectado por los mismos sucesos sísmicos, amenazas ambientales u otros peligros que la sede principal. Por otro lado, las copias de seguridad almacenadas de forma externa siempre tardan más en restaurarse que las ubicadas en local en el sitio primario, y la latencia de red puede ser aún mayor en distancias más largas.

Prueba y revisión continuas

Está claro que si un plan de recuperación tras desastre no se ha probado, no se puede confiar en él. Todos los empleados con responsabilidades relevantes deben participar en el ejercicio de la prueba de recuperación tras desastre, que puede incluir el mantenimiento de las operaciones del sitio de migración tras error durante un determinado periodo de tiempo.

Si realizar pruebas integrales de recuperación tras desastre no encaja en su presupuesto o en sus capacidades, también puede planificar un ejercicio simulado de los procedimientos de prueba, aunque debe tener en cuenta que es menos probable que este tipo de prueba revele anomalías o puntos débiles en sus procedimientos de DR —en especial, la presencia de interdependencias de aplicación no descubiertas previamente— que una prueba completa.

A medida que los activos de hardware y software vayan cambiando, deberá asegurarse de ir actualizando también el plan de recuperación tras desastre, y de revisar periódicamente el plan de forma continua.

En IBM Knowledge Center se proporciona un ejemplo de plan de recuperación tras desastre.

La recuperación tras desastre como servicio (DRaaS) es una de las ofertas gestionadas de servicio de TI más populares y que más rápido crecen hoy en día. El proveedor documenta los RTO y RPO en un acuerdo de nivel de servicio (SLA) que describe los límites de tiempo de inactividad y las expectativas de recuperación de las aplicaciones.

Los proveedores de DRaaS suelen proporcionar entornos de migración tras error basados en cloud. Este modelo ofrece importantes ahorros de costes en comparación con el mantenimiento de recursos de hardware dedicados y redundantes en un centro de datos propio. Existen contratos en los que se paga una tarifa por el mantenimiento de prestaciones de migración tras error más los costes por uso de los recursos consumidos en una situación de recuperación tras desastre. Lo más habitual es que el proveedor asuma toda la responsabilidad de configurar y mantener el entorno de migración tras error.

Las ofertas de servicio de recuperación tras desastre varían de un proveedor a otro. Algunos proveedores definen su oferta como una solución integral todo en uno, mientras que otros ofrecen servicios fragmentados que van desde la restauración de aplicaciones individuales hasta la réplica completa del centro de datos en el cloud. Algunas ofertas pueden incluir servicios de prueba o planificación de recuperación tras desastre, mientras que en otras se cobra una tarifa de consultoría adicional por estas ofertas.

Asegúrese de que todas las aplicaciones de software empresarial de las que depende sean compatibles, al igual que cualquier proveedor de cloud público con el que trabaje. También es importante asegurarse de que el rendimiento de la aplicación sea correcto en el entorno de migración tras error, y de que se hayan realizado pruebas suficientes de los procedimientos de migración tras error y restablecimiento.

Si ya se ha creado una solución local de recuperación tras desastre (DR), puede ser complicado evaluar los costes y las ventajas de mantenerla en lugar de cambiar a una suscripción DRaaS mensual.

La mayoría de las soluciones de DR locales incurrirán en costes de hardware, energía, trabajos de mantenimiento y administración, software y conectividad de red. Además de los gastos de capital iniciales asociados a la configuración inicial del entorno de DR, se deberán presupuestar las actualizaciones periódicas del software. Dado que la solución de DR debe seguir siendo compatible con el entorno de producción primario, es conveniente asegurarse de que la solución de DR seleccionada tenga las mismas versiones de software. En función de los detalles del acuerdo de licencia, esto puede suponer que, en la práctica, se dupliquen los costes de software.

Migrar a una suscripción de DRaaS no solo puede reducir los gastos de hardware y software, sino también los costes de mano de obra, ya que traslada la carga de mantenimiento del sitio de migración tras error al proveedor.

Si está contemplando utilizar soluciones de terceros, es buena idea asegurarse de que el proveedor tenga la capacidad de realizar copias de seguridad de varios sitios y entre distintas regiones. Si un grave suceso meteorológico, como por ejemplo un huracán, afectase a la ubicación de su oficina principal, ¿estaría el sitio de migración tras error lo suficientemente lejos como para no verse afectado por la tormenta? Además, ¿tendría el proveedor la capacidad adecuada para satisfacer las necesidades combinadas de todos los clientes de su zona si el problema afectase a muchos de ellos a la vez? Va a confiar en que su proveedor cumpla los RTO y los RPO en tiempos de crisis, así que debe buscar un proveedor de servicio con una sólida reputación de fiabilidad.

Para obtener una comparación general entre las dos soluciones, lea el artículo "Disaster Recovery as a Service (DRaaS) vs. Disaster Recovery (DR): Which Do You Need?".