Recuperación artesanal de datos con dd_rescue (1/2)

La migración a Ubuntu me ha dado algún dolor de cabeza que no pude prever al principio (en general por culpa de temas ajenos a Ubuntu), aunque también me ha dejado una buena colección de casos para ir colgando aquí.

Lo más serio con lo que me he encontrado ha sido un problema físico en un disco que estuve utilizando para el backup previo al movimiento. Para más datos un problema de sectores ilegibles. Tengo que hablar mal del fabricante del disco (WD). Era un disco USB nuevo que compré sólo para ese propósito, con la esperanza de no tener problemas. Curiosamente el desastre que provocó este disco ha sido el mayor de mis problemas. Pero también debo decir que en la tienda me lo cambiaron en seguida nada más ver el juego de comprobaciones que les llevé (obtenidos con la propia herramienta de diagnóstico de WD). Y el que me dieron en sustitución del defectuoso, también WD, funciona perfectamente. Al menos de momento.

Tenía un segundo backup algo más antiguo, así que hubiera sido un caso de poca importancia de no ser porque ese segundo backup no contenía unas líneas de código PHP con las que he estado trabajando hace poco, y que tenían bastante valor para mí.

Para acabar de rematar, el disco de origen de donde había salido el código ya estaba formateado y con la nueva Ubuntu corriendo, habiendo pasado de NTFS a ext3. Encima la nueva FAT no tenía nada que ver con la anterior.

Conozco algunas herramientas de recuperación, no todas claro. Las que he hecho servir alguna vez, "prefieren" que la partición a analizar no haya cambiado el tipo de filesystem: recover, e2undel, ntfsundelete de linux-ntfs.org, ntfsundelete de ntfsundelete.com... Ya había escrito en esa partición para instalar el nuevo SO. La FAT había cambiado... Me sentía pesimista, así que no quise meterme muy a fondo con ninguna de estas herramientas. Lo poco que llegué a probar no funcionó con mi escenario.

Pero no me resignaba. Lo que necesitaba recuperar no eran más de 200 líneas de código y se me ocurrió que si era capaz de hacer algo así como un grep en bloques físicos del disco, en lugar de ficheros... igual tenía suerte. Pensándolo una segunda vez me dí cuenta de que la cadena de búsqueda debía ir en consonancia con el character encoding que hubiera utilizado para grabar el fichero que contenía el código. Por ejemplo, si edito un fichero /tmp/fichero_test.txt cuya única línea sólo contenga la palabra "peremolto.net", y lo guardo en UTF-8, al hacer un hexdump -C (Canonical hex+ASCII display) veo lo siguiente:

nouser@nohost:~$ hexdump -C /tmp/fichero_test.txt
00000000 70 65 72 65 6d 6f 6c 74 6f 2e 6e 65 74 0a |peremolto.net.|
0000000e

Si en cambio guardo el mismo fichero en UTF-16 (siempre que mi editor de textos lo permita, p. ej. Eclipse), la salida del hexdump es esta:

nouser@nohost:~$ hexdump -C /tmp/fichero_test.txt
00000000 fe ff 00 70 00 65 00 72 00 65 00 6d 00 6f 00 6c |...p.e.r.e.m.o.l|
00000010 00 74 00 6f 00 2e 00 6e 00 65 00 74 |.t.o...n.e.t|
0000001c

Como es lógico la información plasmada en disco también es distinta.

En el segundo caso, UTF-16 provoca que cada carácter quede representado con un número mayor de bytes que en el caso de UTF-8. Así que si al final logro hacer mi grep sobre bloques de disco, he de tener en cuenta este detalle.

Tirando del hilo llegué a la conclusión de que no había utilizado UTF-16, pero tampoco estaba seguro de si lo que habría hecho servir era UTF-8 o Western ISO-8859-15... Por suerte, las cadenas de texto que recordaba de mi código se guardan con la misma secuencia de bytes en ambos casos.

Sigo con el grep. En concreto, el tipo de "match" que yo pretendía llevar a cabo viene documentado en el man (o info) correspondiente como "procesar un fichero binario como si fuera texto", y se puede hacer (sobre ficheros en un filesystem) con el modificador -a. Pero ¿cómo hago un grep sobre bloques de disco que no "hospedan" ficheros? (y que por lo tanto el filesystem no puede tratar con grep).

Una posible solución se encuentra en otro comando al que le tengo un cariño especial: dd. Con dd puedo, entre otras cosas, leer en la posición del disco que me dé la gana y luego escribir lo que he obtenido en un fichero. El inconveniente de esta gran utilidad es que cuando hay un problema físico en el disco, el proceso se eterniza debido a los repetidos reintentos de lectura o escritura. Si mis discos no tienen problemas, con dd tengo suficiente. Pero si trabajo con discos "conflictivos", dd_rescue es una alternativa mejor. Hasta donde yo sé dd_rescue hace todo lo que hace dd y más, así que utilicé dd_rescue.

Ya tengo todos los ingredientes que necesito. Vengo con la receta.