¿Cómo recuperar un archivo eliminado en Linux?


65

Por accidente, utilicé rmun archivo que no quería eliminar. ¿Hay alguna manera de recuperarlo en Linux?


@Nav, rmes un comando "peligroso" de UNIX / Linux (leer $ man rm). Úselo con extrema precaución . Dicho esto, es una forma rápida de eliminar archivos de los que está seguro. Los entornos de escritorio modernos de Linux y Unix proporcionan una solución de "bote de basura" , por lo que el usuario puede recuperar fácilmente archivos borrados accidentalmente.
Jose Elera

1
algunas respuestas más actualizadas: unix.stackexchange.com/questions/122305/…
Ben Crowell

No use "rm" si desea restaurar los archivos en el futuro. Utilice la utilidad "rm-trash" en su lugar: github.com/nateshmbhat/rm-trash
Natesh bhat

Respuestas:


51

Los siguientes son pasos genéricos para recuperar archivos de texto.

  1. Primero use el comando wall para decirle al usuario que el sistema se está cayendo en un modo de usuario único:

    # wall
    System is going down to .... please save your work.
    

    Presione CTRL + D para enviar el mensaje.

  2. Luego use el comando init 1 para llevar el sistema a un modo de usuario único:

    # init 1
    
  3. Usando grep (forma UNIX tradicional) para recuperar archivos

    Utilice la siguiente sintaxis grep:

    grep -b 'search-text' /dev/partition > file.txt
    

    O

    grep -a -B[size before] -A[size after] 'text' /dev/[your_partition] > file.txt
    

    Dónde,

    -i : Ignore case distinctions in both the PATTERN and the input files i.e. match both uppercase and lowercase character.
    -a : Process a binary file as if it were text
    -B Print number lines/size of leading context before matching lines.
    -A: Print number lines/size of trailing context after matching lines.
    

    Para recuperar el archivo de texto que comienza con la palabra "nixCraft" en / dev / sda1, puede intentar el siguiente comando:

    # grep -i -a -B10 -A100 'nixCraft' /dev/sda1 > file.txt
    
  4. Luego use vi para ver file.txt.

    Este método SOLO es útil si el archivo eliminado es un archivo de texto. Si está utilizando el sistema de archivos ext2, pruebe el comando de recuperación.

Encontrado en http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html


16
Vale la pena señalar que NO PUEDE HACER ESTE MANDO A DISTANCIA, el modo de usuario único apaga las redes
Quinma

1
Este método funciona de maravilla para archivos de texto, ¡gracias! Lo que me gusta es que no se basa en el diario del sistema de archivos (como extundelete), sino que en realidad escanea los bytes sin formato de toda la unidad. Si este comando no encuentra su archivo, nada lo hará.
Benjamin B.

1
@Quinma, este método puede funcionar de forma remota con solo pequeñas modificaciones ... En lugar de ejecutarse init 1, elimine manualmente todos los demonios del sistema, excepto sshd. También creo que en este punto debería volver a montar todos los sistemas de archivos RO y guardarlos en tmpfs (suponiendo que sus archivos temporales encajen en la memoria RAM) para evitar sobrescribir los archivos con los datos temporales. Por supuesto, tendrá que copiarlo en otro lugar más tarde, ya sea a un servidor remoto o volver a los sistemas de archivos locales después de volver a montarlos RW.
Thomas Guyot-Sionnest

¿Cuál es tu partición? Tengo un error: / dev / sda1: No
existe

1
@Qback, realmente no lo sé. Como se dijo, solo seguí el paso a paso. Pero el init 1 está destinado a tareas administrativas, y quizás elimine el proceso no relacionado con ese escenario de nivel de ejecución. Eso puede ayudar a evitar que se use el disco duro, sobrescribiendo el archivo que está intentando recuperar.
Gabriel L. Oliveira

13
  • Si es muy, muy importante, toma el disco de la computadora y contrata a una empresa para que lo haga por ti.
  • Si solo es muy importante, monte el disco de solo lectura, copie la partición completa a un archivo usando dde intente encontrar el archivo dentro de él (usando grep, o un editor).

Editar: a veces ddrescuefunciona mejor que dd.


1
"tratar de encontrar el archivo que contiene" Estoy confundido, ¿cómo se podría abrir razonablemente un archivo de más de 15 GB y buscar o canalizar esta bestia en grep? ¿Y qué harías cuando encontraras el texto? ¿Cómo demonios es esta recuperación?
TheLQ

1
Lo primero que debe hacer es probar algunas herramientas comunes antes de quemar mucho efectivo para obtener un resultado incierto. Por cierto, grep realmente no ayudará, photorec o ext3grep lo harán.
wazoox



5
  • La única respuesta correcta es: restaurar su archivo desde la copia de seguridad. Todos deben tener una copia de seguridad. Para archivos realmente importantes, debe tener dos copias de seguridad. Usted no? Bueno, lástima, aquí hay una lección aprendida (Perdón por sonar duro, pero estoy en el almacenamiento de datos, y las personas no retroceden hasta que pierden algunos datos importantes, eso es un hecho. Entonces sí, pareces estúpido, pero así es casi todos los demás).

  • OK, no tienes respaldo. debe dejar de usar el sistema de archivos que contenía el archivo AHORA MISMO . Cualquier actividad de escritura definitivamente puede manipular los datos del archivo que pueden (solo pueden ) permanecer en el disco.

  • Si cometió el trágico error de usar solo una partición como sistema de archivos raíz y / home, eso significa que debe arrancar desde otro dispositivo. EMPRESA .

  • Si su archivo tiene algún formato común (archivo de Word, JPG, etc.), use Photorec . Photorec puede recuperar los formatos de archivo más comunes.

  • Puede probar el método "ext3 undelete" propuesto anteriormente, pero debe sentirse cómodo con la línea de comandos, comprender el funcionamiento interno básico de Linux, etc.

  • Si su archivo es de algún formato especial, mala suerte. Una vez escribí un programa Perl para escanear una unidad en busca de algunos archivos especiales, y funcionó bastante bien; pero necesitará saber algo de programación para hacerlo, y también estar bastante a gusto con Linux.


5

Lo hice hace un par de años. Mi enfoque fue directamente, sin tiempo que perder, desmontar la partición y luego

dd if=/dev/hda1 of=backup_image.ext3

tener un archivo de copia de seguridad del estado exacto de la partición. Luego, puede volver a montar la partición y continuar con los negocios de la forma habitual mientras busca el archivo eliminado en la imagen creada. La imagen probablemente será MUY grande ya que necesita todo el espacio "vacío", por lo que podría ser un problema práctico almacenarla.

Luego fue solo para realizar búsquedas aburridas después de fragmentos de texto que esperaba estar en algún lugar de la sopa de contenido de partición. Por ejemplo, para encontrar archivos .tex, ejecuté

grep --binary-files=text -1000 "subsection" < backup_image.ext3 > latexfiles

que imprimió un gran contexto alrededor de la frase "subsección" y guardó el resultado en un archivo para buscarlo manualmente. Imprimí un contexto tan grande, ya que me tomó tanto tiempo buscar la imagen que preferiría no hacerlo más veces de lo necesario.

Además, el comando stringsfue útil para eliminar la basura binaria de la salida, pero si recuerdo correctamente, también eliminó todas las líneas nuevas, lo que podría ser un problema.

Para encontrar archivos binarios de la misma manera, uno podría tener éxito en encontrar un encabezado característico o algo de cierto archivo, pero imagino que será una gran aventura.


Breves notas técnicas: existen dificultades técnicas con la recuperación de disco y Ext3 / 4. Es algo largo de explicar, pero brevemente (e inadecuadamente): Ext3 / 4 elimina los "marcadores" que le dicen al sistema operativo dónde se encuentran los archivos en el disco cuando los elimina. Los archivos no se eliminan, pero ya nadie sabe en qué parte del disco comienzan y terminan, y a veces incluso están fragmentados en varios lugares. Algunos otros sistemas de archivos simplemente establecen los estados de los archivos en "eliminados", pero mantienen los datos de ubicación. Luego, recuperar no es más difícil que mirar los punteros de archivo con este indicador (aún deberían estar disponibles si no se ha producido demasiada actividad), y luego esperar que su contenido no se haya sobrescrito.

¿Qué es lo mejor? Retórica, en mi opinión. La copia de seguridad frecuente es la respuesta a todos estos problemas. Datos importantes sin un sistema de respaldo automatizado es un accidente esperando a ocurrir, en mi humilde opinión.


Anécdota personal obligatoria: iba a eliminar foo\ foo*de ~. escribí

rm -r foo<Tab>*

, que lamentablemente, dado que fooaparentemente era un enlace simbólico y el único archivo que coincidía con esto, el shell se convirtió en

rm -r foo\ foo *

Presioné Enter y me senté allí mirando el comando, que debería haber tomado un segundo como máximo. Después de un poco más de tiempo rmme preguntó si quería "eliminar el archivo protegido contra escritura 'algo'". Rápidamente sentí los escalofríos y presioné suavemente y muy controlado Ctrl+c. ~ La mitad de mi ~fue eliminada, pero logré recuperar todo el valor a través del grepping descrito anteriormente y algunas copias de seguridad más o menos actuales. Tenía algunos datos de medición personalmente muy valiosos (léase: mucho tiempo) y muy recientes en el disco que se perdieron, pero había hecho copias de seguridad cuádruples. Uno desapareció aquí, otro debido a la interrupción del sistema en la escuela, otro estaba corrupto y al principio no pude encontrar el cuarto, ya que por error lo había colocado en la carpeta incorrecta :-D. No harm -rse atascó en un archivo protegido contra escritura, el cuarto se habría comido desde que esa carpeta se montó a través de sshfs en mi ~. Desde entonces tengo mucho más cuidado con ese tipo de cosas.


5

Si es el rm estándar , espero que tenga una copia de seguridad. El procedimiento para recuperar un archivo eliminado sería diferente para cada sistema de archivos, si es que se puede hacer. Linux no tiene una "papelera de reciclaje" incorporada; una vez que eliminas un archivo, todo desaparece.

De cualquier forma que lo haga, querrá desconectar la computadora, tan pronto como sea posible, ya que continuar ejecutando la computadora (incluso para apagarla) provoca escrituras en el disco y aumenta la posibilidad de que algunos bloques que anteriormente ocupaban el archivo se sobrescribirá. Una vez que haya hecho eso, colóquelo en otra computadora, reinicie desde un CD en vivo (asegurándose de no montar la unidad a menos que lo monte como de solo lectura) o retire el disco duro y llévelo a un especialista en recuperación de datos.


4

Establezca sus expectativas bajas. Si se escribió algo sobre los datos 'eliminados', lo perderá.

He realizado una pequeña cantidad de recuperación y las mejores herramientas que encontré a menudo fueron diseñadas para ciertos formatos. Por ejemplo, 'photorec' fue genial cuando quería recuperar decenas de miles de archivos JPEG.

Recuva también me ha ayudado antes y podría ser su mejor opción. (Es gratis, no se deje engañar por pagar con sus anuncios)

Al final del día, si lo que perdió es importante, desconecte el disco y deje de escribir en él. Use cada pieza de software de recuperación que pueda encontrar hasta que recupere sus datos o deje de valer la pena. Si es realmente importante, envíelo a profesionales a un alto precio.

Si ha tenido suerte con una herramienta antes, vuelva a intentarlo ya que está familiarizado con ella. Al final del día, no deberían estar escribiendo en el disco, por lo que puede usar el software hasta que encuentre uno que funcione.


2

Aquí hay un gran documento para ti. Encontrará un montón de consejos prácticos allí.

Por cierto, hay dos grupos de personas:

  1. los que hacen copias de seguridad
  2. aquellos que harán copias de seguridad

Felicidades, acabas de ascender al grupo 2. ;-)


2

Si tiene una aplicación abierta que actualmente está leyendo el archivo, como VLC o LibreOffice, entonces esta excelente respuesta de L & U.SO me ayudó a salir de este lío. Aquí hay un método alternativo para hacer lo mismo.

La idea general es encontrar el enlace /proc/PID/fd/DESCRIPTOR_NUMBERy copiarlo nuevamente en su ubicación original. Use ps aux | grep APP_NAMEpara encontrar el PID y luego ls -la /proc/PID/fd/para encontrar el DESCRIPTOR_NUMBER adecuado.


1

La respuesta "correcta" es asumir que no hay un método para recuperar de manera confiable, y en su lugar restaurar desde copias de seguridad o un sistema clonado o reinstalar.

TestDisk es una gran herramienta, y hay otras formas de poder recuperar algunos datos del disco físico dependiendo del sistema de archivos y la antigüedad de la eliminación, pero el tiempo y el dolor involucrados pueden ser demasiado grandes, así que MANTENGA LAS COPIAS DE SEGURIDAD (y también pruebe que son válidos y restaurables)!


1

Si no es sobrescrito por otros usuarios, entonces tienes suerte. Accidentalmente eliminé mi archivo fuente cpp y utilicé una herramienta llamada foremost , que me ayudó a restaurar los escombros cpp 60G del disco. Finalmente, recuperé mi archivo ensamblando esos escombros pieza por pieza. ¡Creo que escanea cierto patrón para un tipo de archivo específico y atraviesa todos los inodos en el disco para recuperar archivos! ¡Solo inténtalo!


0

Si accidentalmente ha eliminado el archivo de Linux, puede usar este comando:

find /root -name "search text" -type f  -exec mv {} "/home" \;

en lugar de search textusted puede poner el nombre del archivo y puede especificar el directorio donde desea restaurar en lugar de /home.


2
Hola santosh No agregue enlaces engañosos a sus publicaciones. Ha sido eliminado.
ᔕᖺᘎᕊ

0

Puedes probar este script. Funciona bien y está destinado a ser usado en lugar de rm y lo estoy usando ampliamente ahora.

https://github.com/nateshmbhat/safe-rm

Caracteristicas :

  • destinado a ser utilizado en lugar de rm
  • maneja todos los argumentos que rm puede tomar
  • maneja las colisiones de nombre de archivo con los archivos que ya están en la papelera
  • maneja algunos problemas de permisos automáticamente
  • si se llama a rm desde cualquier otro script o indirectamente, el comando 'rm' del sistema se usa automáticamente
  • muestra los mensajes de error apropiados como los que surgen en rm

-2

Tuve el mismo problema la semana pasada y probé muchos programas, como debugfs, photorec, ext3grep y extundelete. ext3grep fue el mejor programa para recuperar archivos. El sintax es muy fácil:

ext3grep image.img --restore-all

o:

ext3grep /dev/sda3 --restore-all --after date -d '2015-01-01 00:00:00' '+%s' --before `date -d ‘2015-01-02 00:00:00’ ‘+%s’

Este video muestra es un mini tutorial que puede ayudarlo.

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.