Vacaciones y la recuperación de fotos perdidas. Photorec

En estas vacaciones no hemos aplicado tecnología alguna, lo que es muy bueno para el estrés, salvo apretar un tornillo con una llave allen y darle al botón para hacer fotos. Con la nueva cámara TZ-100 es algo más complicado que dar a un botón, por que se puede manejar casi todo, pero una vez aprendido lo fundamental, ya automatizas las opciones. Sin embargo, a la vuelta si hubo que aplicar algo de técnicas de recuperación. La cosa fue así; un día estaba realizando fotos y uno de los fotografíados no estaba contento con la foto en la que salía y decidió borrarla; no sé como hizo, pero en vez de borrar una foto, borró 121 —dos días enteros de turismo—. No me preocupé mucho, por que se pueden recuperar fácilmente con photorec, como ya hemos visto en alguna entrada previa.

https://www.cgsecurity.org/mw/images/Photorec.png

Por supuesto, por seguridad, y para evitar que se perdiera cualquiera de las fotos borradas, cambié la tarjeta de datos de la cámara, y así las fotos nuevas no reescribirían las áreas donde están las fotos borradas —como sabemos, al borrar lo único que se hace es borrar en la tabla de partición la localización de los datos del fichero, pero no se borran los datos en si—. Al cambiar de tarjeta, no hay borrado accidental de los datos. Después, con tranquilidad, se aplica photorec, que instalamos mediante testdisk

su -c 'dnf install testdisk'
    passwd
photorec

y listo; hay que hacer algunas cosillas después de que se ejecute photorec, pero son bastante intuitivas. Como aviso, lo más delicado es decir si se revisa toda la unidad o la partición; el resultado suele ser mejor eligiendo la partición.

Sin embargo esta cámara tiene sus "novedades". La tengo configurada para grabar una imagen raw, formato ra2, y una jpg ya transformada desde ese raw. Al recuperar las fotos me encontré con unas 115 ra2 y 15 jpg tamaño normal y muchas jpg tamaño de alrededor de 5kb. Las 6 imágenes jpg sin raw tienen una explicación sencilla; son las fotos panorámicas, que la cámara no puede grabar como raw. Pero quedan 9 jpg con su raw, es decir, recuperados los dos ficheros, y luego 100 jpg miniatura con 100 raws completos. Yo supongo, y solo es una suposición, que la cámara no guarda todos los jpgs automáticamente, sino que graba un fichero con las características de control que quiere aplicar al raw y cuando la extraes las fotos, la propia cámara compone el jpg. Como es natural, lo que hice fue hacer una transformación de cada raw, directamente. Algunas han quedado muy bien, y otras no tanto. Habrá que revisarlas cuando haga falta. Eso sí, photorec recuperó sin problemas las 121 fotos, y no hubo que lamentar la pérdida de fotos importantes.

Para terminar, recomiendo llevar siempre una segunda tarjeta de memoria, para evitar tener que utilizar una en la que haya que recuperar material —u otras razones—, y dos baterías, por que si no luego de la foto 250 no se pueden sacar más. Y, por supuesto, un cargador para poder cargar la que has terminado cada día.

Leyendas urbanas. Un "experto" dice que no es necesario desmontar dispositivos USB...

Expliquemos el problema. Dos personas desesperadas se acercan con cara de angustia por que el fichero del trabajo que llevan varios días realizando es ilegible en su pendrive.
A la pregunta de si disponen de otra versión en el ordenador dicen que las dos han trabajado solo e la unidad USB. Primera reprimenda, solo se debe trabajar como única versión de un documento en una unidad USB externa si estamos e condiciones "especiales" —ordenadores ajenos, cibers, o en ordenadores sin disco duro, como un RaspberryPi o dispositivos antiguos de reciclaje—.
Al inspeccionar la unidad e intentar abrir el fichero —fichero de word docx— aparecen todos los síntomas de corrupción de tabla de partición por desmontado incorrecto o haber extraído la unidad mientras estaba grabando. Examinamos con gparted y discos la unidad y esta formateada con FAT16, es decir, sistema de fichero sin journaling.
Esto se suele solucionar aplicando photorec, utilidad incluida en testdisk. Photorec es capaz de recuperar los bloques de información identificando los ficheros borrados o "perdidos" a través de la firma identificativa inicial que lleva cada fichero en su inicio, en los metadatos.

Normalmente logramos recuperar lo necesario con est aplicación, siempre que no se haya escrito sobre ella. Si con photorec no lo logramos, acudimos a foremost; en este caso no fue necesario.
Listo. Se recuperó el trabajo, y se recomendó un formato nuevo de la unidad, ya qe la tabla de partición estaba corrupta.
Lo mejor vino después; ante la acusación de no haber desmontado correctamente ambas personas afirmaron que nunca desmontaban por que un "EXPERTO" les había dicho que no era necesario, que desmontar era una pérdida de tempo y que nunca les había sido necesario.
Si bienes cierto de que si no has cambiado nada en la unidad es posible que te salves saliendo sin desmontar, si has realizado algún cambio y no cierras correctamente antes de salir, tarde o temprano, más bien temprano, tendrás un problema en la unidad, y adiós trabajo. Este es un caso claro de una leyenda urbana; alguien, un "experto", claro, no ha cerrado y se ha librado; corre el rumor que lo de desmontar no es necesario y de manera viral se lo acaba creyendo todo el mundo. Resultado final, trabajo para los técnicos. ¡BIEN!... o quizás no tan bien.

Recomendaciones:
1. Trabajen en el ordenador y no se fíen de un dispositivo USB (no sirve como copia de seguridad). Es solo un método de transporte de información, y no el más seguro.
2. Desmonten/maten correctamente las unidades antes de extraerlas.
3. Si es posible (a veces no podemos por problemas con la compatibilidad con cámaras y otros artilugios), formateen con un sistema con journaling. Aunque soy usuario de Linux, tengo que utilizar ordenadores del lado oscuro frecuentemente, así que formateo en NTFS. Sí, no es un perfecto journaling, pero es un compromiso entre seguridad, tamaño de ficheros y productividad.
4. Identifique al "experto", antes de hacerle caso. No es necesariamente el que te lo cuenta en facebook, ni el amigo del cuñado del primo segundo del vecino del apartamento de verano.

Si no ha hecho caso a estos consejos gratuitos, no se olvide, photorec o técnico cualificado.

Recuperación de datos borrados. Testdisk y photorec

Este es uno de estos casos de recuperación de información perdida de los que hemos hablado en ocasiones. Este en particular se refiere a un disco duro en el que el dueño hace una mala jugada y borra directamente información sin darse cuenta de que no la ha duplicado. El problema fundamental está en que no hay copia de seguridad. El arreglo por parte de los técnicos termina con ficheros con nombre y sin contenido, así que hemos hecho un intento de recuperación con testdisk. Las particiones aparecen, aunque la importante que contenía los datos no puede ser montada en Linux (¿falta de NTLDR?). Éste es el log

#1462463494 Disk /dev/sdc - 320 GB / 298 GiB - CHS 38913 255 63
 1 : start=     2048, size=   407552, Id=07, *
 2 : start=   409600, size=592109568, Id=07, P
 3 : start=592519168, size= 32409600, Id=07, P
 4 : start=624928768, size=   211632, Id=0C, P

Para estar seguros copiamos una imagen con ddrescue por si luego no podemos trabajar con el disco y para mantener una copia de recuperación:

su -c 'ddrescue -v /dev/sdc2 /home/copiadd/imagen.img'

Luego lanzamos photorec sobre sdc2, con la recuperación de 269.101 ficheros en 532 directorios de recuperación (recup_dir.532). Hasta ahí mi trabajo. Para el fin de semana el dueño del ordenador tendrá que encontrar las diferentes agujas (unas 2000) útiles dentro de un pajar de 269.101 ficheros.

PD. Y me pregunto yo que habrán usado estos técnicos para no encontrar nada (sí, ha pasado por técnicos que solo han recuperado los nombres de los ficheros)

Disco duro escrito a ceros por su cuenta

Este es un caso de poltergeist del que no he sido capaz de encontrar una explicación. Por pasos:
Una compañera de trabajo me entrega un disco del que le gustaría recuperar miles de fotos que ha perdido (lo de las recomendaciones de las copias de seguridad lo dejamos para otro momento). Es el disco duro Toshiba, 2.5' y 500GB

de un Netbook de las siguientes características:
ACER Aspire One D255, Intel Atom N455, 1GB de RAM (DDR3) y con Windows 7 Starter como sistema operativo.
El netbook de repente dejó de funcionar, y en la tienda fueron incapaces de recuperar nada del disco, así que le pusieron uno nuevo y listo.
En principio pensé que no habían aplicado tiempo suficiente y que sería fácil recuperar la información, bien con foremost o photorec.
Al introducir el disco en el sistema (Fedora 20 64bits, con KDE como máscara gráfica), la aplicación discos lo detecto pero sin partición y, curiosamente, dándolo como disco perfecto, sin ningún daño, así que...

Pregunta 1. ¿Por qué falló el sistema y sin embargo el disco está perfecto? Sí, un virus, troyano o similar. Muy bien, le borró el MBR; lo recuperamos y listo.

Por seguridad, creé una imagen con ddrescue, de forma similar a como decíamos aquí con una unidad USB. De esta forma, trabajamos sobre la imagen y no trabajamos sobre la superficie magnética, y evitamos empeorar daños físicos (que según S.M.A.R.T. no había). Una vez generada la imagen de 467GB, es decir, el disco completo, no fue posible montarla, ya que el disco original no estaba particionado. Con testdisk intenté recuperar la partición, pero fue imposible, ya que ni en busqueda superficial ni profunda pudo encontrar rastro de una tabla de particiones en el disco. Bien, no es la primera vez que pasa algo así. Simplemente, si los datos aun están ahí, foremost o photorec pueden encontrar las cabeceras de ficheros y recuperar al menos parte de ellos (no siempre están en un solo trozo contiguo, y sin la tabla de partición no se pueden reconstruir y volver a unir los trozos separados), aunque no se conserve el nombre y directorio.
Al pasar photorec (ver aquí), el resultado fue un directorio de recuperación ¡completamente vacío!

Cada carpeta de recuperación en función de la identificación de photorec (o foremost, por que lo hice tantas veces que ya no recuerdo cual es cual) dice 0 ficheros recuperados. Es decir, varias horas de revisión de la imagen da cero cabeceras de fichero reconocibles.

Pregunta 2. ¿Como se las arregla un usuario básico en un netbook con Windows 7 starter para escribir en ceros un disco duro de 500GB sin darse cuenta?

Si eso es imposible, o al menos muy poco probable,

Pregunta 3. ¿Qué otra circunstancia o condición puede provocarlo?

Para estar seguro, después de probar dos días seguidos todo lo disponible en la imagen, luego lo apliqué directamente sobre el disco duro, con el mismo resultado. Más aun, por si es cuestión del sistema, luego lo intenté con un Hiren's Boot 15.2, arrancando con Windows XP mini y aplicando toda la bateria disponible.

Por supuesto, lo único que me entra en la cabeza es que en la tienda hayan hecho un formateo profundo, pero no lo creo, por que en un disco de 500GB aun lleva un rato bastante largo. Pero si el usuario no es capaz de hacerlo, que otra circunstancia provoca el borrado completo de datos de un disco dejándolo completamente cubiero de... NADA. Por que los virus y troyanos de hoy lo quieren son las tarjetas de crédito y las palabras clave, o bloquearte el sistema y pedir rescate, pero no borrar discos duros, como antes.

Se admiten respuestas.

PD. El disco funciona perfectamente; lo he formateado en NTFS y lo he llenado casi del todo de material multimedia que se ve y escucha perfectamente; por si había dudas del dispositivo.

Recuperación de datos en una unidad USB sin formato

Hoy me han dado un lápiz USB que, de repente, había perdido el formato. En general aplicamos photorec (del paquete testdisk) y siguiendo las instrucciones se recuperan todos, o al menos gran parte, de los ficheros; es especialmente útil para recuperar las fotos de las tarjetas de las cámaras digitales. Sin embargo, hoy la cosa se puso más difícil, por que al llegar al quinto fichero se paraba la acción por algún error y se cortaba photorec en el terminal.
Aunque no tenía experiencia, decidí aplicar foremost sobre la unidad, pero tardaba mucho tiempo, mucho más del necesario. Llegado a este punto copie una imagen del lápiz (sudo ddrescue -d /dev/sd? imagen fichero.log) y trabajar sobre ella. La imagen no se pudo montar, así que aplicamos foremost sobre ella (foremost -vqT /rutadeenlace/imagen) y recuperamos CASI todo, unos 180 ficheros, más o menos. La única pena es que el que se necesitaba en ese momento fue el único que no se recuperó. Eso me lleva a pensar de que la razón de la pérdida de formato del lápiz se deba a que estaba en formato FAT32 y había sido extraído del ordenador con ese fichero abierto. La segunda posibilidad es que el troyano que posiblemente tenía (un fichero exe pequeño, 9KB, que recuperó foremost me parece muy sospechoso) pudiera impedir el desmontado del USB, y ya sabemos que los sistemas de ficheros sin journaling, como FAT o FAT32, si no se extraen adecuadamente, pierden fácilmente el formato (el ejemplo más claro son las unidades con Slax en FAT32).
Después intenté trabajar en la imagen con autopsy, pero me superó y no pude cargar la imagen en el "caso nuevo" abierto. Tengo que aprender más sobre ello. O no encontré documentación clara para mi o no busqué lo suficiente.

Error en un disco duro

Como hemos comentado, hace unos días añadí un disco de 1TB a mi ordenador de trabajo. Con el generé home en una partición de 500 GB para poder poner una máquina virtual de más GB para Windows. La otra parte la deje para sustituir el disco de datos, que en general ya no monto casi nunca, y que solo uso como copia de respaldo dentro del mismo ordenador. Cuando acabé de trabajar di la orden de copiar el antiguo disco de datos, un WD de 320GB, a esa partición y me marché. Al día siguiente, pensando que todo estaba bien, sin ver ningún mensaje extraño, lo desmonté, apagué la máquina, saqué el disco de 320, volví a encender la "machina" y me puse a trabajar. En un momento determinado quise recuperar un fichero antiguo, fui a la partición de datos y estaba ¡vacía!. Solo se había copiado el primer directorio y no completo. Volví a montar el disco anterior con cables conceptronics y no fui capaz de montarlo, recibiendo un mensaje simialr a este:

    mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
    missing codepage or other error
    In some cases useful info is found in syslog - try
    dmesg | tail or so

Como soy obediente, ejecuté
    dmesg | tail

de lo que obtuve, más o menos
    EXT2-fs error (device sdc1): ext2_check_descriptors: Block bitmap not in group
    EXT2-fs: group descriptors corrupted!

Lo primero es que el disco estaba con sistema de archivos ext3, así que no entendí la respuesta. Segundo, no fui capaz de montarlo ni extraer datos. Es bien extraño, por que había funcionado hasta el día anterior y se había extraído correctamente. Buscando información encontré dos posibles soluciones. La primera se corresponde a este blog, con lo que decidí ejecutar:

   fsck /dev/sdc1 -y

Después de una hora de copiar y recupera sectores, terminó y ya se pudo montar el disco. Sin embargo, no se pudo recuperar todos los directorios de datos (se perdieron alrededor de 4 GB de un total de 80, asociados a dos directorios perdidos completamente y que no se pudieron recuperar, aunque en la ejecución de fsck los estaba clonando). No pasó nada irreparable, por que tenía dos copias realizadas antes de Navidad, y como ese disco solo es la primera copia de respaldo que se usa esporádicamente, no había muchas variaciones, y las que estaban las tengo en Dropbox.

La segunda posibilidad era aplicar testdisk. Realmente no me dio tiempo, por que ya había ejecutado la anterior. No puedo por tanto comparar ambas posibilidades, pero si me vuelve a pasar algo similar intentaré usar testdisk. Si funciona tan bien como photorec (utilidad de testdisk) debe ser una maravilla. Parece además bastante fácil de utilizar.