ext3: Misión Imposible

Pedro Carrasco — Sat, 27 Oct 2007 22:34:39 +0000

A todos nos ha pasado alguna vez. Escribes sin querer un argumento de más en la consola al hacer un rm o eliges el fichero equivocado (o el directorio, que es aun peor). En el momento en que presionas enter, te das cuenta de que no querías hacer lo que acabas de hacer. Así que intentas recuperar el fichero del backup, pero entonces recuerdas que ibas a hacer el backup justo despues de borrar el fichero.

Si estás trabajando en un sistema de archivos FAT o NTFS no hay problema, existen multitud de herramientas de recuperación de datos, pero si trabajas bajo ext3 (o ext2), que es el sistema de archivos más extendido entre la mayoría de distribuciones de Linux, lo tendrás más difícil. El modo en que ext3 borra los ficheros es la causa de su especial dificultad. Información relevante acerca de dónde se encuentra el contenido del fichero se borra durante el proceso de borrado.

En este artículo intentaremos recuperar esos preciados archivos de una partición ext2 o ext3 que por descuido han ido a parar más allá de la papelera de reciclaje.

Suceden varias cosas cuando un fichero se borra en ext3 desde Linux. Pero de un modo general para una máquina Linux, podemos decir que al menos, el sistema operativo marca el bloque como vacío por lo que otros ficheros pueden usar ese bloque liberado. Herramientas como debugfs y e2undel podían fácilmente recrear los archivos en ext2. Esto funcionaba siempre que los bloques no hubieran sido utilizados por un nuevo fichero ya que en ese caso, el contenido original habría sido sobreescrito.

Con ext3, hay un paso adicional que hace la recuperación de ficheros un poco más dificil. Cuando el bloque se vacía, también se borran las direcciones del resto de bloques del inodo, por lo que no podemos determinar dónde estaba situado el contenido del fichero.

¿Cómo recuperamos archivos borrados?
Lo primero que debemos hacer en el momento en que nos damos cuenta que hemos borrado algo por error es apagar el PC y conectar el disco duro en otro ordenador con Linux como esclavo o simplemente arrancar desde un CD de linux. Si es un dispositivo que podemos desmontar (como una memoria USB o algo así), desmontándo el dispositivo es suficiente.

El primer paso a realizar para intentar recuperar la información es encontrar la dirección del inodo del archivo. Podemos determinar esta direccion desde debugfs, que es una pequeña aplicación que permite depurar el sistema de archivos y que además suele venir en la mayoría de distribuciones. Para empezar a usar debugfs tenemos que saber qué dispositivo contiene el fichero borrado. En este ejemplo, hemos arrancado desde un CD y el disco es el dispositivo /dev/sda1, así que teclearemos lo siguiente:

root@pedro# debugfs /dev/sda1
debugfs 1.40.2 (12-Jul-2007)
debugfs:

Ahora podemos usar el comando cd para cambiar al directorio del fichero borrado dentro del debugger:

root@pedro# debugfs /dev/sda1
debugfs 1.40.2 (12-Jul-2007)
debugfs: cd directorio

Una vez allí, podemos listar los ficheros borrados en el directorio haciendo un ls -d. Los archivos borrados se indican mostrando el inodo entre los símbolos "<" y ">".

debugfs: ls -d
356225 (12) . 2 (4084) .. <356226> (4072) ooops.jpg

El archivo que intentaremos recuperar se llama ooops.jpg y podemos ver que anteriormente estaba en el inodo 356226.

La técnica de recuperación que usaremos, utiliza la cabecera de los archivos borrados. Muchos formatos de archivo tienen un valor estándar en los primeros bytes de la cabecera del archivo, de este modo mediante esta técnica buscaremos esos bytes para determinar dónde el archivo supuestamente contiene el inicio. Por ejemplo, los archivos JPEG empiezan con 0xffd8 y acaban con 0xffd9. Para recuperar archivos JPEG que se han eliminado, miraremos en los primeros dos bytes de cada bloque en busca de 0xffd8. Si lo encontramos, solo nos quedará buscar el final del archivo que está marcado con 0xffd9. Todo lo que haya en medio, debería ser el fichero en sí. Lo malo es que no todos los ficheros tienen un fin de fichero estándar, por lo que determinar donde acaba la información puede ser complicado. Un ejemplo de una herramienta libre que realiza usa este método es foremost, aunque también existen aplicaciones comerciales.

Podemos aplicar foremost a todo el sistema de archivos, pero probablemente acabaremos con excesivos archivos recuperados. Por eso intentaremos acotar la búsqueda, y en vez de realizarla en todo el sistema, lo haremos solo en un grupo de bloques concreto. Con el comando imap de debugfs, obtendremos el grupo de bloques al que pertenece el inodo:

debugfs: imap <356226>
Inode 356226 is part of block group 22
located at block 720898, offset 0×0080

Ahora averiguaremos el rango de bloques del grupo 22 con el comando fsstat:

root@pedro:~# fsstat /dev/sda1
FILE SYSTEM INFORMATION
——————————————–
File System Type: Ext3
Volume Name:
Volume ID: 47e3e5e3604b71bbdf43738bcbcad03a
(…)
Group: 22:
Inode Range: 356225 – 372416
Block Range: 720896 – 753663
Layout:
    Data bitmap: 720896 – 720896
    Inode bitmap: 720897 – 720897
    Inode Table: 720898 – 721403
    Data Blocks: 720898 – 720897, 721404 – 753663
Free Inodes: 16191 (99%)
Free Blocks: 32259 (98%)
Total Directories: 1

El grupo 22, empieza en el bloque 720896 y acaba en el bloque 753663, así que examinaremos solo ese rango. Para extraer esos bloques, utilizaremos la herramienta dls:

root@pedro:~# dls /dev/sda1 720896-753663 > /mnt/recovery.dat

El comando anterior guardará los bloques del grupo 22, en un fichero llamado /mnt/recovery.dat. Asegurate de que se guarda en un sistema de ficheros distinto al que queremos recuperar, sino podriamos ser incapaces de recuperar la información que buscamos.

Una vez acabado este proceso, podemos utilizar foremost para intentar recuperar el archivo borrado:

root@pedro:~# foremost -d -i /mnt/recovery.dat -o /mnt/output/

El directorio /mnt/output contendrá los archivos que se han podido recuperar, junto con un archivo de texto con el nombre de los archivos recuperados y el formato identificado. Si el fichero a recuperar es demasiado grande o no obtenemos el resultado deseado, quizás seria conveniente aplicar foremost a todo el sistema, usando el comando:

# foremost -d -i /dev/sda1 -o /mnt/output

Espero que este pequeño manual pueda ser útil a todos aquellos torpes que, como yo, hayan borrado parte de su disco duro sin saber exactamente cómo (o sin querer decir cómo). Y recordad que las copias de seguridad son mucho más cómodas que andar mirando bloques e inodos.

Innovando en las Tecnologias de la Información » ext3

ext3: Misión Imposible

Artículos relacionados