La recuperación de desastres en un búnker nuclear de la guerra fría

Esta situación se produjo hace ya unos cuantos años, que es por lo cual podemos hablar ahora, pero las lecciones que se aprendieron en aquél entonces, hoy en día siguen siendo importantes.

La situación

Kroll Ontrack recibió una llamada de la OTAN, agencia de comunicación e información, situada justo fuera de La Haya en los Países Bajos. Tenían un fallo en el servidor Windows 2000 y no podían llevar el volumen principal de datos de nuevo en línea. El volumen de datos contenía la única copia de documentos logísticos importantes que eran necesarios a la semana siguiente para un importante ejercicio de la OTAN. El hardware del servidor era una torre HP independiente con una caja de disco externo. Cuatro unidades del disco duro SCSI tenían una configuración RAID 5 utilizando un controlador RAID de canal único Mylex. Creo que el tamaño total del volumen de datos no era más de 98 GB. El servidor se reinició, como parte de una actualización de mantenimiento y dos de las unidades no tenían copia de seguridad online. Podrían haber sido obligados a estar online pero nadie podía asegurar si ambas unidades habían caído al mismo tiempo. Había una pequeña posibilidad de que el RAID hubiera estado funcionando en modo degradado durante algún tiempo. Ellos también tenían la opción de forzar uno de los discos online por algún tiempo, pero si éste hubiera sido el que falló primero, los datos viejos hubieran causado corrupción y si el disco FDisk hubiera funcionado, esto hubiera podido causar daños mayores (FDISK fue configurado para ejecutarse automáticamente en el servidor de arranque).

Otro aspecto inusual de esta situación fue que no había copia de seguridad. Debido a la facilidad de transporte de una copia de seguridad en cinta, se decidió que ello entrañaba un riesgo demasiado alto de seguridad, por lo que no se hicieron copias de seguridad. También se decidió que la redundancia en la RAID 5 proporciona suficiente protección de datos.

Debido al nivel de seguridad de los datos, llevarse el disco del sitio en sí estaba prohibido, por lo tanto éste no podría llevarse a uno de nuestros laboratorios. Cualquier intento de recuperación de datos tenía que hacerse in situ, en las zonas de seguridad, bajo guardia. Esto resultó ser bajo tierra, en un búnker de protección contra bombas nucleares, lo que hizo que se dieran unas cuantas complicaciones inesperadas.

Para preservar la seguridad de nuestro propio software de recuperación no fuera comprometida, necesitábamos un código de seguridad. Normalmente éste se obtiene de la central con una llamada rápida de dos minutos. Pero como éste era un recinto de alta seguridad, todos los teléfonos móviles fueron confiscados antes de entrar y todas las llamadas debían ser vetadas y autorizadas antes de que se pudieran hacer. Cada una de estas llamadas autorizadas, necesitaba un dígito de doce números seguido del número autorizado. La siguiente complicación fue que o bien durante todo el tiempo estábamos encerrados en una área de seguridad detrás de una gran puerta blindada o bien éramos escoltados en todo momento, incluso para ir al baño.

La recuperación

Los datos hexadecimales crudos fueron examinados en cada unidad, para calcular el orden de las unidades y el tipo de paridad de datos antes de crear un RAID virtual y la validación de la integridad de los datos. Resultó que uno de los discos cayó unos días antes, y por lo que habría habido una corrupción generalizada si éste se hubiera forzado online. El RAID fue recreado usando las otras tres unidades de disco y los archivos recuperados copiados a otro volumen de datos.

Lección aprendida

Los responsables de TI tomaron la decisión consciente de no hacer copias de seguridad ya que la evaluación del riesgo de seguridad superó el riesgo de pérdida de datos. Siempre y cuando el nivel de riesgo fuera entendido y aceptado entonces esta sería una decisión válida. También es posible que ellos hubieran incluido una recuperación de datos en sus cálculos.

Sin embargo, cuando se dio la pérdida de datos, resultó que el riesgo era inaceptable. El tiempo de recrear los datos fue mucho mayor que el disponible para cumplir con su programa. Creo que para ellos hubiera sido posible recrear los datos en el tiempo del que disponían pero con un coste adicional significativo comparado con nuestros costes mucho más bajos. También creo que la reputación de alguien estaba en riesgo.

Desde nuestras experiencias en Kroll Ontrack dos fallos en el disco son muy raros pero ocurren con más frecuencia después de un reinicio. Los controladores RAID completan una Auto Prueba de Encendido (por sus siglas en inglés POST) y parte de la prueba, es controlar que los discos duros lean correctamente. Si la tasa de rendimiento de datos está por debajo de las especificadas, éstos podrían fallar el POST, entonces es decisión del operador si se deberían forzar online.