Cómo probar un plan de recuperación de desastres y evitar los errores críticos
Las consecuencias de la pérdida de información crítica ocasionadas por un desastre de IT, pueden llegar a ser devastadoras para la supervivencia de tu organización.
Por ello, siempre insistimos en la importancia que tiene contar con plan eficaz de actuación. De hecho, anteriormente he hecho hincapié en la necesidad de calcular el impacto económico de este tipo de eventos. Puedes comprobarlo aquí:
- Advertencia: Por qué necesitas calcular el impacto económico de un desastre de IT
- ¿Cómo calcular el coste económico de un Desastre de IT y el presupuesto para un DRP?
Los planes de recuperación de desastres (DRP) son la última línea de defensa de la infraestructura IT de tu empresa. Desastres naturales, accidentes, problemas técnicos y, por supuesto, ataques informáticos amenazan la conservación de los datos críticos del negocio.
Desgraciadamente, aún hoy en día, las organizaciones no se toman suficientemente en serio estos riesgos y, aunque pueda parecer alarmista, la infraestructura IT de una organización está permanentemente amenazada, tanto desde el punto de vista interno, como externo.
La labor del CIO, CSO o responsable de IT debe ser por tanto conocer el impacto económico de un desastre de IT, así como el ROI que proporciona el plan de recuperación correspondiente, es uno de los motivos por los cuales los directivos fallan en la protección de la información de su negocio. Este plan debe incluir de forma clara el procedimiento a seguir, detallado por fases.
Si el plan de recuperación de desastres tiene fisuras, el riesgo para la continuidad de tu negocio se incrementa exponencialmente, así que te recomiendo evitar estos errores que son los más frecuentes, a toda costa.
Deficiente divulgación y conocimiento del DRP
Es muy importante tener en cuenta que el conocimiento y la capacidad para llevar a cabo el DRP no se debe limitar solo al departamento de IT, sino que debe ser accesible por tantas personas de la organización como sea necesario para que resulte eficaz y ágil.
Por ello, someter a una simulación lo más real posible a la infraestructura puede ser una de las mejores opciones, aunque suponga un periodo de inactividad con las consecuencias derivadas y que lo óptimo es realizarlo de forma escalada, desde un problema con alcance totalmente delimitado al fallo total.
Esta simulación será evaluada y monitorizada, lo que permitirá delimitar el tiempo necesario para la realización, posibles fallos y una estimación de los costes y consecuencias.
Acceso limitado
Tanto operacionalmente hablando como desde el punto de vista del personal necesario, debemos asegurarnos de que podemos acceder a los detalles del DRP desde diferentes dispositivos y localizaciones y, del mismo modo, que el personal encargado de realizarlo es sustituible mutuamente.
Tener más opciones en todos los sentidos supone la diferencia para el éxito llegado el momento.
Ausencia de test periódicos
A menudo, se cree que el coste del desarrollo de un DRP tiene que ver con el diseño, implantación e infraestructura. Sin embargo, uno de los mayores factores económicos es la necesidad de llevar a cabo test periódicos, una simulación previa periódica puede ser la clave del éxito para detectar y corregir fallos.
La profundidad y complejidad de estos tests también debe ser tenida en cuenta. De nada servirá la ejecución de pruebas, si:
- Dichas pruebas no contemplan la necesaria variedad de escenarios diferentes.
- Se ignoran los errores detectados.
- No se procede a modificar el plan, conforme las circunstancias y evolución del negocio lo requieren.
Deficiente verificación del correcto funcionamiento de los backups y de su frecuencia
La periodicidad y eficacia de los backups debe diseñarse de forma personalizada a cada organización dependiendo de la naturaleza de los datos y se debe garantizar que se realiza de forma satisfactoria.
Mientras que la frecuencia de los backups vendrá determinada por los RPO (Recovery Point Objective) y RTO (Recovery Time Objective) apropiados.
Ausencia de respaldo de las aplicaciones
Con frecuencia, los DRP se centran en respaldar los datos de la organización, pero no tienen en cuenta la protección del software, aplicaciones y licencias correspondientes.
El plan de recuperación debe prever los procedimientos oportunos para la restauración de todo el software, de forma que el desarrollo normal de la actividad del negocio pueda continuar cuanto antes. Por ello, te invito a definir las MECs (Minimum Equipment Configurations), con las que reducirás los costes del DRP, simplificar las pruebas periódicas y garantizar la continuidad en caso de desastre.
Deficiente priorización de la información a respaldar
No toda la información de la organización es determinante para la continuidad de la actividad, así mismo debemos considerar que puede haber datos que debido a la descentralización queden fuera de la red de almacenamiento central, y al margen de los sistemas de respaldo del DRP. En este sentido, la planificación y los test, explicados anteriormente, pueden ayudarnos a planificar mejor y corregir estos errores, reservando la tecnología del backup avanzado para la información crítica.
Lectura recomendada:
¿Por qué es importante poner a prueba tu sistema de DRP?
Realizar las pruebas pertinentes de forma periódica y sistemática tiene evidentes ventajas. Éstas son solo algunas de ellas:
- Podrás asegurarte de que el sistema y el plan de recuperación están adaptados a la infraestructura del negocio.
- Los miembros del departamento de IT ganarán la experiencia necesaria para trabajar como un equipo y de forma eficiente en el momento crítico.
- Sabrás qué RTO podéis alcanzar, lo que te permitirá saber si el sistema es realmente útil.
Toda prueba del sistema de recuperación de desastres debería tener en cuenta los siguientes aspectos:
- Cuánto tiempo ha pasado desde la realización del último test, ya que los datos almacenados son susceptibles de cambiar.
- Cuántas actualizaciones han tenido lugar sobre el hardware empleado.
- Cuál es el impacto de la propia recuperación de los datos en el negocio, dado que se está delimitando cuánta información se va a recuperar y el plazo en el que volverá a estar disponible.
- Cuánto personal cualificado necesitas para el proceso de recuperación, siendo conveniente dejar todo el proceso de backup y DRP en manos de un grupo que sea capaz de sustituirse mutuamente.
Dicho esto, te propongo una serie de pasos clave a ejecutar.
Análisis previo de las probabilidades de sufrir un desastre de IT
Ten en cuenta que una simulación implica someter a tu organización a un periodo de inactividad. Esto supone un coste que, sumado al establecimiento y mantenimiento del sistema de backup y DRP, debería compararse con las consecuencias de un desastre real.
Lectura recomendada:
Prepara un escenario de desastre de IT
El realismo de la simulación determinará la eficacia de la misma. Para ello, deberían combinarse elementos infraestructurales y de negocio.
En este sentido, conviene ir escalando el alcance de las pruebas desde escenarios cuyo alcance esté perfectamente delimitado, hasta un test completo debido a un fallo total del sistema.
Pon a prueba todos los factores
La única manera de poner realmente a prueba un sistema de backup y recuperación de desastres es apagar todos los sistemas y someter a estrés cada uno de los factores implicados, incluyendo los usuarios finales.
- Considera todos los factores que pueden afectar a los dispositivos y hardware, dependiendo del tipo de empleado o usuario.
- Simula diversos incidentes reales y las molestias que estos pueden causar. No acotes la experiencia al departamento de IT.
- Evita que los usuarios intenten sortear las simulaciones, pues esto no será posible en caso de un desastre real.
Monitorización y documentación del test
Una vez ejecutado el test, deberías contar con un registro completo de todos los problemas surgidos y cambios que necesiten realizarse. Para ello, deberás designar a un responsable que observe el desarrollo de la prueba, documentando:
- El procedimiento.
- Los tiempos de ejecución.
- Los aspectos de mayor solidez, así como las fallas del sistema.
- El impacto sobre el negocio, debido a la inactividad del personal y la imposibilidad de acceso a los sistemas.
- Las fallas de conocimiento o preparación por parte del personal de IT.
Si aún no dispones de un sistema de backup y recuperación de desastres, te sugiero leer el siguiente artículo y ponerte en contacto conmigo:
