Ich habe gerade ein 49-GB-Verzeichnis in einen ungültigen Dateipfad verschoben. Ist es möglich, den ursprünglichen Status der Dateien wiederherzustellen?

Ich habe (nun ja , ich hatte ) ein Verzeichnis:

/media/admin/my_data

Es war ungefähr 49 GB groß und enthielt Zehntausende von Dateien. Das Verzeichnis ist der Mount-Punkt einer aktiven LUKS-Partition.

Ich wollte das Verzeichnis umbenennen in:

/media/admin/my_data_on_60GB_partition

Ich habe es damals noch nicht gemerkt, aber ich habe den Befehl vom Home-Verzeichnis aus ausgegeben, und am Ende habe ich Folgendes getan:

~% sudo mv /media/admin/my_data my_data_on_60GB_partition

Dann begann das mvProgramm, /media/admin/my_dataseine Inhalte in ein neues Verzeichnis zu verschieben ~/my_data_on_60GB_partition.

Ich habe Ctrl+ verwendet C, um den Befehl vorzeitig abzubrechen, und habe jetzt eine ganze Reihe von Dateien, die auf Verzeichnisse verteilt sind:

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

und

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

Das neue Verzeichnis ~/my_data_on_60GB_partitionund einige seiner Unterverzeichnisse gehören root.
Ich gehe davon aus, dass das mvProgramm die Dateien zuerst als root kopiert und sie dann nach der Übertragung chownwieder auf mein Benutzerkonto zurückgeschrieben hat.

Ich habe eine etwas alte Sicherung des Verzeichnisses / der Partition.
Meine Frage ist, ist es möglich, den Haufen von Dateien, die verschoben wurden, zuverlässig wiederherzustellen?

Das heißt, kann ich einfach laufen:

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

oder sollte ich den versuch der wiederherstellung aufgeben, da die dateien möglicherweise beschädigt und teilweise vollständig sind, etc.?

• OS - Ubuntu 16.04

mv --version  
mv (GNU coreutils) 8.25

Beim Verschieben von Dateien zwischen Dateisystemen wird mveine Datei nicht gelöscht, bevor der Kopiervorgang abgeschlossen ist, und die Dateien werden nacheinander verarbeitet (ich sagte anfangs, sie werden kopiert und dann mvnacheinander gelöscht , aber das ist nicht garantiert - mindestens GNU- Kopien und dann werden alle Befehle gelöscht). Zeilenargument , und POSIX gibt dieses Verhalten an ). Sie sollten also höchstens eine unvollständige Datei im Zielverzeichnis haben, und das Original befindet sich weiterhin im Quellverzeichnis.

Fügen Sie das -iFlag hinzu, damit mvnichts überschrieben wird , um die Objekte zurückzusetzen:

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

(vorausgesetzt, Sie haben keine versteckten Dateien zum Wiederherstellen ~/my_data_on_60GB_partition/) oder noch besser (vorausgesetzt, Sie haben festgestellt, dass möglicherweise viele Dateien gelöscht werden müssen), fügen Sie das -nFlag hinzu, damit mvnichts überschrieben wird, aber nicht frag dich danach:

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

Sie können auch die -vFlagge hinzufügen, um zu sehen, was gerade getan wird.

Mit jedem POSIX-konform mv, nach wie vor die ursprüngliche Verzeichnisstruktur intakt sein sollte, so könnte alternativ Sie , dass der Check - und einfach löschen /media/admin/my_data... (Im allgemeinen Fall aber ich denke , die mv -nVariante der sichere Ansatz ist - es kümmert sich um alle Formen von mv, einschließlich zB mv /media/admin/my_data/* my_data_on_60GB_partition/ )

Möglicherweise müssen Sie einige Berechtigungen wiederherstellen. Sie können dies massenweise mit chownund tun chmododer sie aus Backups mit getfaclund wiederherstellen setfacl(danke an Sato Katsura für die Erinnerung ).

Nachdem Sie Stephen Kitts Antwort erhalten und diesen Befehl als mögliche Lösung erörtert haben:

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

Ich beschloss, es zu unterbrechen, bis mir klar wurde, was passierte. Diese Antwort beschreibt, was ich herausgefunden und am Ende getan habe.

Ich verwende Gnu, mvdas Dateien auf das Ziel kopiert. Nur wenn der Kopiervorgang erfolgreich ist, wird das Original gelöscht.
Ich wollte jedoch überprüfen, ob mvdiese Sequenz Datei für Datei ausgeführt wird. Wenn dies zutrifft, wurde der ursprüngliche Ordnerinhalt sauber in zwei Teile aufgeteilt, wobei ein Teil an den Zielort verschoben wurde und der andere Teil noch an der Quelle zurückgelassen wurde. Und möglicherweise gibt es eine Datei, die während des Kopiervorgangs unterbrochen wurde, was für beide Verzeichnisse gleich wäre - und wahrscheinlich ist sie fehlerhaft.

Um Dateien zu finden, die zwischen den beiden Verzeichnissen gemeinsam waren, habe ich Folgendes ausgeführt:

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

Dieses Ergebnis legt nahe, dass sowohl im Quell- als auch im Zielverzeichnis 14.237 Instanzen der gleichen Dateien vorhanden sind. Ich habe dies durch manuelles Überprüfen der Dateien bestätigt. Ja, in beiden Verzeichnissen befinden sich viele der gleichen Dateien. Dies legt nahe, dass nur nach dem mvKopieren großer Datenmengen die Quelldateien gelöscht werden. Ein kurzer Blick infoauf das mvKommando zeigte

Es [ mv] verwendet zunächst denselben Code, der cp -azum Kopieren der angeforderten Verzeichnisse und Dateien verwendet wird, und entfernt dann (vorausgesetzt, die Kopie war erfolgreich) die Originale. Wenn das Kopieren fehlschlägt, wird der Teil entfernt, der auf die Zielpartition kopiert wurde.

Ich habe den Befehl nicht ausgeführt, aber ich vermute, dass ich versucht habe, ihn auszuführen

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

Die -i Eingabeaufforderung vor dem Überschreiben hätte wahrscheinlich mehr als 14.000 Mal ausgelöst.

Um herauszufinden, wie viele Dateien sich insgesamt im neu erstellten Verzeichnis befinden, gehen Sie wie folgt vor:

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

Wenn sich also insgesamt 14238 reguläre Dateien im neuen Verzeichnis befanden und 14237 identische Originale in der Quelle hatten, bedeutet dies, dass sich nur eine Datei im neuen Verzeichnis befand, die keine entsprechende identische Datei in der Quelle hatte. Um herauszufinden, was diese Datei ist, habe ich rsync zurück in Richtung der Quelle ausgeführt:

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

Eine schnelle Überprüfung bestätigte, dass dies die fehlerhafte Datei war, bei der die Datei sowohl auf der Quelle als auch auf dem Ziel vorhanden war. Zieldatei = 64 MB, Original = 100 MB. Diese Datei und ihre Verzeichnishierarchie befanden sich noch im Besitz von root und hatten noch nicht die ursprünglichen Berechtigungen wiederhergestellt.

Also zusammenfassend:

• Alle Dateien, die mvnie erreicht wurden, befinden sich (offensichtlich) noch an ihrem ursprünglichen Speicherort.
• Alle Dateien, die mvvollständig kopiert wurden, hatten noch ihre Originalkopien im Quellverzeichnis
• Die Datei, die nur teilweise kopiert wurde, hatte immer noch das Original im Quellverzeichnis

Mit anderen Worten, alle Originaldateien waren noch intakt und die Lösung bestand in diesem Fall darin, einfach das neue Verzeichnis zu löschen!

Ich dachte nur, ich würde sagen, dass manche Leute versucht sein könnten, 'xargs' in die Mischung zu werfen, um die Dinge parallel laufen zu lassen. Das gibt mir die Qualen und ich mag die obige rsync-Lösung wirklich.

Beim Verschieben und Kopieren des Dateisystems und beim Löschen des Originals werden das VFS und die zugrunde liegenden Dateisysteme so koordiniert, dass die Atomarität pro Datei gewährleistet ist, bevor dieser Löschschritt ausgeführt wird. Selbst wenn es unterbrochen wird, bevor die Zieldatei vollständig geschrieben ist, ist die gesamte Sperre im VFS wirklich streng und schützt auch in parallelen Fällen vor Dingen wie zufälliger Datenverschachtelung. (Ich habe an Linux VFS und NFS4 Sachen gearbeitet)

Das Hinzufügen von 'xargs' zu der Mischung hätte den Schritt der doppelten Überprüfung der Vernunft wahrscheinlich zu Kopfschmerzen gemacht, da sich während der Übertragung mehrere Dateien befanden. Ich wünschte, ich hätte mehr Skripte auf Systemebene. Gute Erinnerungen für mich!

Liebte die Frage, gut für Spinnweben, und bringt mich dazu, Rsync wieder zu lieben. Prost!