Ich habe gerade ein 49 GB großes Verzeichnis per „mv“ auf einen falschen Dateipfad verschoben. Ist es möglich, den ursprünglichen Zustand der Dateien wiederherzustellen?

Question

Ich habe (also ichhatte) ein Verzeichnis:

/media/admin/my_data

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

Ich wollte das Verzeichnis umbenennen in:

/media/admin/my_data_on_60GB_partition

Mir war es damals nicht klar, aber ich gab den Befehl vom Home-Verzeichnis aus ein und führte letztendlich Folgendes aus:

~% sudo mv /media/admin/my_data my_data_on_60GB_partition

Anschließend wurde begonnen, das Programm und seinen Inhalt in ein neues Verzeichnis mvzu verschieben ./media/admin/my_data~/my_data_on_60GB_partition

Ich habe Ctrl+ verwendet C, um den Befehl zwischendurch abzubrechen, sodass ich jetzt einen ganzen Haufen Dateien auf mehrere Verzeichnisse verteilt habe:

~/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 zunächst als root kopiert und chownsie dann nach der Übertragung wieder auf mein Benutzerkonto übertragen hat.

Ich habe ein etwas älteres Backup des Verzeichnisses/der Partition.
Meine Frage ist,ist es möglich, die verschobenen Dateien zuverlässig wiederherzustellen?

Das heißt, kann ich einfach Folgendes ausführen:

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

oder sollte ich die Wiederherstellungsversuche aufgeben, da die Dateien möglicherweise beschädigt, teilweise vollständig usw. sind?

• Betriebssystem - Ubuntu 16.04

mv --version  
mv (GNU coreutils) 8.25

Answer 1

Beim Verschieben von Dateien zwischen Dateisystemen mvwerden Dateien nicht gelöscht, bevor sie vollständig kopiert wurden, und die Dateien werden nacheinander verarbeitet (ich sagte zunächst, dass jede Datei nacheinander kopiert und dann gelöscht wird, aber das ist nicht garantiert – zumindest mvkopiert GNU jede Datei nacheinander und löscht sie dann.Befehlszeilenargumentwiederum, undPOSIX spezifiziert dieses Verhalten). Sie sollten also höchstens eine unvollständige Datei im Zielverzeichnis haben und das Original wird sich weiterhin im Quellverzeichnis befinden.

Um die Dinge zurück zu verschieben, fügen Sie das -iFlag hinzu, damit mvnichts überschrieben wird:

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

(vorausgesetzt, Sie haben keine versteckten Dateien, aus denen eine Wiederherstellung erfolgen könnte ~/my_data_on_60GB_partition/) oder noch besser (da, wie Sie festgestellt haben, viele Dateien darauf warten könnten, gelöscht zu werden) fügen Sie das -nFlag hinzu, damit mvnichts überschrieben wird, Sie aber nicht danach gefragt werden:

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

Sie können auch die Flagge hinzufügen, -vum zu sehen, was getan wird.

Bei jedem POSIX-kompatiblen mvsollte die ursprüngliche Verzeichnisstruktur noch intakt sein. Alternativ können Sie dies also überprüfen und einfach löschen /media/admin/my_data... (Allgemein halte ich die mv -nVariante jedoch für die sichere Vorgehensweise, da sie alle Formen von verarbeitet mv, einschließlichz.B mv /media/admin/my_data/* my_data_on_60GB_partition/.)

Sie müssen wahrscheinlich einige Berechtigungen wiederherstellen. Das können Sie tunin Massenmit chownund chmod, oder stellen Sie sie aus Backups wieder her mit getfaclund setfacl(danke anSato Katsurafür dieErinnerung).

Answer 2

Nachdem ich die Antwort von Stephen Kitt erhalten und diesen Befehl als mögliche Lösung besprochen habe:

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

Ich habe beschlossen, mit der Ausführung zu warten, bis ich verstanden habe, was passiert ist. Diese Antwort beschreibt, was ich herausgefunden und schließlich getan habe.

Ich verwende Gnu mv, das Dateien in das Ziel kopiert und dann das Original nur löscht, wenn der Kopiervorgang erfolgreich ist.
Ich wollte jedoch bestätigen, ob mvdiese Sequenz jeweils eine Datei nach der anderen ausführt. Wenn das der Fall wäre, wäre der Inhalt des ursprünglichen Ordners sauber in zwei Teile aufgeteilt worden, ein Teil wäre zum Ziel verschoben worden, der andere wäre noch an der Quelle zurückgeblieben. Und möglicherweise gäbe es eine Datei, die während des Kopierens unterbrochen wurde, was zwischen den beiden Verzeichnissen üblich wäre – und sie wäre wahrscheinlich fehlerhaft.

Um Dateien zu ermitteln, die in 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 deutete darauf hin, dass es 14.237 Instanzen derselben Dateien sowohl im Quell- als auch im Zielverzeichnis gab. Ich bestätigte dies, indem ich die Dateien manuell überprüfte – ja, es gab viele derselben Dateien in beiden Verzeichnissen. Dies deutet darauf hin, dass erst nach mvdem Kopieren großer Dateimengen die Löschung der Quelldateien durchgeführt wird. Eine schnelle Suche im infoBefehl on mvzeigte

Dabei wird [ mv] zunächst ein Teil des gleichen Codes verwendet, der auch cp -azum Kopieren der angeforderten Verzeichnisse und Dateien verwendet wird. Anschließend werden (vorausgesetzt, das Kopieren war erfolgreich) die Originale entfernt. Wenn das Kopieren fehlschlägt, wird der Teil entfernt, der in die Zielpartition kopiert wurde.

Ich habe den Befehl nicht ausgeführt, aber ich vermute, wenn ich versucht hätte, ihn auszuführen

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

Der-i Eingabeaufforderung vor dem Überschreibenwäre wahrscheinlich mehr als 14.000 Mal ausgelöst worden.

So ermitteln Sie, wie viele Dateien sich insgesamt im neu erstellten Verzeichnis befinden:

~% 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 es nur eine Datei im neuen Verzeichnis gab, die keine entsprechende identische Datei in der Quelle hatte. Um herauszufinden, welche Datei das war, 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 es sich um die fehlerhafte Datei handelte. Die Datei existierte sowohl in der Quelle als auch im Ziel, Zieldatei = 64 MB, Original = 100 MB. Diese Datei und ihre Verzeichnishierarchie gehörten noch immer root und die ursprünglichen Berechtigungen waren noch nicht wiederhergestellt.

Zusammenfassend also:

• alle Dateien, die mvnie angekommen sind, sind immer noch an ihren ursprünglichen Speicherorten (offensichtlich)
• alle Dateien, die mvvollständig kopiert wurden, hatten noch ihre Originalkopien im Quellverzeichnis
• Die nur teilweise kopierte Datei hatte noch das Original im Quellverzeichnis

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

Answer 3

Ich wollte nur anmerken, dass manche Leute versucht sein könnten, „xargs“ in den Mix zu werfen, um Dinge parallel laufen zu lassen. Das macht mir Angst und ich mag die rsync-Lösung oben wirklich.

Was das Dateisystem betrifft, also das Verschieben und Kopieren und wann genau das Original gelöscht wird, koordinieren sich das VFS und die zugrunde liegenden Dateisysteme, um die Atomizität pro Datei zu gewährleisten, bevor es zu diesem Löschschritt kommt. Selbst wenn es also unterbrochen wird, bevor die Zieldatei vollständig geschrieben ist, ist die gesamte Sperrung im VFS sehr streng und schützt vor Dingen wie zufälliger Datenverschachtelung, selbst in parallelen Fällen. (Ich habe an Linux VFS und NFS4-Sachen gearbeitet)

Das Hinzufügen von „xargs“ zur Mischung hätte den Schritt der doppelten Plausibilitätsprüfung wahrscheinlich zu einem Problem gemacht, wenn mehrere Dateien mitten im Transit waren. Ich wünschte, ich hätte mehr Skripting auf Systemebene gehabt. Gute Erinnerungen für mich!

Fand die Frage toll, gut für Spinnweben und lässt mich rsync wieder lieben. Prost!