Unix / Linux recuperar / recuperar archivos borrados

124

¿Existe un comando para recuperar / recuperar archivos borrados rm?

$ rm -rf /path/to/myfile

¿Cómo me puedo recuperar myfile? Si existe tal herramienta, ¿cómo puedo usarla?

pylover
fuente
1
cyberciti.biz/tips/… puede ayudar. También es mejor en Stack Exchange .
fedorqui
1. Esto sería mejor para Unix y Linux 2. ¿Copias de seguridad?
1
Antes de hacer nada, monte el sistema de archivos de solo lectura para asegurarse de que los datos no se sobrescriban. Además, eche un vistazo a esta publicación: superuser.com/questions/170857/ext4-undelete-utilities .
1
@EvanTeitelman, ¿quiere decir que remontar solo lectura es mejor que intentar recuperar el archivo mientras está desmontado? por cierto, midnightcommander (mc), sugiere un montaje de datarecoverypros.com/recover-linux-midnightcommander.html
Aquarius Power
1
La mejor solución es pensar en el futuro y usar una herramienta de control de revisión.
ctrl-alt-delor

Respuestas:

66

El enlace que alguien proporcionó en los comentarios es probablemente su mejor oportunidad.

Hack de Linux debugfs: Recuperar archivos

Ese artículo, aunque parece un poco intimidante, es bastante sencillo de seguir. En general, los pasos son los siguientes:

  1. Use debugfs para ver un registro de sistemas de archivos

    $ debugfs -w /dev/mapper/wks01-root
    
  2. En el indicador de depuración

    debugfs: lsdel
    
  3. Salida de muestra

    Inode  Owner  Mode    Size    Blocks   Time deleted
    23601299      0 120777      3    1/   1 Tue Mar 13 16:17:30 2012
    7536655      0 120777      3    1/   1 Tue May  1 06:21:22 2012
    2 deleted inodes found.
    
  4. Ejecute el comando en debugfs

    debugfs: logdump -i <7536655>
    
  5. Determinar archivos inode

    ...
    ...
    ....
    output truncated
        Fast_link_dest: bin
        Blocks:  (0+1): 7235938
      FS block 7536642 logged at sequence 38402086, journal block 26711
        (inode block for inode 7536655):
        Inode: 7536655   Type: symlink        Mode:  0777   Flags: 0x0   Generation: 3532221116
        User:     0   Group:     0   Size: 3
        File ACL: 0    Directory ACL: 0
        Links: 0   Blockcount: 0
        Fragment:  Address: 0    Number: 0    Size: 0
        ctime: 0x4f9fc732 -- Tue May  1 06:21:22 2012
        atime: 0x4f9fc730 -- Tue May  1 06:21:20 2012
        mtime: 0x4f9fc72f -- Tue May  1 06:21:19 2012
        dtime: 0x4f9fc732 -- Tue May  1 06:21:22 2012
        Fast_link_dest: bin
        Blocks:  (0+1): 7235938
    No magic number at block 28053: end of journal.
    
  6. Con la información de inodo anterior, ejecute los siguientes comandos

    # dd if=/dev/mapper/wks01-root of=recovered.file.001 bs=4096 count=1 skip=7235938
    # file recovered.file.001
    file: ASCII text, with very long lines
    

Archivos recuperados a recovered.file.001.

Otras opciones

Si lo anterior no es para ti, he usado herramientas como photorecrecuperar archivos en el pasado, pero está orientado solo a archivos de imagen. He escrito mucho sobre este método en mi blog en este artículo titulado:

Cómo recuperar archivos corruptos jpeg y mov de la tarjeta SDD de una cámara digital en Fedora / CentOS / RHEL .

slm
fuente
11
Lo intenté con debugfs -w /dev/sdb2pero lsdel0 deleted inodes found.
dijo
55
usar extundeletees más fácil para ext3 / 4 y probablemente conduciría a los mismos resultados.
eadmaster
1
esto funcionó para recuperar un archivo, pero recibí @ y U T6 Ԝ * e 0 v' T 0 <#selinuxsystem_u: object_r: rpm_var_lib_t: s0 } y U T6 ..... probar conv = ascii, conv = ibm y conv = ebcdic produce el mismo problema
codyc4321
2
lsdel: El sistema de archivos no está abierto, ¿cómo resolverlo?
Amitābha
3
Entiendo /dev/mapper/wks01-root: No such file or directory while opening filesystem¿De dónde sacaste esto /dev/mapper/wks01-root?
Marko Avlijaš
29

Con un poco de posibilidades, a veces puedo recuperar archivos borrados con este script o la siguiente solución en la respuesta:

#!/bin/bash

if [[ ! $1 ]]; then
    echo -e "Usage:\n\n\t$0 'file name'"
    exit 1
fi

f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep "$1 (deleted" | awk '{print $9}')

if [[ $f ]]; then
    echo "fd $f found..."
    cp -v "$f" "$1"
else
    echo >&2 "No fd found..."
    exit 2
fi

Hay otro truco útil: si conoce un patrón en sus archivos eliminados, escriba alt+ sys+ resuopara reiniciar + volver a montar en solo lectura, luego con un live-cd, use greppara buscar en el disco duro:

grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover

luego edite /tmp/recoverpara conservar solo los archivos que tenía antes.

Oye, si con la filosofía de Unix todo son archivos, es hora de aprovechar esto, ¿no?

Gilles Quenot
fuente
55
Su grepsolución basada es muy inteligente y funcionó para mí, incluso con el sistema de archivos aún montado. ¡Gracias!
wchargin
No entiendo cómo la solución grep funcionó para usted, solo genera datos binarios. ¿Cómo es eso útil?
w00t
2
@ w00t Claro, "solo" escupe datos binarios. Pero a veces esos datos binarios contienen los bits ASCII correspondientes al archivo que estoy buscando. ¿Supongo que no entiendo la pregunta?
wchargin
@ w00t el truco es usar un patrón de búsqueda que sea muy específico para ese archivo. El comando grep tomará las 500 líneas antes y después de cada línea coincidente, por lo que aún escupirá una gran cantidad de datos irrelevantes, pero con un editor de texto que puede hacer frente a eso (por ejemplo, Vim), es fácil separar lo bueno de las cosas malas También puede filtrar todas las líneas con caracteres no imprimibles grep -av "[^[:print:]]"
canalizándolas a
La grepsolución funcionó para mí con una modificación: lo hice sudo grep --line-buffered -ab "$PATTERN" /dev/sda1 | tee linesy obtuve compensaciones de bytes (como 123123123:line\n456456456:another\n...), luego lo hice n=1000; sudo dd of=before if=/dev/sda1 ibs=1 skip=$[123123123-$n] count=$ny n=1000; sudo dd of=after if=/dev/sda1 ibs=1 skip=123123123 count=$ncon diferentes nvalores.
Kirill Bulygin
21

Lo que funcionó para mí fue dada por arco (sólo se aplica a archivos de texto):

grep -a -C 200 -F 'Unique string in text file' /dev/sdXN

donde /dev/sdXNestá la partición que contiene el archivo perdido (verifique mountsi no está seguro).

¡Toma un poco de tiempo, pero funcionó cuando borré accidentalmente un código fuente que aún no había confirmado!

William Becker
fuente
44
Muy útil para programadores! por lo general, siempre perdimos nuestros propios códigos.
pylover
1
cuéntame, accidentalmente corrí en rm data/*.json python myFile.pylugar derm data/*.json && python myFile.py
William Becker
2
Gracias amigo, me ayudaste a recuperar un archivo de texto que pasé 2 horas escribiendo por la noche. PS /dev/sdXNes para el sistema de archivos, ¿verdad? Encontré la mía condf -T | awk '{print $1,$2,$NF}' | grep "^/dev"
Alex
Solo veo el binario del archivo. ¿Hay alguna forma de convertirlo a formato normal?
silgon
grep: conflicting matchers specified
Felwithe
10

Aunque esta pregunta está resuelta y tiene algunos años, quiero mencionar la utilidad testdisk .

Cómo recuperar archivos con testdisk se explica bien en este tutorial . Para recuperar archivos, ejecute testdisk /dev/sdXy seleccione su tipo de tabla de particiones. Después de esto, seleccione [ Advanced ] Filesystem Utils, luego elija su partición y seleccione [Undelete]. Ahora puede explorar y seleccionar archivos eliminados y copiarlos a otra ubicación en su sistema de archivos.

S. Wilhelm
fuente
No ve mi / dev / nvme0n1p2
h22
6

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. La sintaxis 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 es un mini tutorial que puede ayudarte.

Juan
fuente
6

Se puede usar una alternativa en dellugar de rmeliminar:

http://fex.belwue.de/fstools/del.html

del tiene una función de recuperación y funciona con cualquier sistema de archivos.

Por supuesto, no es una solución si ya ha eliminado sus archivos con "no tomar prisioneros" rm: -}

Framstag
fuente
1
No es una respuesta como ya ha dicho, pero gracias por introducir el del comando.
pylover
5

conectar la unidad a través de la interfaz externa

  1. montar
  2. umount /dev/{sd*}
  3. extundelete --restore-all /dev/{sd*}
  4. los resultados van a la carpeta de inicio en la unidad de arranque
  5. puntos de bonificación: escriba una GUI para esto

Consulte este enlace para obtener más información: recuperar un archivo recién eliminado en ext4 con extundelete .

GRZ
fuente
2
Votantes, explique por qué cree que extundelete no es una buena opción.
webminal.org
2
¡Agradable! Gracias por publicar. extundelete es una nueva herramienta para mí. Usé esto hoy y lo encontré extremadamente útil. OMI mucho más útil que la respuesta aceptada. Las únicas cosas que agregaría a esta respuesta para mejorarla levemente son (1) reiterar las instrucciones en algunas otras respuestas de que uno debe apagar la computadora afectada tan pronto como se dé cuenta de que los archivos se eliminaron por error y (2) arranque desde un liveCD o liveUSB OS como Kali Linux que incluye la utilidad extundelete (descubrí que muchos otros liveCD como Debian Jessie no incluyen esta utilidad en sus medios de instalación).
Osteoboon
4

Herramientas de recuperación - Línea de comando:

Herramientas de recuperación - Gui:

Informaciones:

En mi experiencia personal, recupero mis datos utilizando ufs-explorer y photorec

(1) = No es de código abierto, no es gratis

(2) = No es de código abierto, gratis

(3) = Código abierto y gratuito

(4) = Tener soporte ntfs

(5) = Tiene función de estructura de directorio

intika
fuente
1

No estoy de acuerdo con que sea imposible, simplemente muy, muy difícil, y tampoco lo he hecho desde Linux:

Cuando se eliminan los archivos, en realidad no se eliminan. Lo que sucede es que el espacio que tenían en el disco duro se reinicia, de modo que si la computadora intenta escribir datos allí, nada se queja. En general, los datos en su disco duro que pensó que eliminó pueden estar allí casi un año después. O al menos, esta es mi experiencia en una máquina con Windows. Si funciona o no de la misma manera desde una línea de comandos en Linux, no estoy seguro, pero es probable que necesite un Live CD por separado para abrir la partición así, y tampoco hay garantía de que los archivos sigan allí. He hecho esto en Windows XP varias veces usando Zero Assumption Recovery. Estoy seguro de que hay una herramienta similar si te fijas lo suficiente.

Roguebantha
fuente
Dependiendo de la situación, puede ser 100% imposible. Puede o no funcionar, pero NUNCA tienes ninguna garantía.
klutt
0

Cuando elimina un archivo, el recuento de enlaces en la tabla de inodo para ese archivo disminuye en uno. En Unix, cuando el recuento de enlaces cae a 0, los bloques de datos para ese archivo se marcan como libres y, por lo general, se pierden referencias a esos bloques de datos. Acabo de descubrir por el comentario de @ fedorqui que puede haber alguna forma de acceder a esos bloques, pero eso solo es aplicable al sistema de archivos ext3.

Una forma de preservar los archivos será escribir una función que le permita mover los archivos a un área de basura (digamos $HOME/.trash) y recuperar los archivos necesarios desde allí. Esta función puede ser alias rm. Puede programar un trabajo cron para eliminar los archivos que han estado en el área de la papelera durante un cierto número de días.

unxnut
fuente
0

Esto podría ahorrarles problemas a algunos de ustedes.
Si alguna vez usó gedit para editar ese archivo, por defecto se creará una copia de ese archivo.
Por ejemplo, supongamos que hemos eliminado accidentalmente 'myfile.txt'.
En la carpeta que solía contener el archivo que acaba de eliminar, use estos comandos y recuperará la copia desde allí:
ls | grep 'myfile.txt~'
con un poco de suerte lo encontrará y luego:
cp 'myfile.txt~' 'myfile.txt'
He recuperado un archivo ahora mismo usando este método. ¡La mejor de las suertes!

ntt
fuente