Je viens de "mv" ed un directory de 49 Go à un mauvais path de file, est-il possible de restaurer l'état d'origine des files?

J'ai (bien, j'ai eu ) un directory:

/media/admin/my_data 

Il était d'environ 49 Go et comptait des dizaines de milliers de files. Le directory est le sharepoint assembly d'une partition LUKS active.

Je voulais renommer le directory en:

 /media/admin/my_data_on_60GB_partition 

Je ne savais pas à l'époque, mais j'ai émis la command depuis le directory personnel, donc j'ai fini par faire:

 ~% sudo mv /media/admin/my_data my_data_on_60GB_partition 

Alors, le programme mv a commencé à déplacer /media/admin/my_data et son contenu vers un nouveau directory ~/my_data_on_60GB_partition .

J'ai utilisé Ctrl + C pour annuler la command à mi-path, donc maintenant j'ai tout un tas de files répartis entre les directorys:

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

et

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

Le nouveau directory ~/my_data_on_60GB_partition et certains de ses sous-directorys appartiennent à root.
Je suppose que le programme mv doit avoir copié les files en tant que root initialement, puis après le transfert chown les renvoyé à mon count d'user.

J'ai une sauvegarde un peu ancienne du directory / partition.
Ma question est, est-il possible de restaurer de manière fiable le groupe de files qui ont été déplacés?

Autrement dit, est-ce que je peux juste courir:

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

ou devrais-je renoncer à essayer de récupérer, car les files sont peut-être corrompus et partiellement complets, etc.?

  • OS – Ubuntu 16.04
 mv --version mv (GNU coreutils) 8.25 

Lors du déplacement de files entre les filesystems, mv ne supprime pas un file avant de le copyr et traite les files de manière séquentielle (je l'ai initialement copié puis supprimé chaque file à son tour, mais ce n'est pas garanti). l'argument de command line à son tour, et POSIX spécifie ce comportement ). Vous devez donc avoir au plus un file incomplet dans le directory cible, et l'original sera toujours dans le directory source.

Pour déplacer les choses, ajoutez le drapeau -i afin que mv n'écrase rien:

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

(en supposant que vous ne disposez d'aucun file caché à restaurer à partir de ~/my_data_on_60GB_partition/ ), ou mieux encore (étant donné que vous avez découvert que vous pourriez avoir beaucoup de files en attente d'être supprimés), ajoutez l' -n si mv doesn ' t écraser tout mais ne vous request pas à ce sujet:

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

Vous pouvez également append le drapeau -v pour voir ce qui se fait.

Avec n'importe quel mv compatible POSIX, la structure du directory d'origine devrait être intacte, donc vous pouvez vérifier cela et simplement supprimer /media/admin/my_data … (Dans le cas général cependant, je pense que la variante mv -n est l'approche sûre – elle gère toutes les forms de mv , y compris par exemple mv /media/admin/my_data/* my_data_on_60GB_partition/ .)

Vous aurez probablement besoin de restaurer certaines permissions; vous pouvez le faire en masse en utilisant chown et chmod , ou les restaurer à partir de sauvegardes en utilisant getfacl et setfacl (merci à Sato Katsura pour le callback ).

Après avoir obtenu la réponse de Stephen Kitt et discuté de cette command comme solution possible:

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

J'ai décidé de ne pas courir jusqu'à ce que je me rende count de ce qui se passait, cette réponse décrit ce que j'ai découvert et fini par faire.

J'utilise Gnu mv qui copy les files sur la cible, alors seulement si l'opération de copy réussit, elle supprime l'original.
Cependant, je voulais confirmer si mv exécutait cette séquence un file à la fois, si c'était vrai, le contenu du dossier d'origine aurait été proprement découpé en deux parties, une partie décalée vers la destination, l'autre restée à la source. Et éventuellement, il y aurait un file qui a été interrompu pendant la copy qui serait commun entre les deux directorys – et il serait probablement malformé.

Pour découvrir les files qui étaient communs entre les deux directorys, j'ai couru:

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

Ce résultat a suggéré qu'il y avait 14 237 instances des mêmes files dans les directorys source et cible, j'ai confirmé en vérifiant les files manuellement – oui il y avait beaucoup des mêmes files dans les deux directorys. Cela suggère que seulement après que mv copy de grands groupes de files effectue la suppression des files source. Une search rapide dans les info sur la command mv montré

Il utilise d'abord le même code que celui utilisé par cp -a pour copyr les directorys et files demandés, puis (en supposant que la copy a réussi), il supprime les originaux. Si la copy échoue, la partie copiée sur la partition de destination est supprimée.

Je n'ai pas exécuté la command mais je soupçonne que si j'ai essayé de courir

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

L' invite -i avant écrasement aurait probablement déclenché plus de 14 000 fois.

Alors, pour savoir combien de files total dans le nouveau directory créé:

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

Donc, s'il y avait un total de 14238 files réguliers dans le nouveau directory et que 14237 avaient des originaux identiques dans la source, cela signifie qu'il n'y avait qu'un seul file dans le nouveau directory qui n'avait pas de file identique correspondant sur la source. Pour savoir ce que ce file était, j'ai couru rsync dans la direction de la source:

 ~% 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) 

Une vérification rapide a confirmé qu'il s'agissait du file malformé, où le file existait à la fois sur la source et la destination, file de destination = 64 Mo, original = 100 Mo. Ce file et sa hiérarchie de directorys étaient toujours la propriété de root et n'avaient pas encore restauré les permissions d'origine.

Donc en résumé:

  • tous les files que mv jamais atteint sont toujours de return dans leurs locations d'origine (évidemment)
  • tous les files que mv a copiés complètement avaient encore leurs copys originales dans le directory source
  • le file qui n'a été que partiellement copié avait toujours l'original dans le directory source

En d'autres termes, tous les files originaux étaient encore intacts et la solution dans ce cas était simplement de supprimer le nouveau directory!

Je pensais juste que je dirais que certaines personnes pourraient être tentées de jeter des «xargs» dans le mélange pour faire fonctionner les choses en parallèle. Cela me donne les willies et j'aime vraiment la solution rsync ci-dessus.

En ce qui concerne le système de files, les files VFS et les filesystems sous-jacents sont coordonnés pour garantir l'atomicité par file avant d'accéder à cette étape de suppression. Ainsi, même s'il est interrompu avant que le file cible ne soit entièrement écrit, tout le locking dans le VFS est très ssortingct et protège contre des éléments tels que l'entrelacement random de données, même dans des cas parallèles. (J'ai travaillé sur Linux VFS et NFS4)

L'ajout de «xargs» au mélange aurait probablement rendu l'étape de double vérification de la santé mentale un casse-tête, avec plusieurs files en transit moyen. J'aurais aimé avoir plus de scripts de niveau système. De bons callbacks pour moi!

J'ai adoré la question, bon pour les canvass d'araignée, et me fait aimer à nouveau rsync. À votre santé!