Acabo de "mv" editar un directorio de 49 GB en una ruta de archivo incorrecta, ¿es posible restaurar el estado original de los archivos?

Question

tengo (bueno, yotenía) un directorio:

/media/admin/my_data

Tenía un tamaño aproximado de 49 GB y contenía decenas de miles de archivos. El directorio es el punto de montaje de una partición LUKS activa.

Quería cambiar el nombre del directorio a:

/media/admin/my_data_on_60GB_partition

No me di cuenta en ese momento, pero emití el comando desde el directorio de inicio y terminé haciendo:

~% sudo mv /media/admin/my_data my_data_on_60GB_partition

Entonces el mvprograma comenzó a moverse /media/admin/my_datay su contenido a un nuevo directorio ~/my_data_on_60GB_partition.

Utilicé Ctrl+ Cpara cancelar el comando a mitad de camino, así que ahora tengo un montón de archivos divididos en directorios:

~/my_data_on_60GB_partition    <---  about 2GB worth files in here

y

/media/admin/my_data           <---- about 47GB of orig files in here    

El nuevo directorio ~/my_data_on_60GB_partitiony algunos de sus subdirectorios son propiedad del root.
Supongo que el mvprograma debe haber copiado los archivos como root inicialmente y luego, después de la transferencia, chownlos devolvió a mi cuenta de usuario.

Tengo una copia de seguridad algo antigua del directorio/partición.
Mi pregunta es,¿Es posible restaurar de manera confiable el conjunto de archivos que se movieron?

Es decir, ¿puedo simplemente ejecutar:

sudo mv ~/my_data_on_60GB_partition/*  /media/admin/my_data

¿O debería dejar de intentar recuperarlos, ya que es posible que los archivos estén dañados y parcialmente completos, etc.?

• Sistema operativo: Ubuntu 16.04

mv --version  
mv (GNU coreutils) 8.25

Answer 1

Al mover archivos entre sistemas de archivos, mvno elimina un archivo antes de terminar de copiarlo y procesa los archivos secuencialmente (inicialmente dije que copia y luego elimina cada archivo por turno, pero eso no está garantizado; al menos GNU mvcopia y luego elimina cada uno) .argumento de línea de comandoa su vez, yPOSIX especifica este comportamiento). Por lo tanto, debería tener como máximo un archivo incompleto en el directorio de destino y el original seguirá estando en el directorio de origen.

Para retroceder las cosas, agregue la -ibandera para mvno sobrescribir nada:

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

(suponiendo que no tiene ningún archivo oculto para restaurar ~/my_data_on_60GB_partition/), o mejor aún (dado que, como descubrió, podría tener muchos archivos esperando a ser eliminados), agregue la -nmarca para que mvno sobrescriba nada, pero no preguntarte al respecto:

sudo mv -n ~/my_data_on_60GB_partition/* /media/admin/my_data/

También puedes agregar la -vbandera para ver qué se está haciendo.

Con cualquier compatible con POSIX mv, la estructura de directorio original aún debería estar intacta, por lo que, alternativamente, puedes verificar eso y simplemente eliminar /media/admin/my_data... (Sin embargo, en el caso general, creo que la mv -nvariante es el enfoque seguro: maneja todas las formas de mv, incluidop.ej mv /media/admin/my_data/* my_data_on_60GB_partition/.)

Probablemente necesitarás restaurar algunos permisos; usted puede hacer esoen masausando chowny chmod, o restaurarlos desde copias de seguridad usando getfacly setfacl(gracias aSato KatsuraPara elrecordatorio).

Answer 2

Después de recibir la respuesta de Stephen Kitt y analizar este comando como una posible solución:

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

Decidí posponer la ejecución hasta que entendí lo que estaba sucediendo. Esta respuesta describe lo que descubrí y terminé haciendo.

Estoy usando Gnu mv, que copia archivos al destino y solo si la operación de copia tiene éxito, elimina el original.
Sin embargo, quería confirmar si mvesta secuencia se realiza un archivo a la vez; si eso fuera cierto, el contenido de la carpeta original se habría dividido limpiamente en dos partes, una parte trasladada al destino y la otra aún dejada en el origen. Y posiblemente habría un archivo que se interrumpió durante la copia y que sería común entre los dos directorios, y probablemente tendría un formato incorrecto.

Para descubrir archivos comunes entre los dos directorios, ejecuté:

~% sudo diff -r --report-identical-files my_data_on_60GB_partition/. /media/admin/mydata/. | grep identical | wc -l
14237

Este resultado sugirió que había 14,237 instancias de los mismos archivos tanto en el directorio de origen como en el de destino, lo confirmé revisando los archivos manualmente; sí, había muchos de los mismos archivos en ambos directorios. Esto sugiere que solo después de mvcopiar grandes cantidades de archivos realiza la eliminación de los archivos fuente. Una búsqueda rápida en infoel mvcomando mostró

[ mv] primero usa parte del mismo código que usa cp -apara copiar los directorios y archivos solicitados, luego (suponiendo que la copia se haya realizado correctamente) elimina los originales. Si la copia falla, se elimina la parte que se copió en la partición de destino.

No ejecuté el comando pero sospecho que si intenté ejecutarlo

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

El-i aviso antes de sobrescribirprobablemente se habría disparado más de 14.000 veces.

Entonces, para saber cuántos archivos totales hay en el directorio recién creado:

~% sudo find my_data_on_60GB_partition/ -type f -a -print | wc -l                                                                    
14238

Entonces, si había un total de 14238 archivos normales en el nuevo directorio y 14237 tenían originales idénticos en el origen, eso significa que solo había un archivo en el nuevo directorio que no tenía un archivo idéntico correspondiente en el origen. Para saber cuál era ese archivo, ejecuté rsync en la dirección de la fuente:

~% sudo rsync -av --dry-run my_data_on_60GB_partition/ /media/admin/my_data
sending incremental file list
./
Education_learning_reference/
Education_learning_reference/Business_Education/
Education_learning_reference/Business_Education/Business_education_media_files/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/Jeff and David F interview/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/Jeff and David F interview/018 business plans-identifying main KPIs.flv

sent 494,548 bytes  received 1,881 bytes  330,952.67 bytes/sec
total size is 1,900,548,824  speedup is 3,828.44 (DRY RUN)

Una verificación rápida confirmó que se trataba de un archivo con formato incorrecto, donde el archivo existía tanto en el origen como en el destino, archivo de destino = 64 MB, original = 100 MB. Este archivo y su jerarquía de directorios todavía eran propiedad de root y aún no se habían restaurado los permisos originales.

Entonces en resumen:

• todos los archivos que mvnunca llegaron todavía están en sus ubicaciones originales (obviamente)
• todos los archivos que mvse copiaron completamente todavía tenían sus copias originales en el directorio de origen
• el archivo que solo se copió parcialmente todavía tenía el original en el directorio de origen

En otras palabras, todos los archivos originales todavía estaban intactos y la solución en este caso fue simplemente eliminar el nuevo directorio.

Answer 3

Solo pensé en comentar que algunas personas pueden verse tentadas a incluir 'xargs' en la mezcla para ejecutar cosas en paralelo. Eso me pone los pelos de punta y realmente me gusta la solución rsync anterior.

En cuanto a las cuestiones del sistema de archivos sobre mover y copiar y cuándo se elimina exactamente el original, el VFS y los sistemas de archivos subyacentes se coordinan para garantizar la atomicidad por archivo antes de llegar al paso de eliminación. Entonces, incluso si se interrumpe antes de que el archivo de destino esté completamente escrito, todo el bloqueo en el VFS es realmente estricto y protege contra cosas como el entrelazado aleatorio de datos incluso en casos paralelos. (Trabajé en cosas de Linux VFS y NFS4)

Agregar 'xargs' a la mezcla probablemente habría hecho que el paso de doble verificación de cordura fuera un dolor de cabeza, con múltiples archivos en medio del tránsito. Ojalá hubiera tenido más secuencias de comandos a nivel del sistema. ¡Buenos recordatorios para mí!

Me encantó la pregunta, buena para las telarañas y hace que vuelva a amar rsync. ¡Salud!