El archivo está misteriosamente vacío. ¿Opciones para recuperarse?


9

He visto varias publicaciones sobre la recuperación de archivos eliminados, pero esta situación es diferente. Mi esposa tenía un archivo llamado Journal.odt en el que guardaba mucha información personal importante, como recuerdos especiales sobre nuestros hijos. El otro día, cuando intentó abrirlo en OpenOffice, se quejó del formato. Tuve su golpe cancelar y volver. Cuando catel archivo está completamente vacío. lsdice que el archivo tiene 0 bytes.

Si ella hubiera seleccionado accidentalmente todo el texto en el archivo, presionó la tecla de retroceso y lo guardó, todavía habría la metainformación de OpenOffice en el archivo.

Inmediatamente apagué su computadora portátil para evitar hacer más cambios en el disco hasta que se me ocurra algo que hacer.

He hecho algunas cosas complicadas en el pasado, como usar ddpara recuperar texto sin formato del disco, pero no tengo idea de qué hacer aquí. Como los archivos impares no son texto plano, no puedo canalizar todo el disco a través de grep.

Cualquier sugerencia sería muy apreciada.

Además, si alguien tiene alguna idea de lo que podría haber salido mal, me encantaría escucharlo.

Gracias


1
Sería diferente si el archivo se eliminara accidentalmente o algo así, pero cuando se guarda en un editor de texto, etc. Hubiera sido mejor si no apagaras el sistema de inmediato, apuesto a que un par de presiones de control + z (función de "deshacer" incorporada en Open Office) habrían solucionado el problema.
Tim

@Tim Veo tu punto, pero desafortunadamente el archivo se había vaciado días antes. La última modificación en el archivo fue unos días antes. En mi descripción, cuando la abrió en OO, ya estaba vacía. Gracias sin embargo.
jcbwlkr

2
No trato de vencer a un caballo muerto o patear a un hombre cuando está caído, pero sospecho que esta experiencia lo llevará a buscar una solución de respaldo. Eche un vistazo a "Areca Backup" para obtener una aplicación de respaldo simple y compatible con Linux.
Tim

¿Disco lleno quizás? Consulte condf -h
jippie

@Tim Si el archivo tiene 0 bytes, no es un documento OO; Ctrl+Zno habría hecho nada, ya que el archivo no se guardó como lo hace OO. @ Jacobwalker0814 Los archivos ODT son archivos zip, por lo que las herramientas de recuperación como testdisk tienen la posibilidad de encontrarlos; pero no hay garantía, e incluso si los datos aún están allí, es posible que tenga que pasar por muchos otros archivos zip. Y para el futuro, ¡retrocede!
Gilles 'SO- deja de ser malvado'

Respuestas:


3

Si está utilizando el sistema de archivos ext3, intente seguir el COMO de Carlo Wood

En pocas palabras,

  • Utilice ext3grep $ IMAGE --ls --inode 2 | grep your_file para encontrar el archivo que está buscando (donde $ IMAGE es su partición, por ejemplo / dev / sda2)
  • Encuentre el bloque del sistema de archivos que contiene el diario del espacio no asignado.
  • Encuentra todos los descriptores de diario que hacen referencia al bloque que se encontró anteriormente.
  • Copie el bloque con dd.
  • Edite el archivo para eliminar los ceros finales.
  • cat el archivo donde quieras

De la fuente:

"El capítulo Ejemplo de recuperación manual

En el siguiente ejemplo recuperaremos manualmente un pequeño archivo. Solo se proporciona una salida parcial para ahorrar espacio y hacer que el ejemplo sea más legible.

Usando ext3grep $ IMAGE --ls --inode encontramos el nombre del archivo que queremos recuperar:

$ ext3grep $ IMAGEN --ls --inode 2 | grep carlo 3 final d 195457 D 1202352103 jue 7 feb 03:41:43 2008 drwxr-xr-x carlo

$ ext3grep $ IMAGEN --ls --inode 195457 | grep 'bin $' | head -n 1 34 35 d 309540 D 1202352104 jue 7 feb 03:41:44 2008 drwxr-xr-x bin

$ ext3grep $ IMAGEN --ls --inode 309540 | grep start_azureus 9 10 r 309631 D 1202351093 jue 7 feb 03:24:53 2008 rrwxr-xr-x start_azureus

Obviamente, el inodo 309631 se borra y no tenemos números de bloque para este archivo:

$ ext3grep $ IMAGEN --print --inode 309631 [...] Inode es Grupo no asignado: 19 Id de generación: 2771183319 uid / gid: modo 1000/1000: rrwxr-xr-x tamaño: 0 número de enlaces: 0 sectores: 0 (-> 0 bloques indirectos).

Inode Times: Acceso: 1202350961 = Jue 7 de febrero 03:22:41 2008 Archivo modificado: 1202351093 = Jue 7 de febrero 03:24:53 2008 Inode modificado: 1202351093 = Jue 7 de febrero 03:24:53 2008 Tiempo de eliminación: 1202351093 = Jue 7 de febrero 03:24:53 2008

Bloques directos:

Por lo tanto, intentaremos buscar una copia anterior en el diario. Primero, encontramos el bloque del sistema de archivos que contiene este inodo:

$ ext3grep $ IMAGEN --inode-to-block 309631 | grep reside Inode 309631 reside en el bloque 622598 en el desplazamiento 0xf00.

Luego, encontramos todos los descriptores de revistas que hacen referencia al bloque 622598:

$ ext3grep $ IMAGE --journal --block 622598 [...] Descriptores de diario que hacen referencia al bloque 622598: 4381294 26582 4381311 28693 4381313 28809 4381314 28814 4381321 29308 4381348 30676 4381349 327188817171881871881871871871881871871871881881881871871881818818181881817081708171708181717081717 4382137 6672 4382138 7536 4382139 7984 4382140 8931

Esto significa que la transacción con el número de secuencia 4381294 tiene una copia del bloque 622598 en el bloque 26582, y así sucesivamente. El número de secuencia más grande, en la parte inferior, debe ser los últimos datos escritos en el disco y, por lo tanto, el bloque 8931 debe ser el mismo que el bloque actual 622598. Para encontrar la última copia no eliminada, uno debe comenzar en la parte inferior y trabajar hacia arriba.

Si intenta imprimir dicho bloque, ext3grep reconoce que es un bloque de una tabla de inodo e imprimirá el contenido de los 32 inodos en él. Sin embargo, solo deseamos ver el inodo 309631; entonces usamos un grep inteligente:

$ ext3grep $ IMAGEN --print --block 8931 | grep -A15 'Inode 309631' -------------- Inode 309631 ----------------------- Id de generación: 2771183319 uid / gid: modo 1000/1000: rrwxr-xr-x tamaño: 0 número de enlaces: 0 sectores: 0 (-> 0 bloques indirectos).

Inode Times: Acceso: 1202350961 = Jue 7 de febrero 03:22:41 2008 Archivo modificado: 1202351093 = Jue 7 de febrero 03:24:53 2008 Inode modificado: 1202351093 = Jue 7 de febrero 03:24:53 2008 Tiempo de eliminación: 1202351093 = Jue 7 de febrero 03:24:53 2008

Bloques directos:

De hecho, esto es lo mismo que vimos en el bloque 622598. A continuación, observamos números de secuencia más pequeños hasta que encontramos uno con un tiempo de eliminación 0. El primero que encontramos (de abajo hacia arriba) es el bloque 6073:

$ ext3grep $ IMAGEN --print --block 6073 | grep -A15 'Inode 309631' -------------- Inode 309631 ----------------------- Id de generación: 2771183319 uid / gid: modo 1000/1000: rrwxr-xr-x tamaño: 40 número de enlaces: 1 sectores: 8 (-> 0 bloques indirectos).

Inode Times: Acceso: 1202350961 = Jue 7 de febrero 03:22:41 2008 Archivo modificado: 1189688692 = Jue 13 de septiembre 15:04:52 2007 Inode modificado: 1189688692 = Jue 13 de septiembre 15:04:52 2007 Tiempo de eliminación: 0

Bloques directos: 645627

Lo anterior está automatizado y se puede hacer mucho más rápido con la opción de línea de comando --show-journal-inodes. Esta opción encontrará el bloque al que pertenece el inodo, luego buscará todas las copias de ese bloque en el diario, y posteriormente imprimirá solo el inodo solicitado de cada uno de estos bloques (cada uno de los cuales contiene 32 inodos, como usted sabe), eliminando duplicados :

$ ext3grep $ IMAGE --show-journal-inodes 309631 Número de grupos: 75 Bloque de diario mínimo / máximo: 1115/35026 Cargando descriptores de diario ... hecho La transacción de diario 4381435 se envuelve, algunos bloques de datos podrían haberse perdido de esta transacción. Número de descriptores en la revista: 30258; números de secuencia mín. / máx .: 4379495/4382264 Copias del inodo 309631 encontradas en la revista:

-------------- Inode 309631 ----------------------- Id de generación: 2771183319 uid / gid: 1000/1000 modo: rrwxr-xr-x tamaño: 0 número de enlaces: 0 sectores: 0 (-> 0 bloques indirectos).

Inode Times: Acceso: 1202350961 = Jue 7 de febrero 03:22:41 2008 Archivo modificado: 1202351093 = Jue 7 de febrero 03:24:53 2008 Inode modificado: 1202351093 = Jue 7 de febrero 03:24:53 2008 Tiempo de eliminación: 1202351093 = Jue 7 de febrero 03:24:53 2008

Bloques directos:

-------------- Inode 309631 ----------------------- Id de generación: 2771183319 uid / gid: 1000/1000 modo: rrwxr-xr-x tamaño: 40 número de enlaces: 1 sectores: 8 (-> 0 bloques indirectos).

Inode Times: Acceso: 1202350961 = Jue 7 de febrero 03:22:41 2008 Archivo modificado: 1189688692 = Jue 13 de septiembre 15:04:52 2007 Inode modificado: 1189688692 = Jue 13 de septiembre 15:04:52 2007 Tiempo de eliminación: 0

Bloques directos: 645627

El archivo es realmente pequeño: solo un bloque. Copiamos este bloque con dd como se muestra antes:

$ dd if = $ IMAGE bs = 4096 count = 1 skip = 645627 of = block.645627 1 + 0 registros en 1 + 0 registros 4096 bytes (4.1 kB) copiados, 0.0166104 segundos, 247 kB / s

y luego edite el archivo para eliminar los ceros finales, o copie los primeros 40 bytes (el tamaño dado del archivo):

$ dd if = block.645627 bs = 1 count = 40 of = start_azureus 40 + 0 registros en 40 + 0 registros 40 bytes (40 B) copiados, 0.000105397 segundos, 380 kB / s

$ cat start_azureus cd / usr / src / azureus / azureus ./azureus &

¡Recuperado!"


Me encantaría ver eso, pero el enlace parece estar muerto.
jcbwlkr

3
No me parece muerto.
Sr. Lister

Sí, yo también puedo acceder.
java_xof

Funciona bien ahora. Definitivamente no fue antes. ¿Quién sabe? Gracias java. Lo miraré
jcbwlkr

No hay problema, espero que esto te ayude, no te ofendas, pero sé algo sobre la interacción esposa <-> computadora;)
java_xof

2

Pruebe testdisk y photorec , pero la forma en que entiendo su escritura es probablemente la forma difícil de aprender el valor de las copias de seguridad regulares. También es posible que desee iniciar desde el CD para evitar que el disco duro se cambie aún más. Personalmente, me gusta System Rescue Disk para esto, pero se basa principalmente en la línea de comandos.


1

Utilice Caine, una distribución especial de Linux para análisis forense digital. Son muchas herramientas para la recuperación de archivos y discos duros.


Gracias. Revisaré esa distribución y veré si tiene algo. ¿Tiene alguna recomendación sobre herramientas específicas o formas de abordar el problema? El problema aquí es que el archivo no se eliminó, que muchas herramientas parecen abordar; simplemente perdió su contenido.
jcbwlkr

1
Open Office a veces crea un archivo oculto que contiene el documento guardado anterior. Si tiene suerte, puede intentar recuperarlo utilizando, por ejemplo, "extundelete" o "testdisk" cgsecurity.org/wiki/TestDisk
PsyStyle

Mire en ~ / .openoffice.org / 3 / user / backup / o ~ / .libreoffice.org / 3 / user / backup / Escribí un script para borrar estos directorios para que las cosas sensibles que eliminé aún no estuvieran allí.
Joe
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.