Estrategias para comprobar el correcto funcionamiento del sistema de recuperación de desastres

En un momento en el que las empresas dependen, más que nunca, de la automatización para que un número más reducido de trabajadores sea más productivo, la planificación de recuperación ante desastres (DRP) es más importante que nunca. Incluso el más leve problema puede tener graves consecuencias en la continuidad de una empresa.

Una vez dicho esto, lo cierto es que muchas organizaciones han reducido sus esfuerzos en materia de planificación debido a las presiones económicas. Un ámbito relevante en el que se están llevando a cabo recortes es la asignación de fondos para realizar  pruebas de planificación.

En el ámbito de la planificación de recuperación ante desastres, el aspecto que más costos va a conllevar es la realización de pruebas. Una vez que se han identificado los datos corporativos más importantes y que se han fijado los objetivos para su correspondiente recuperación en caso de que se produzca un suceso que interrumpa la actividad de la empresa, los encargados de la planificación suelen esforzarse en buscar la técnica de recuperación más correcta para proteger y restablecer dichos datos teniendo en cuenta sus limitaciones tecnológicas y presupuestarias. 

El plan se documenta y concreta tomando como base las técnicas que más se ajustan a las necesidades de la empresa. Y, aquí, es donde entra en juego el verdadero trabajo del proceso de recuperación ante desastres informáticos: las pruebas de rutina.

Tradicionalmente, las pruebas siguen una misma pauta. Una vez al año, se prepara y presenta un plan de pruebas a la dirección de la empresa de forma que se puedan asignar, con anterioridad, los recursos para la siguiente serie de actividades de prueba. Después, se realizan planes diferenciados para cada uno de los eventos de prueba programados para los siguientes 12 meses. 

Cada evento de prueba se lleva a cabo de acuerdo al programa, realizando las labores y procedimientos de recuperación de una forma no lineal para optimizar el tiempo de duración de la prueba. (Para no desperdiciar el valiosísimo tiempo de las pruebas, las tareas interdependientes se verifican de forma separada, repartiéndolas entre distintos eventos, para evitar que un fallo en uno de los procedimientos afecte a todo el evento.) Finalmente, se examinan los resultados para determinar qué cambios es necesario introducir en el diseño general del plan y qué tareas deben someterse a más pruebas.

Esta estrategia ha caracterizado las pruebas de DR en los últimos 30 años. Fue útil en unidades principales, pero demostró ser algo menos eficiente en el ámbito de los sistemas distribuidos.  Esto se debe, en parte, a la sencillez logística, la estandarización y la disciplina de TI (tecnología de la información) de las operaciones de la unidad principal y la plataforma tecnológica, de los que carece el cajón de sastre de los sistemas abiertos. En los sistemas abiertos, nos enfrentamos a una mayor complejidad: las configuraciones de plataforma varían, las incompatibilidades de hardware provocan problemas de diseño en la plataforma de recuperación, el software de las aplicaciones no está diseñado para los procesos de recuperación, etc.

Y la proliferación de “soluciones” de recuperación no hace más que empeorar el problema. Todo el mundo quiere cumplir la ley de protección de datos. Los fabricantes de hardware de almacenamiento quieren vender sistemas de replicación en espejo multisalto o de protección de datos continua que sólo funcionan con productos que llevan su logo corporativo. Los productos de software fabricados por terceros para realizar copias de seguridad o con alta disponibilidad han entrado en el mercado de forma masiva. Los fabricantes de soluciones de virtualización quieren fomentar el uso de sus procedimientos contra fallos de clúster. Los fabricantes de sistemas en nube quieren vender productos de protección de datos en red. Y los fabricantes de sistemas operativos y aplicaciones presumen, ahora, de sus propios sistemas de protección de datos propietarios. Hoy en día, pocas empresas se limitan a una de estas técnicas. Normalmente, los encargados de la planificación recurren a una combinación de distintos procesos de protección de datos.

Aunar todos estos procesos en una sola solución que sea fácil de gestionar es una tarea difícil. Pero descubrir una forma coherente de verificar su correcto funcionamiento puede ser una pesadilla.

Esto nos lleva a un importante déficit en el proceso de planificación actual: la incapacidad de desarrollar estrategias de DR teniendo en cuenta el proceso de pruebas. Los responsables de la planificación tienden a centrarse en cómo proteger y recuperar los datos, a qué costo y en cuánto tiempo. Pocas veces, de hacerlo alguna vez, nos preguntamos cómo comprobar que la estrategia que hemos adoptado funciona.

El artículo “La realización de pruebas de verificación es siempre lo último en lo que se piensa” añade costos significativos al mantenimiento de un plan. En él, se explica que cada evento de prueba que se programe debe incluir tres tipos de tareas: gestión de datos, sustitución de infraestructuras y reabastecimiento logístico. 

En otras palabras, la prueba debe confirmar: 1) que se están protegiendo los datos correctos y que éstos están disponibles, en la forma que sea, para ser recuperados; 2) que se cuenta con la infraestructura correcta (o que ésta puede establecerse rápidamente) para realojar las aplicaciones y los datos; y 3) que se han identificado tanto a las personas como los procesos adecuados para realizar las labores de recuperación y que todos saben lo que tienen que hacer.

Lo cierto es que, si prestáramos la atención adecuada a cómo vamos a verificar los procedimientos de continuidad cuando se seleccionan las distintas técnicas de protección y recuperación de datos, no necesitaríamos poner a prueba la gestión de datos y la sustitución de infraestructuras dentro del sistema de verificación anual. Esto nos permitiría incorporar al sistema las pruebas de recuperación fácilmente en vez de encajarlas a la fuerza.

Desplegar un “wrapper o empaquetador” (algunos denominan a estos paquetes de software: organización en geo-clústers o soluciones de gestión de recuperación de sitios) podría solucionar parte del problema. Productos como CA XOsoft, NeverFail Group NeverFail, entre otros, permiten monitorizar los procesos de protección de datos de forma continua. Pueden avisar al usuario cuando se produce un cambio en el estado de los datos protegidos, es decir, cuando los datos pasan a una nueva localización física o cuando superan los parámetros temporales que se fijaron en los objetivos de recuperación. Y también pueden confirmar que se están llevando a cabo copias de seguridad o réplicas y que éstas se han completado. Con algunos productos, incluso se pueden simular o realizar procedimientos contra fallos en tiempo real para alternar las plataformas diariamente si se quiere comprobar que la infraestructura en la sombra sigue estando preparada para albergar la carga de trabajo que se le va a conferir.

Aunque los wrappers no son soluciones perfectas, si se utilizan con criterio, pueden reducir la carga de trabajo de las pruebas y permitirles a los responsables de la planificación de DR aprovechar el tiempo de duración de las pruebas de forma mucho más eficiente (y económica). En estos momentos en los que la financiación supone un problema para la mayoría de empresas, todos necesitamos hacer lo que podamos para reducir el costo de los procedimientos de prueba.

Sobre el autor: Jon Toigo es un experimentado planificador que ha ayudado a más de 100 empresas a desarrollar y verificar sus planes de continuidad. Ha escrito 15 libros, entre ellos, cinco relacionados con el tema de la planificación de la continuidad empresarial. Actualmente, está escribiendo la cuarta edición de su "Planificación de recuperación ante desastres”, que se distribuirá a través de la Web. A partir de agosto de 2009, los lectores pueden ir leyendo los capítulos según se van publicando y contribuir con sus opiniones y experiencias en http://book.drplanning.org.