Recuperación de Desastres: 6 Errores comunes

Última actualización: 22/07/2020

En esta entrada explicamos qué es un plan de recuperación de desastres. Comentamos las buenas prácticas y algunos de los problemas más frecuentes en su implementación a través de los 6 errores más comunes.

Recuperación de desastres (Disaster recovery) Big Data

Un plan de recuperación de desastres (Disaster Recovery, DR o DRP) es un proceso crítico para los negocios que define las actuaciones para recuperar los datos y los sistemas de la organización en una situación de desastre. Esta situación puede deberse a causas naturales o bien puede estar causada por personas. La finalidad es volver a ejecutar sus operaciones con normalidad.

Tener un plan de recuperación de desastres informáticos es fundamental en los sistemas de almacenamiento Big Data. Al tratar cantidades de datos tan grandes, que a menudo son críticas para la organización, debe existir un plan bien definido. Este plan debe minimizar el impacto que pueden tener los posibles desastres en los datos. Para ello nos debemos aprovechar de las ventajas de las tecnologías cloud.

Además, estos planes deben ser probados y puestos en funcionamiento periódicamente para comprobar su efectividad. Es un área en la que existe poco margen de error, ya que trata situaciones críticas y poco frecuentes. En el mejor de los casos, podría existir pérdida de servicio temporal o pérdida de beneficios. Sin embargo, también puede ser la causa de pérdida permanente de datos, incumplimiento de contratos o de daños a la organización.

Errores comunes en el plan de recuperación de desastres

No actualizar el plan con nuevas tecnologías y sistemas

Con las nuevas tecnologías y soluciones en la nube (Cloud Computing) han aumentado las posibilidades de reforzar los sistemas de recuperación de fallos de las organizaciones. En la actualidad, se pueden automatizar las replicaciones de datos a otras regiones y las copias de seguridad para que la pérdida de servicio sea mínima, y en ocasiones inexistente. Es deber de las organizaciones explorar estas nuevas soluciones e implementar las más adecuadas para su negocio y sus necesidades.

En la definición inicial del plan de recuperación de desastres y continuidad del negocio, se deben incluir todos los sistemas críticos de la organización. Sin embargo, a menudo los sistemas evolucionan, deprecando aplicaciones y sistemas antiguos y agregando nuevas funcionalidades críticas que no quedan reflejadas en el plan de recuperación.

Para evitar estas situaciones, los equipos deben participar en la definición del plan. Con ayuda de las pruebas periódicas y de auditorías, incorporar los nuevos sistemas y servicios. Con este fin, también podría ser muy útil incorporar el plan de DR a los procesos de control de cambios de la organización.

No definir correctamente las métricas de RTO y RPO

El RPO o Punto Objetivo de Recuperación (Recovery Point Objective) es la métrica que indica el máximo periodo de tiempo que la organización está dispuesta a perder datos (desde la última copia o réplica del sistema). Definir un RPO demasiado alto, puede significar unos costes y un impacto mucho más alto para la organización.

El RTO o Tiempo Objetivo de Recuperación (Recovery Time Objective) es el tiempo que pasa para que un sistema vuelva a estar disponible tras el desastre.

Además, un buen plan de recuperación de fallos debe definir la cantidad de tiempo máximo que la organización puede tolerar una pérdida de servicio o no tener un funcionamiento normal. Esta definición no afecta solo a los sistemas, sino también a todos los aspectos de la organización para recuperar el servicio: entre otros, los trabajadores y los activos materiales.

No examinar los SLA de los proveedores de servicios

Los SLA (Service Level Agreements o Acuerdos de nivel de servicio) que garantiza el proveedor de servicios son fundamentales para la realización de un plan efectivo. En el caso de incumplir estos acuerdos, el proveedor podría hacerse cargo de los daños económicos, pero esta situación, generalmente, es insuficiente.

Se deben investigar y examinar estos acuerdos de servicio para verificar cómo y dónde se almacenan los datos, cómo se protegen y cuál es la actuación del proveedor ante un fallo y ante un desastre. Desafortunadamente, también es frecuente que algunos proveedores ofrezcan garantías que no pueden cumplir en sus momentos críticos, como el soporte de emergencias 24h que no podrían cumplir por falta de personal.

No probar ni monitorizar el plan de recuperación de desastres

Además de estudiar la teoría, para realizar un plan de recuperación de desastres eficaz se deben poner a prueba todos sus componentes. Tanto de forma individual como en conjunto. También se debe probar que el plan de recuperación de desastres de los proveedores se cumple mediante tests periódicos.

Siempre pueden existir problemas en cualquier pieza del sistema, como fallos de software, de hardware, de dependencias externas, etc. Aun así, estos errores se deben minimizar con las sucesivas pruebas. Quizá las pruebas más interesantes son las que afectan directamente a las personas. Se ha comprobado que las personas son la fuente de errores más común en las organizaciones. Un personal bien entrenado y que conoce los protocolos de recuperación de desastres puede marcar la diferencia en el éxito de las operaciones.

La frecuencia con la que se someten los sistemas a pruebas de recuperación de desastres y continuidad del negocio depende de la organización y de sus protocolos. No se recomienda realizar menos de una prueba al año, que debe evaluar y examinar cuidadosamente los resultados. La prueba resulta en la planificación de las acciones de mejora y los ajustes necesarios para fortalecer todo el plan.

Evaluar los riesgos incorrectos y no incluir nuevas amenazas

Aunque existan riesgos catastróficos para las organizaciones como los desastres naturales o los ataques organizados, el plan de recuperación de desastres informáticos debe evaluar los riesgos en función de su posible impacto y probabilidad de ocurrencia.

Por ejemplo, los desastres causados por catástrofes, fuego o ataques terroristas son muy poco frecuentes. Sin embargo, pueden llegar a ocasionar unas pérdidas enormes si no se tienen reflejadas actuaciones para su recuperación en el plan, como la incorporación de extintores o alarmas.

Los desastres más comunes en relación a los datos de una organización son debidos a ciberataques y a la falta de suministro eléctrico. Ambos pueden ocasionar pérdidas de servicio generalizadas. En los últimos años, se han incrementado los ciberataques a organizaciones con el fin de ocasionar pérdidas de servicio o robos de datos. Para mitigarlo, las organizaciones invierten grandes cantidades de dinero en software especializado como antivirus y seguridad. En el caso de la falta de suministro eléctrico, se puede evaluar la adopción de sistemas de alimentación ininterrumpida (SAI). Otra medida, podría ser incluir proveedores de suministro redundantes o duplicados.

Además, emergen continuamente nuevas amenazas, que se deben identificar y evaluar periódicamente.

No incluir en el plan de recuperación de desastres los protocolos de comunicación

Los protocolos y las pruebas definidas en el plan de recuperación ante desastres de las organizaciones suelen pasar por alto la definición de la comunicación con los equipos.

Es muy importante detectar y comunicar el problema a los equipos de trabajo involucrados así como volver a poner en funcionamiento los sistemas y notificar a los equipos correspondientes de que están operativos de nuevo.

También debe incluir la asistencia y el soporte que los usuarios de los sistemas (internos y externos a la organización) pueden necesitar para recuperar su actividad. Para ello, el conocimiento de las actuaciones debe estar presente en toda la organización.


A continuación, comparto con vosotros una infografía sencilla para tener en cuenta estos errores comunes al definir vuestro plan de recuperación ante desastres. ¡Compártelo!

Errores comunes en el plan de recuperación de desastres

A continuación el vídeo-resumen. ¡No te lo pierdas!


¡Echa un ojo a mi lista de reproducción de Big Data en Youtube!

Si te ayuda el contenido del blog, por favor considera unirte a la lista de correo para reconocer el trabajo!

Deja una respuesta