Go to Top

El temido comando dd ataca de nuevo

Server error

A lo largo del tiempo, el lugar de trabajo ha evolucionado en distintas áreas. Ninguna de ellas tan prevalente como el entorno de IT. Actualmente muchas compañías han debido implementar sistemas mucho más complejos para así poder mantenerse al día con los avances de la tecnología. A raíz de esto, los administradores y empleados ahora deben dominar múltiples comandos y múltiples sistemas, por lo que no resulta sorprendente que de vez en cuando se cometan errores. La mayoría de estos errores son insignificantes, aunque desafortunadamente algunos caen en la categoría de grave. Un error que recordamos es el caso de un proveedor de servicios gestionados de Corea en mayo de 2018, en donde el comando dd provocó un inmenso error de datos.

¿Qué fue lo que sucedió?

Muchos de ustedes han escuchado hablar del infame comando “dd” de UNIX. Para quienes no lo sepan, el propósito principal del comando es el de convertir y copiar archivos.

El principal problema es que también contiene parámetros de comando para borrar archivos, particiones e incluso discos duros completos. Esto puede ocurrir si el usuario intercambia los parámetros ´if´ y ´or´, ya que el resultado es indicativo de la abreviatura asignada “dd”. Con frecuencia, se piensa que la abreviatura significa “destruir disco” o “destruir datos”, en lugar del término original “duplicar datos”.

Lo que sucedió fue que se ejecutó incorrectamente el infame comando “dd” de UNIX cuando el proveedor de servicio gestionado cambió los ajustes de configuración del sistema de NetApp del cliente.

¿Fue ese el problema?

Como resultado de la ejecución incorrecta del comando dd en el sistema FAS 8060 de NetApp del proveedor de Corea, se produjo una situación crítica. El comando provocó la eliminación de importantes datos, necesarios para el sistema de producción Sybase conectado de su cliente.

El sistema de NetApp del cliente contaba con un total de 161 discos duros SAS de 900GB, distribuidos en dos conjuntos separados (68 + 93 respectivamente). Para cada uno de los dos conjuntos, el servidor de Sybase tenía disponibles tres LUN de 468 GB. Los seis LUN estaban combinados en un único grupo de datos. Se separaron tres volúmenes lógicos de este grupo de datos comunes y se presentaron a Sybase. Luego del comando dd, uno de los volúmenes lógicos con aproximadamente 45 GB de datos quedó “puesto a cero” y ya no fue posible apuntarlo o dejarlo disponible para el servidor Sybase.

¿Qué hicimos?

Ya que no quería correr el riesgo de perder un cliente valioso, y con pleno conocimiento de las potenciales demandas, el proveedor coreano solicitó nuestra ayuda. Al enterarse de la situación, nuestro equipo de ingeniería le recomendó al cliente apagar el sistema para evitar más movimientos de datos.

Pasaron 12 horas antes de que el cliente pudiera finalmente apagar el sistema para evitar más pérdidas de datos. Para asegurarse de que no se perdiese más tiempo, el proveedor coreano eligió nuestra solución de recuperación de datos remotos. El cliente conectó los 161 discos duros de ambos conjuntos a una computadora con Windows, la que luego se conectó a través de Internet a nuestro servidor de Recuperación de Datos Remotos (RDR), utilizando el cliente seguro que nos proporcionaron. Nuestra opción de RDR les brindó la mejor combinación de velocidad, seguridad y flexibilidad para solucionar la urgente y sensible situación de los datos de su cliente.

Nuestro proceso de recuperación de datos

Nuestro equipo de investigación y desarrollo crea constantemente nuevas herramientas bajo derechos de propiedad para darle solución a proyectos únicos de recuperación de datos, y rápidamente reconoció que no era posible reconstruir “automáticamente” los dos conjuntos con las herramientas ya existentes. Se determinó que, para facilitar la recuperación, deberíamos sumar más ingenieros y llevar a cabo una recuperación manual.

Las unidades fueron clasificadas de acuerdo a los dos grupos de conjuntos. Nuestros ingenieros pudieron reconstruir las unidades y reconstruir los dos conjuntos hasta el punto más cercano posible al original en donde se perdieron los datos.

Ya que los datos originales de los volúmenes lógicos estaban disponibles para el sistema Sybase como almacenamiento RAW, no fue posible que nuestros ingenieros pudieran verificar los archivos al finalizar. Por lo tanto, se extrajeron los seis LUN como archivos planos en un disco de almacenamiento externo, para entregar al cliente.

El resultado

Para restablecer los seis LUN en el sistema NetApp y reconectarlos al servidor Sybase, consultamos al soporte de NetApp. Luego de que los volúmenes lógicos recuperados superaron las verificaciones de integridad sobre el servidor Sybase, el cliente confirmó que todo estaba funcionando bien. El servidor de base de datos del cliente final volvió a estar online solamente algunos días después de la falla, ¡sin pérdidas de datos!

¡Clientes contentos!

Derechos del contenido de imagen y video: Copyright © 2019 Lumen5