No estoy hablando de recuperar archivos borrados , sino de archivos sobrescritos . A saber por los siguientes métodos:
# move
mv new_file old_file
# copy
cp new_file old_file
# edit
vi existing_file
> D
> i new_content
> :x
¿Es posible recuperar algo si alguna de las tres acciones anteriores se realiza suponiendo que no hay programas especiales instalados en la máquina Linux?
data-recovery
ext4
Desbordamiento de preguntas
fuente
fuente
mv
) es similar a eliminarold_file
, no sobrescribir, por lo que los métodos (si existen) para recuperar archivos eliminados, a diferencia de los archivos sobrescritos, se aplicarían en ese caso. Sus otros dos ejemplos de hecho sobrescriben un existenteold_file
yexisting_file
, respectivamente.mv
es diferente.Respuestas:
La respuesta es "Probablemente sí, pero depende del tipo de sistema de archivos y el momento".
Ninguno de esos tres ejemplos sobrescribirá los bloques de datos físicos del archivo antiguo o el archivo existente, excepto por casualidad.
mv new_file old_file
. Esto desvinculará old_file. Si hay enlaces duros adicionales a old_file, los bloques permanecerán sin cambios en los enlaces restantes. De lo contrario, los bloques generalmente (depende del tipo de sistema de archivos) se colocarán en una lista libre. Luego, si semv
requiere copiar (en lugar de solo mover las entradas del directorio), los nuevos bloques se asignarán comomv
escrituras.Estos bloques recién asignados pueden o no ser los mismos que fueron liberados . En sistemas de archivos como UFS , los bloques se asignan, si es posible, desde el mismo grupo de cilindros que el directorio en el que se creó el archivo. Por lo tanto, existe la posibilidad de que desvincular un archivo de un directorio y crear un archivo en ese mismo directorio se reutilice ( y sobrescribir) algunos de los mismos bloques que acaban de liberarse. Es por eso que el consejo estándar para las personas que eliminan accidentalmente un archivo es que no escriban datos nuevos en los archivos de su árbol de directorios (y preferiblemente no en todo el sistema de archivos) hasta que alguien pueda intentar la recuperación del archivo.
cp new_file old_file
hará lo siguiente (puede usarstrace
para ver las llamadas al sistema):El indicador O_TRUNC hará que se liberen todos los bloques de datos, tal como se
mv
hizo anteriormente. Y como se indicó anteriormente, generalmente se agregarán a una lista gratuita, y pueden o no ser reutilizados por las escrituras posteriores realizadas por elcp
comando.vi existing_file
. Sivi
es realmentevim
, el:x
comando hace lo siguiente:Por lo tanto, ni siquiera elimina los datos antiguos; Los datos se conservan en un archivo de copia de seguridad.
En FreeBSD,
vi
doesopen("existing_file",O_WRONLY|O_CREAT|O_TRUNC, 0664)
, que tendrá la misma semántica que lacp
anterior.Puede recuperar algunos o todos los datos sin programas especiales; todo lo que necesita es
grep
ydd
, y acceso al dispositivo sin formato.Para archivos de texto pequeños, el
grep
comando único en la respuesta de @Steven D en la pregunta a la que se vinculó es la forma más fácil:Pero para archivos más grandes que pueden estar en múltiples bloques no contiguos, hago esto:
que le dará el desplazamiento en bytes de la línea correspondiente. Siga esto con una serie de
dd
comandos, comenzando conTambién querrás leer algunos bloques antes y después de ese bloque. En UFS, los bloques de archivos generalmente son de 8 KB y generalmente se asignan de manera bastante contigua, los bloques de un solo archivo se intercalan alternativamente con bloques de 8 KB de otros archivos o espacio libre. La cola de un archivo en UFS tiene hasta 7 fragmentos de 1 KB, que pueden ser contiguos o no.
Por supuesto, en los sistemas de archivos que comprimen o encriptan datos, la recuperación podría no ser tan sencilla.
En realidad, hay muy pocas utilidades en Unix que sobrescriban los bloques de datos de un archivo existente. Uno que viene a la mente es
dd conv=notrunc
. Otro esshred
.fuente
btrfs
es bastante resistente a los archivos eliminados. Tiende a usar bloques de forma circular, por lo que si tiene suficiente espacio en el dispositivo, el archivo no se sobrescribirá durante mucho tiempo. Ver aquískip=
parámetro, en lugar de leerlo desde el principio de la entrada, omitirá ese número de bloques. Un bloque tiene 512 bytes por defecto, pero se puede cambiar con elbs=
parámetro.skip=
valor que sea 1 bloque (512 bytes) menos. En mi ejemplo$(expr 13813610612 / 512 - 1)
,. Si eso no obtiene lo que desea, intente nuevamente mientras resta 16 o 32, que examinará las áreas que son 8192 y 16384 bytes menos; los archivos a menudo se asignan en fragmentos de 8192 bytes. Si está intentando recuperar un archivo más grande, intente conteos más grandes para ahorrar tiempo. Usualmente usocount=16
y miro el resultado en un editor como elemacs
que no le importa si algunos de los datos no son texto.Voy a decir que no (con un asterisco gigante).
Piense en cómo se almacenan los datos en un disco. Tiene bloques que contienen datos y apuntan al siguiente bloque (si hay uno).
Cuando sobrescribe datos, está cambiando el contenido del bloque (y si está extendiendo el archivo todo el marcador final). Por lo tanto, nada debería poder recuperarse (ver más abajo).
Si acorta el archivo, está perdiendo los bloques antiguos y pronto se reciclarán. Si usted es un programador, piense en una lista vinculada en la que "pierde" la mitad de su lista sin hacer una descarga / eliminación gratuita. Esa información todavía está ahí, pero buena suerte para encontrarla.
Algo que puede ser interesante pensar es la fragmentación.
La fragmentación se produce cuando tiene "agujeros" de datos no contiguos en su disco. Esto puede deberse a la modificación de archivos de modo que los extienda o acorte y ya no quepan en su lugar original en el disco.
En el caso de que un archivo crezca más allá de su tamaño original (necesita moverse en este punto), dependiendo de su sistema de archivos, puede copiar todo el archivo a una nueva ubicación donde los datos antiguos aún estarían allí (pero marcados como libres) o simplemente cambia el puntero final anterior y hace que apunte a una nueva ubicación (esto provocará una paliza).
En resumen, sus datos probablemente se pierdan (sin pasar por un proceso forense extremo en el que los mira bajo un microscopio); Sin embargo, existe la posibilidad de que todavía esté allí.
fuente
ext4
oxfs
está en uso. Con copia en sistemas de archivos de escritura comozfs
ybtrfs
, de hecho, nunca está "cambiando el contenido del bloque"; esos sistemas de archivos siempre usan bloques nuevos para contener nuevos datos. Además, los sistemas de archivos basados en registros comojffs2
siempre también escriben datos nuevos en nuevas ubicaciones (no "bloques", esos sistemas de archivos no están basados en bloques). Dicho esto, esto no significa que sea fácil encontrar dónde viven los datos antiguos y hacerlo antes de reciclar el espacio. Entonces su respuesta, que es no, sigue siendo correctaAsegúrese de tener suficiente espacio en disco en / var / tmp o en algún lugar grande.
Tratar
donde / dev / sda1 sería su disco en su sistema.
Luego busque mi archivo recuperado para su cadena.
En su mayoría, puede estar allí. Si lo encuentra, compruebe si faltan espacios de líneas, corchetes, símbolos, etc.
Use una palabra de búsqueda de su archivo que sea bastante única o una cadena que reducirá la cantidad de datos en el archivo. Si busca una palabra como "echo", obtendrá muchas cadenas, ya que el sistema tendrá muchos archivos con la palabra echo en ellas.
fuente
Había sobrescrito un archivo de texto (VQ1.txt) con 12 horas de datos de prueba :( Una noción de que Unix guarda la versión anterior del archivo en formato text.txt ~, me hizo buscar en la carpeta que contiene el archivo sobrescrito con $ -ll Full ¡La lista mostró VQ1.txt ~ que tenía mis datos 'perdidos'!
fuente
TL; DR: si el archivo sobrescrito aún se mantiene abierto por un proceso en ejecución, entonces esta publicación de blog podría guardar su tocino:
https://www.linux.com/news/bring-back-deleted-files-lsof/
En él, habla de archivos eliminados , pero tuve buena suerte incluso con un archivo que fue sobrescrito por rsync. Y estoy hablando de un archivo de 60 GB sobrescrito por uno de 4 MB, y pude recuperar el original porque afortunadamente no había detenido el proceso de ejecución que lo mantenía abierto.
fuente