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.?
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é:
mv
jamais atteint sont toujours de return dans leurs locations d'origine (évidemment) mv
a copiés complètement avaient encore leurs copys originales 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é!