Windows system >> Conocimiento de Windows > >> Tutorial del sistema Linux >> Tutorial de linux

Restaurar archivos borrados en Ext3

El siguiente tutorial
le enseñará cómo recuperar archivos que se han eliminado en el sistema de archivos Ext3.

Suponiendo que tenemos un archivo llamado ‘ test.txt ’
$ ls -il test.txt 15 -rw-rw-r – 2 root root 20 Apr 17 12:08 test.txt

Nota :: La opción " -il " indica el número de i-node del archivo de pantalla (15). Si no conoce el "nodo I" del sistema de archivos Unix /Linux, debe agregar la correspondiente Conocimiento En pocas palabras, el i-node es un número de identificación para el archivo de gestión de la operación.

Veamos el contenido:
$ cat test.txtthis es el archivo de prueba

Bien, ahora comenzamos a eliminar archivos:.
$ rm test.txtrm : eliminar el archivo regular protegido contra escritura `test.txt ’? y

Recuperar usando números de diario e inodo

Tenga en cuenta que si elimina el archivo y reinicia el sistema, El archivo diario se perderá y no podremos recuperar el archivo. Por lo tanto, la premisa de restaurar archivos es que Journal no se puede perder, es decir, el sistema no se puede reiniciar.

Como ya sabemos que el número de inodo del archivo test.txt es 15, podemos usar el comando debugfs para verlo:
debugfs: logdump -i < 15 > FS bloque 1006 registrado en la secuencia 404351, diario Bloque 7241 (bloque de inodo para inodo 15): Inodo: 15 Tipo: regular Modo: 0664 Indicadores: 0x0 Generación: 0Uso: 0 Grupo: 0 Tamaño: 20 Archivo ACL: 0 Directorio ACL: 0 Enlaces: 1 Bloqueo: 8Fragmento: Dirección: 0 Número : 0 Tamaño: 0 tiempo: 0x48159f2d — lun 28 de abril 15:25:57 2008atime: 0x48159f27 — lun 28 de abril 15:25:51 2008mtime: 0x4806f070 — jue abr 17 12:08:40 2008Blocks: (0 + 1) : 10234No hay un número mágico en el bloque 7247: fin del diario.

Tenga en cuenta la línea del mensaje anterior:
Bloques: (0 + 1): 10234

Esta es la dirección donde el inodo 15 almacena el archivo (bloque de datos) ). Entonces, conocemos esta dirección, podemos usar el comando dd para extraer los datos de esta dirección.
#dd if = /dev /sda5 de = /tmp /test.txt bs = 4096 count = 1 skip = 102341 + 0 records in1 + 0 records out

si es el dispositivo de entrada

of es el dispositivo de salida.

bs especifica el tamaño de un bloque y

el conteo muestra cuántos bloques deben ser volcados

omitir Descripción Salta 10234 desde el principio Bloquee y obtenga los datos de un bloque

Veamos el archivo recuperado:
$ cat /tmp/test.txt Este es el archivo de prueba

Por supuesto, La recuperación del archivo anterior se basa en el inodo que conocemos sobre el archivo. En realidad, no conocemos esta información. Si no conocemos el inodo, ¿podemos recuperarlo? Sí, esto es posible, veamos cómo recuperarnos.

Uso de la recuperación del Diario y del nombre de archivo

¿Si no conocemos el inodo del archivo, podríamos recuperarlo? Les puedo decir que esto es imposible. Sin embargo, tenemos una manera de saber el número de inodo del archivo. Veamos cómo hacerlo:
$ rm mytest.txtrm: elimine el archivo normal protegido contra escritura `mytest.txt ’? y

Tenga en cuenta que no sabemos su número de inodo, pero podemos usar debugfs Comando para ver (usando su opción ls -d).
debugfs: ls -d 2 (12). 2 (12) .. 11 (20) lost + found 2347777 (20) oss < 2121567 > (20) mytest.txt

Busque el nombre del archivo, Su número de inodo es < 2121567 >. Tenga en cuenta que los inodos de los archivos eliminados están entre paréntesis angulares.

Cuando conoce el número de inodo, entonces podemos recuperarlo fácilmente (usando la opción logdump):
debugfs: logdump -i < 2121567 > Inode 2121567 está en el grupo 65, bloque 2129985, desplazamiento 3840Journal Comience en el bloque 1, transacción 405642, bloque FS 2129985 registrado en la secuencia 405644, bloque diario 9 (bloque de inodo para inodo 2121567): Inodo: 2121567 Tipo: tipo malo Modo: 0000 Banderas: 0x0 Generación: 0 Usuario: 0 Grupo: 0 Tamaño: 0 ACL del archivo: 0 ACL del directorio: 0 Enlaces: 0 Número de bloques: 0 Fragmento: Dirección: 0 Número: 0 Tamaño: 0 tiempo: 0x00000000 — Jue 1 de enero 05:30:00 atime de 1970: 0x00000000 — Jue 01 de enero 05: 30:00 1970 mtime: 0x00000000 — jue 1 de enero 05:30:00 1970 Bloques: FS bloque 2129985 registrado en la secuencia 405648, bloque diario 64 (bloque de inodo para inodo 2121567): Inode: 2121567 Tipo: regular Modo: 0664 Banderas: 0x0 Generación: 913772093 Usuario: 100 Grupo: 0 Tamaño: 31 Archivo ACL: 2130943 Direc Tory ACL: 0 Enlaces: 1 Blockcount: 16 Fragmento: Dirección: 0 Número: 0 Tamaño: 0 ctime: 0x4821d5d0; miércoles 7 de mayo 21:46:16 hora de 2008: 0x4821d8be y mdash; miércoles 7 de mayo 21:58:46 2008 mtime : 0x4821d5d0 — miércoles 7 de mayo 21:46:16 Bloques 2008: (0 + 1): 2142216

Hay mucha información al respecto, veamos más de cerca, puede ver la siguiente línea de información:
FS bloque 2129985 Registrado en la secuencia 405644, el bloque de diario 9

y su tipo es:
Tipo: tipo incorrecto

Eche un vistazo más de cerca a la marca de tiempo del archivo a continuación Bloques: Nada. Así que echemos un vistazo al siguiente bloque:
Bloque FS 2129985 registrado en la secuencia 405648, bloque diario 64 (bloque de inodo para inodo 2121567):

Este Diario tiene información de bloque:
Bloques: ( 0 + 1): 2142216

Esta es la dirección del archivo eliminado. Ejecutemos nuevamente el comando de restauración:
$ sudo dd if = /dev /sda5 de = /home /hchen /mytest_recovered.txt bs = 4096 skip = 2142216 count = 1

Revisemos el contenido del archivo:
$ cat mytest_recovered.txtthis es mi archivo de prueba

Resumen

Bien, aquí están algunos de nuestros resúmenes: 1 ) Use debugfs: ls -d para encontrar el número de inodo del archivo eliminado. 2) Utilice debugfs: logdump para encontrar la dirección del bloque de datos del archivo. 3) Utilice el comando dd para extraer los datos y guardarlos como un archivo.

Existen diferentes maneras de recuperar archivos en Internet. Básicamente, también usan el comando debugfs. Algunos de ellos también usan lsdel. De hecho, son similares. Este tutorial es lo que vi en Internet, aunque dijo que es solo para Sistema de archivos Ext3, pero siempre siento que debería estar disponible para el sistema de archivos Ext2, pero no lo he probado. Tal vez Ext2 y Ext3 no son lo mismo que la salida de información de debugfs. Todo el mundo puede probarlo.

(Fin del artículo)