Estaba haciendo el otro día mis pinitos con django, cuando por una negligencia, borré una aplicación que ya tenía terminada. La web no era compleja, tenía pocas líneas de código y creía que la podría volver a tener en menos de un día, pero sin embargo, vi la ocasión como una oportunidad para aprender a hacer una recuperación de datos en un disco SSD.
La configuración del disco de este equipo es la siguiente: particionado GPT con varias particiones formateadas con ext4 (nada de LVM). Mi experiencia previa en este tipo de casos siempre ha sido utilizar las herramientas más conocidas en entornos GNU/Linux: sleuthkit, autopsy, testdisk y photorec (éstas dos últimas suelen venir en el mismo paquete), dd, grep…
Volviendo al caso, nada más darme cuenta de lo que había hecho intenté mantener la calma y seguir lo que suele ser mi procedimiento estándar: montar la partición en la que estaba el proyecto como sólo lectura y crear una imagen de la partición con la herramienta ‘dd‘, de manera que las nuevas interacciones con el disco no sobreescriban ningún dato.
Creada la imagen, mi primera opción fue testdisk, un software de análisis forense y recuperación de datos que me ha dado muy buenos resultados en el pasado. No obstante, en esta ocasión me decía que la partición estaba corrupta, por lo que no podía recuperar el contenido del disco. A día de hoy, desconozco si fue por un error mío en las múltiples opciones que ofrece testdisk, o si bien por el contrario esta herramienta no se lleva bien con discos SSD o con particiones GPT.
Tras un primer intento fallido, probé suerte con sleuthkit y autopsy. En esta ocasión, todo iba como la seda. Tras establecer los parámetros iniciales del caso, empecé a “jugar” con las opciones de autopsy:
No obstante, parecía que el procedimiento iba para rato, ya que la imagen de disco tenía cierto tamaño y estaba almacenada en un disco duro externo USB. Como no me apetecía estar delante del PC sin hacer nada un viernes de madrugada, cancelé los procesos de sleuthkit y me puse a utilizar photorec.
Con photorec la cosa cambió: en cuestión de segundos, estaba recuperando multitud de ficheros, algunos de ellos borrados hacía meses. Como iba para rato, pero había podido comprobar que estaba haciendo su tarea, decidí dejar el proceso ejecutándose y continuar la mañana siguiente. Cual fue mi sorpresa al día siguiente al ver que photorec había encontrado unos cuantos miles de ficheros de tipo texto (extensiones txt, java (en este equipo nunca he programado en Java), html, py…).
Dado el gran número de ficheros, nada mejor que un poco de grep y unas cuantas expresiones regulares para encontrar el directorio y los ficheros que me interesaban. Al ser código en python, empleé sentencias que serían únicas de python, como import, nombres de variables que recordaba, tags html…
Al cabo de unas cuentas horas, pese a que parecía que había recuperado casi la totalidad del proyecto y que si faltaba algo podría recodificarlo, había una cosa extraña: el número de ficheros que tenía ahora del proyecto era más del triple del número de ficheros que tenía originalmente. Tras ojear los ficheros para poder cambiarles el nombre por el original (photorec tiene una pega: cambia el nombre del fichero por caracteres alfanuméricos, e incluso hay veces que no detecta correctamente la extensión del fichero), vi que muchos ficheros se correspondían con el mismo y que muchos otros no estaban completos.
Descarté en seguida que se tratara de copias de seguridad: no había considerado que fuese necesario crear una copia de seguridad para un proyecto como éste. Además, ¿qué sería de la vida sin pequeñas emociones? (N.d.E.: niños, no hagáis caso a este insensato)
Mirando los ficheros detenidamente, pude ver como los ficheros se correspondían a versiones viejas de los mismos, como si cuando hubiese hecho un cambio y lo hubiese guardado en disco, se creara un nuevo fichero y se borrase el viejo, almacenándose cada uno en secciones diferentes del disco. También había unos cuantos ficheros parciales, en los que se veían funciones del código pero no todas las que coexistían en el mismo fichero.
Tras indagar un poco, pude discernir entre “versiones”, realizar varias pruebas en la aplicación y ver que líneas tenía que añadir, borrar o modificar para tener la aplicación tal y como la tenía antes. No obstante, se me planteaban nuevas cuestiones. ¿Guarda eclipse varias versiones del mismo fichero? ¿Es cosa del Sistema Operativo? ¿Es por utilizar un disco SSD?
Como muchos lectores ya se habrán imaginado, el causante de este comportamiento es la forma en la que el disco SSD almacena los datos. Sin embargo, me gustaría dejar los detalles técnicos para una próxima entrega, más técnica y menos teórica que la actual.
Nos vemos en la próxima!
Probablemente sea que eclipse crea “archivos de backup” (que eliminará más tarde) mientras estas editando el archivo; estilo lo que hace JEdit: Crea archivos copia del original, añadiendo un ~ al final del nombre, para “volver rápido” cuando uno se prende al Ctrl+Z (deshacer). Generalmente elimina esos archivos al guardar el original, pero a veces los deja (creo yo, cuando se hicieron muchas modificaciones).
Tal vez esto responda alguna de tus preguntas.
Saludos!
La experiencia demuestra que es importante tener copias de seguridad, a mi me paso algo parecido y ahora tengo instalado Copian Backup, haciendo copias de seguridad cada 24hrs de todos mis ficheros de trabajo en 2 discos diferentes.
No conocía el software que has dicho y aún así lo tendré en cuenta por si me vuelve a ocurrir algo parecido.
Disculpa, es algo que no ha quedado muy claro. Eclipse guarda un historial de los cambios, de ahí surgen la mayoría de ficheros completos recuperados. No obstante, los ficheros parciales, no tienen nada que ver con Eclipse, y sí con la forma en que se guardan los datos en el disco… aunque eso, como ya he comentado, será en la próxima entrega :)
Muy buenas tardes a todos,
El tema del forensic en discos SSD es algo francamente complicado, por la propia forma de ser de los SSD, que es MUY diferente a bajo nivel de lo que son los discos duros cĺásicos.
Por poner un ejemplo, los SSD tienen “garbage collection” integrada en el propio firmware que hace que solo con estar encendidos puedan ir “borrando” información automáticamente (lo que hace el recovery infernal y nada de fiar).
Y por otra parte, muchos firmware “apilan” bloques copiándolos de un lado para otro … y no borrándolos, lo que hace el borrado seguro otra pesadilla.
Todo eso sumado a que cada SSD tiene su propio firmware hace que el análisis forense de estos cacharros sea algo francamente … interesante :)
Aquí os dejo un artículo (ojo, denso) sobre el tema:
http://static.usenix.org/events/fast11/tech/full_papers/Wei.pdf
Un saludo,
Antonio Sanz
CISA,CISM,CHFI
Si dices “pero” no digas a continuación “sin embargo”. Son elementos redundantes al ser dos conjunciones adversativas.
Es como decir “Sr. Don Fulanito de tal”… (muy común en cartas por cierto)
“Don” viene de la abreviatura de Dominus, -i (que significa señor en latín). Por lo que si te refieres a alguien como “Sr. Don…” lo que estás diciendo es Sr. dos veces (Sr. Sr. Fulanito de tal = REDUNDANTE)
Por lo demás, interesante artículo.
Keep on learning :-P
Saludos.
Si bien el uso de “pero” y “sin embargo” es redundante, no implica por ello que sea una construcción incorrecta.
Al respecto, he encontrado dos referencias que me parecen relevantes para aclarar esta duda, donde cada una de ellas plantea un argumento diferente (la primera de ellas efectivamente lo indica como una redundancia pero con una función lingüistica):
a) http://www.elcastellano.org/consultas.php?Tag=locuci%F3n&Pag=27 (primera consulta)
“» usos de la palabra PERO y SIN EMBARGO
P: Serían tan amables de ayudarme a disipar una duda, gracias. Es correcto utilizar juntas las palabras: “pero sin embargo”
R: Está bien dicho, es un pleonasmo que refuerza la expresividad. Aunque, por supuesto, no es necesario usar las dos expresiones para expresar la idea, solo para reforzarla.”
b) http://www.fondodeculturaeconomica.com/obras/suma/r3/buscar.asp?word2=pero%20sin%20embargo
“Ahora bien, puede observarse que el constituyente sin embargo no se comporta de conformidad con lo estipulado para las conjunciones coordinantes, pues, por una parte, puede aparecer junto a un nexo coordinante (“estaba lloviendo pero sin embargo fui a la cita”) y, por otra parte, no necesariamente aparece siempre en posición inicial del sintagma que introduce (“estaba lloviendo, sin embargo fui a la cita” y “estaba lloviendo, fui sin embargo a la cita”).”
Por tanto, podríamos decir que aunque “pero sin embargo” pueda levantar alguna suspicacia lingüistica, no es del todo cierto que no puedan ser utilizados juntos.
Gracias por leernos y (sin ironía) motivar estas dudas.
Interesante el artículo e interesante también el breve debate sobre propiedad en el uso del lenguaje (para que luego digan que los informáticos somos unos catetos que no saben mas que de ordenadores). Sin embargo (sin pero, que hace mucho que la Academia ya ni limpia ni fija ni da esplendor y sólo recoge el “uso” que la gente hace del español, gracias a lo que disfrutamos de palabras “correctas” como “cocreta” y “almóndiga”. A “fragoneta” y “malacatón” les faltan dos telediarios para entrar en el diccionario… >_< ) yo escribía para confirmar que sí, que Testdisk falla con SSD, aparte de que directamente se niega (al menos en su versión 7) a leer particiones BTRFS. Photorec escarba en BTRFS y SSD, pero no permite buscar sólo archivos borrados, y recupera todo lo que puede de la partición entera, cosa que es insufrible cuando lo que hemos borrado son unos cientos de megas en una partición de medio tera que llevamos usando varios años. En este terreno de nuevo hay que lamentar el hecho de que en Linux no tenemos nada que pueda hacer sombra a las aplicacione que hay para Windows, por ejemplo Recuva, me recuperó de un SSD los archivos borrados con sus nombres y sus metadatos y la estructura de directorios, en EXT4, no conseguí hacerlo funcionar con BTRFS, pero sí funcionaron Active@ File Recovery y Sysinternals Linux Recovery, aunque sin metadatos nombres de archivo correctos ni estructura de carpetas, lo típico de la técnica de escarbado de archivos. Ademas estos programas tienen interfaces gráficas con visualización de los archivos recuperados, presentación de los resultados antes de que se proceda a su restauracion y elección hasta individual de los directorios y archivos que queremos recuperar, evitándonos así juntarnos con casi medio millón de archivos, y tener que comprar un disco nuevo para poder tener espacio, como en mi caso parecía que iba a tener que hacer si recuperaba con Photorec. Hay que decir que Photorec tiene una incipiente interfaz gráfica llamada Qphotorec, aunque bastante espartana y sobre todo, también abandonada. Todavía usa QT 4 y creo que la ultima versión es de 2013.
Autopsy, como han convertido en abandonware la versión para Linux, que quedo olvidada en su versión 2 mientras que la de Windows va ya por la 4, pues no se si funciona mucho mejor, pero no creo que una versión de hace mas de un lustro funcione mejor que las ultimas versiones de los programas Windows que he mencionado.
En fin, una pena, otra vez mas, que con tanta facilidad para acceder a los conocimientos y tanta herramienta parcial, no haya ninguna realmente completa para Linux.
Por cierto, lo de los archivos duplicados es normal: cuando guardas un archivo modificado, no necesariamente se escribe encima del previo, a veces se escribe en otra zona del disco, lo que a efectos prácticos de "file carving" significa que hay dos archivos que probablemente serán recuperados en la restauración; enteros o a trozos ya dependerá de si algún bloque, sector o lo que sea, que contenía dichos archivos, ha sido reescrito tras su borrado. Lo mas cómodo para gestionar estos duplicados es usar Fslint, Dupeguru (o Dupeguru Picture Edition si queremos poder previsualizar las imágenes que nos encuentre) y echarle paciencia.
Saludos.